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: emacs-dynamic-module in Emacs Git? Date: Mon, 01 Dec 2014 18:51:22 +0200 Message-ID: <83zjb771px.fsf@gnu.org> References: <87wq6tu5m5.fsf@kima.orebokech.com> <85h9xwhpy9.fsf@stephe-leake.org> <87k32sh50f.fsf@lifelogs.com> <85tx1rg64e.fsf_-_@stephe-leake.org> <87siha7r3b.fsf@lifelogs.com> <87lhmz4mtj.fsf@lifelogs.com> <87sih575rc.fsf@lifelogs.com> <8361dyaqf1.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1417452715 13879 80.91.229.3 (1 Dec 2014 16:51:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2014 16:51:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?Aur=C3=A9lien?= Aptel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 01 17:51:50 2014 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 1XvUCT-00062L-Kp for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 17:51:49 +0100 Original-Received: from localhost ([::1]:60871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvUCT-0002Ps-Ae for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 11:51:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvUC4-0002HZ-Rg for emacs-devel@gnu.org; Mon, 01 Dec 2014 11:51:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvUBy-0008SI-Vb for emacs-devel@gnu.org; Mon, 01 Dec 2014 11:51:24 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:49029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvUBy-0008SD-Gd for emacs-devel@gnu.org; Mon, 01 Dec 2014 11:51:18 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NFW00E00XAVE800@mtaout26.012.net.il> for emacs-devel@gnu.org; Mon, 01 Dec 2014 18:50:03 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NFW008UMXFFQ550@mtaout26.012.net.il>; Mon, 01 Dec 2014 18:50:03 +0200 (IST) In-reply-to: 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:178595 Archived-At: > Date: Mon, 1 Dec 2014 14:59:00 +0100 > From: Aur=C3=A9lien Aptel > Cc: Emacs development discussions >=20 > On Sat, Nov 29, 2014 at 6:05 PM, Eli Zaretskii wrote= : > > I have a few more, specific to the Windows build: > > > > . As with other optional libraries, using libltdl should detect= its > > availability at run time, and load it dynamically, instead of > > passing -ltdl switch to the linker when Emacs is built. See > > examples of how to do that in image.c and gnutls.c. >=20 > What's the point of doing it this way? Honest question. Honest answer: to allow users to download and install Emacs binaries and run Emacs without also installing the optional libraries, which are available as separate DLLs. If we link Emacs against those DLLs, it will refuse to start when those DLLs are not present on the end-user's machine. > > . It seems to me that the modules call functions implemented by > > Emacs, like make_number and Fmember, on the assumption that > > calling any Emacs function will "just work". This is false f= or >=20 > I had to add a linker flag to expose every symbol of Emacs. See the > relevant commit: >=20 > http://git.savannah.gnu.org/cgit/emacs.git/commit/configure.ac?h= =3Ddynamic-modules&id=3D5c710fba15e0a3a2ae5d831e5cdb555332238752 I don't think this is correct: we don't really want to export all the symbols. > > Windows (the link command that produces the shared object wil= l > > fail), unless we mark such exportable functions and build an > > import library that will be passed to the linker when the mod= ule's > > shared object is built. Likewise with global variables defin= ed by > > Emacs. >=20 > I've never used Windows much for developement. Isn't there a simila= r > flag we can use on mingw? The same flag will also work with MinGW, but it is not the problem I was talking about. The problem is that on Windows, when you link the modules themselves into shared libraries, the linker must be presente= d with information about symbols exported by Emacs. You could use the Emacs binary, of course, but that's cumbersome. The usual technique is to generate a special import library as side effect of building Emacs, and then submit that import library to the linker when you create the module's shared library. The import library is by convention called libFOO-NN.dll.a (where "FOO" in this case will probably be "emacs", and NN will probably be the Emacs version). It is automatically created by the linker if you pass the "-Wl,--out-implib=3DlibFOO-NN.dll.a" switch to the compiler = on the link command line. All this is pretty standard practice on Windows and works well, the only issue for us is to decide which functions to export (unless we really want to export all of them, in which case the --export-dynamic linker switch is all that's needed).