From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Contributing LLVM.org patches to gud.el Date: Mon, 09 Feb 2015 18:08:05 +0200 Message-ID: <83a90n9ifu.fsf@gnu.org> References: <87mw4rxkzv.fsf@fencepost.gnu.org> <87y4oavxcy.fsf@fencepost.gnu.org> <87d25juy8m.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423498129 6245 80.91.229.3 (9 Feb 2015 16:08:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Feb 2015 16:08:49 +0000 (UTC) Cc: eller.helmut@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 09 17:08:48 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YKqtD-00046b-Rz for ged-emacs-devel@m.gmane.org; Mon, 09 Feb 2015 17:08:48 +0100 Original-Received: from localhost ([::1]:33607 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKqtC-0004i9-WD for ged-emacs-devel@m.gmane.org; Mon, 09 Feb 2015 11:08:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKqsv-0004ho-Ff for emacs-devel@gnu.org; Mon, 09 Feb 2015 11:08:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKqsr-0000VS-HQ for emacs-devel@gnu.org; Mon, 09 Feb 2015 11:08:29 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:43075) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKqsm-0000U0-Er; Mon, 09 Feb 2015 11:08:20 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NJI00N00I045R00@mtaout26.012.net.il>; Mon, 09 Feb 2015 18:08:27 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJI00BKJI63HJB0@mtaout26.012.net.il>; Mon, 09 Feb 2015 18:08:27 +0200 (IST) In-reply-to: <87d25juy8m.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182704 Archived-At: > From: David Kastrup > Date: Mon, 09 Feb 2015 12:21:13 +0100 > Cc: eller.helmut@gmail.com, emacs-devel@gnu.org > > A generic dynamic library loading facility to Emacs has been in > discussion and vetoed for decades. Somewhat amusingly, the only > working run-time dynamic library loading that I know of in Emacs is > the loading of image libraries (free ones, of course) under Windows. This is very inaccurate, and might lead Ricard, who doesn't know the details, to very wrong conclusions. So I must put the record straight: THERE IS NO "RUN-TIME DYNAMIC LIBRARY LOADING" in Emacs on Windows. What we do have is _delayed_linking_ of shared libraries against which Emacs was compiled at build time. We provide a facility that performs this delayed linking when the Lisp primitives that invoke functions from the respective library are first called. But the interface to those functions, including their calling sequences and all the involved data types, are known to the C compiler at the time the corresponding C source file is compiled as part of building Emacs. Moreover, use of these libraries from Emacs is possibly only through specific primitives that were coded in advance and compiled into the Emacs binary at build time. Lisp programs cannot invoke any functionality from these libraries _except_ what the above-mentioned primitives provide. IOW, the functionality this provides is exactly identical to Emacs being statically linked to these libraries, except that the actual linking is delayed until first use (or indefinitely, if there's no use at all). The reason we provide this on Windows is to allow users to install a pre-compiled binary of Emacs and use it without installing the optional libraries (such as image libraries or GnuTLS), if the user doesn't need the extra functionality. If we didn't provide this feature, Emacs would refuse to start without all of the libraries being present (unlike on Posix platforms, where it will run as long as the functions from those libraries are not called). By contrast, the "generic dynamic library loading" facility that is missing, both on Posix platforms and on MS-Windows, is much more flexible and allows the following features that are not currently available in Emacs: . Two-way conversion between Lisp data types and arbitrary data structures, including pointers, in C, C++, and other languages . Loading libraries not known to Emacs at build time, for which no specialized primitives were coded as part of Emacs itself . Unloading of libraries no longer needed . Calling any exported library function from Lisp, without any need to write a C-level primitive This is an entirely different level of using dynamic object loading, and should never be even compared with the delayed linking of shared libraries we have now.