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: Dynamic loading progress Date: Sat, 14 Feb 2015 11:31:51 +0200 Message-ID: <83wq3k3kl4.fsf@gnu.org> References: <87y4t9m76w.fsf@lifelogs.com> <85k31coixa.fsf@stephe-leake.org> <85oapy5kt6.fsf@stephe-leake.org> <83y4oiiw81.fsf@gnu.org> <838ugdf251.fsf@gnu.org> <87bnl1vmqf.fsf@lifelogs.com> <87vbj8tow4.fsf@lifelogs.com> <87r3twtagf.fsf@lifelogs.com> <85siebl7ws.fsf@stephe-leake.org> <85a90ilwmm.fsf@stephe-leake.org> <83386a6f7z.fsf@gnu.org> <85h9upjz7v.fsf@stephe-leake.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1423906333 14866 80.91.229.3 (14 Feb 2015 09:32:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Feb 2015 09:32:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 14 10:32:02 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 1YMZ4z-0006Iq-Qf for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2015 10:32:02 +0100 Original-Received: from localhost ([::1]:59286 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMZ4z-0005tg-9d for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2015 04:32:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMZ4v-0005sk-4o for emacs-devel@gnu.org; Sat, 14 Feb 2015 04:31:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMZ4r-0005Ai-SY for emacs-devel@gnu.org; Sat, 14 Feb 2015 04:31:57 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:35939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMZ4r-00059h-FK for emacs-devel@gnu.org; Sat, 14 Feb 2015 04:31:53 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NJR00J008UWQL00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 14 Feb 2015 11:31:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJR00JCT953KM60@a-mtaout22.012.net.il>; Sat, 14 Feb 2015 11:31:51 +0200 (IST) In-reply-to: <85h9upjz7v.fsf@stephe-leake.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:183046 Archived-At: > From: Stephen Leake > Date: Fri, 13 Feb 2015 15:09:08 -0600 >=20 > Eli Zaretskii writes: >=20 > >> From: Stephen Leake > >> Date: Thu, 12 Feb 2015 14:09:53 -0600 > >> > >> I had to add to options to the 'gcc' line in modules/curl/Makefi= le: > >> > >> -std=3Dc99 -I$(ROOT)/nt/inc > > > > Why do you need -std=3Dc99? What happens if you don't use it? >=20 > It complains about the "register" keyword in string.h stpcpy >=20 > >GCC > > defaults to -std=3Dgnu99, >=20 > Apparently not in Mingw64 I don't think this is true, as that is a general feature of GCC independent of the platform. But in any case, -std=3Dc99 is rarely w= hat you want, since it's a rare program that conforms to strict ANSI C99 spec. Use -std=3Dgnu99 instead. > > I also don't like the -I$(ROOT)/nt/inc thing, it should only be n= eeded > > for Emacs-specific system-level stuff. Why was it needed here? >=20 > some file included ms-w32.h: >=20 > stephe@takver$ make > gcc -std=3Dc99 -ggdb3 -Wall -I../../src -I../../lib `pkg-config lib= curl --cflags` -fPIC -c curl.c > curl.c:1:0: warning: -fPIC ignored for target (all code is position= independent) > #include > ^ > In file included from ../../src/config.h:1866:0, > from curl.c:6: > ../../src/conf_post.h:32:27: fatal error: ms-w32.h: No such file or= directory This is wrong on several levels. First, the module shouldn't use "-fPIC" unconditionally, as on some platforms, such as Windows, it invokes a warning and is otherwise ignored. More importantly, it is dead wrong for modules to include headers in lib/, and in particular they should NEVER include Emacs's config.h. That's because a config.h produced for a program or library should never be used by another program or library -- it includes stuff specific to that program/library. On Windows, doing so will get you in trouble because ms-w32.h include= s all kinds of tricks and function redirections/redefinitions that will most probably break any non-trivial code which interfaces with an external library. The above is an example of such trouble, and the "solution" of add -I../nt -s a wrong solution. So the question now becomes: what happens if you _remove_ the "-I../../lib" option from the GCC command line? If that doesn't work, then we really need an emacs.h file ASAP, and the module should include only that file, without including inside that file. > >> Normally those would be added by configure. Perhaps they could b= e set > >> via CFLAGS by the perl script when on mingw64? > > > > Sorry, I don't understand: the Emacs configure script already add= s > > that directory to the include path. So what's wrong? >=20 > I'm not running the top level Emacs makefile; I'm running > modules/curl/Makefile, in order to build the curl module. >=20 > > GNU ld is a one-pass linker, so the libraries should be after the > > object files. >=20 > Ah, right; I forgot about link order. That fixes the libcurl proble= m. > But the original order worked on Debian. On Debian, you don't need to link against the import library, that's why. > >> The other symbols appear to be Emacs symbols? There was some dis= cussion > >> about a special flag for exporting those on Windows; is that '-X= linker > >> -E'? I guess that goes in src/Makefile somewhere? > > > > The unresolved externals that are defined by Emacs are expected: = you > > need to link against an import library produced as part of buildi= ng > > emacs.exe. >=20 > Right, but I was expecting this makefile to do that. Especially sin= ce it > "just works" on Debian. >=20 > > Otherwise all this stuff will not work on Windows, because > > the Windows port of the linker must see the import library at lin= k > > time. >=20 > Apparently that is not true on Debian. Yes, and I tried to explain why. Dynamic linking on Posix systems works differently: the reference to external symbols is left at zero, and is resolved at run time. On Windows, these references cannot be left unresolved, so using the import library allows the linker to resolve them to an "import symbol" which is just an indirect call through a dispatch table. > > The flag to produce the import library should be something like t= his: > > > > -Wl,--out-implib=3Dlibemacs.dll.a >=20 > And that goes in src/Makefile somewhere? Not on the "emacs$(EXEEXT)= " > line, since that doesn't run gcc. So it must go on the temacs$(EXEE= XT) > line (line 693)? Yes, it should be part of the temacs link command. > And until we write emacs.h, it also needs -Xlinker -E (or can that > be -Wl,-E ?). I don't see what does a header file have to do with linking. Why do you think you need that option? > That should be added by configure when Windows and --with-ltdl are > specified.=20 I'd imagine --with-modules, not --with-ltdl, but I didn't take a look at the branch yet. > Hmm. We already have: >=20 > LIBLTDL =3D -lltdl -Wl,--export-dynamic >=20 > which is included in LIBES, and thus in the temacs.exe link. Howeve= r, > that produces a warning: >=20 > C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../x86_= 64-w64-mingw32/bin/ld.exe: > warning: --export-dynamic is not supported for PE+ targets, did you= mean > --export-all-symbols? >=20 > So apparently that should be changed to --export-all-symbols? Doing= that > produces libemacs.dll.a No, using --export-all-symbols is wrong. See my other message in thi= s thread. We don't want to export all the Emacs symbols to the outside world. Please use -Wl,--out-implib=3D instead. > > Then you need to link the shared library against -lemacs. > > > > And the link command line should produce curl.dll, not curl.so. >=20 > Ok, that produced curl.dll. But doing: >=20 > src/emacs.exe -L modules/curl & > (require 'curl) >=20 > fails, with "eval: Cannot open load file: No such file or directory= , > curl". That most probably means the module support stuff doesn't tell Emacs where to find the library. Or maybe it tries to load curl.so or something. I really don't know, you should debug this. > That same test works on Debian. GNU/Linux is what Aur=E9lien tested this on, so it shouldn't surprise you it works on GNU/Linux, but not on Windows. IOW, it's not an interesting data point. > So one question is how to make this Makefile do the right thing > for the current operating system. The intent is for this Makefile t= o be > part of the Emacs test suite, so it needs to not require user inter= vention. Indeed, this is part of the job of figuring out how to use modules in Emacs. Apparently, that part was not yet done. > One option is to rename modules/curl/Makefile to > modules/curl/Makefile.in and use configure in the modules directori= es. Which configure? the Emacs configure? That'd be a wrong solution, IMO, as it will require the Emacs maintainers to know about modules i= n order to DTRT for them in our mainline configure script. So if Autoconf should be used to generate Makefile's in the modules, it should be their own configure scripts. > Another is to set flags in modules/tests.py. That requires Python, which is an additional requirement for the buil= d environment. I'd rather we used Emacs for that. Alternatively, if the number of different settings is small, we could assume GNU Make and use its conditional directives to cater to the fe= w different platforms. That's much easier, but doesn't scale well to large and complex modules. But perhaps that's not a big deal, if we assume modules will not be large and complex.