From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sat, 14 Feb 2015 09:13:03 -0600 Message-ID: <85bnkwil1c.fsf@stephe-leake.org> References: <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> <83wq3k3kl4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423926834 23884 80.91.229.3 (14 Feb 2015 15:13:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Feb 2015 15:13:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 14 16:13:43 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 1YMePe-0003fH-Qt for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2015 16:13:43 +0100 Original-Received: from localhost ([::1]:60128 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMePd-0007jm-If for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2015 10:13:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMePU-0007jc-EB for emacs-devel@gnu.org; Sat, 14 Feb 2015 10:13:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMePR-0000et-4Z for emacs-devel@gnu.org; Sat, 14 Feb 2015 10:13:32 -0500 Original-Received: from gproxy1-pub.mail.unifiedlayer.com ([69.89.25.95]:59835) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1YMePQ-0000eX-Tp for emacs-devel@gnu.org; Sat, 14 Feb 2015 10:13:29 -0500 Original-Received: (qmail 31317 invoked by uid 0); 14 Feb 2015 15:13:24 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 14 Feb 2015 15:13:24 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id sFDG1p00b2UdiVW01FDKZo; Sat, 14 Feb 2015 08:13:24 -0700 X-Authority-Analysis: v=2.1 cv=SqADtp+0 c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=TeMFXEv2S7AA:10 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=jrwKn-8xaegA:10 a=0HtSIViG9nkA:10 a=mDV3o1hIAAAA:8 a=uPdko3GTpS3Z1Ltb4nUA:9 a=glDBMo4qYi9yPSpc:21 a=r-c94iYDXmk21MR1:21 Original-Received: from [70.94.38.149] (port=51124 helo=takver) by host114.hostmonster.com with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.82) (envelope-from ) id 1YMePE-0005WN-K3 for emacs-devel@gnu.org; Sat, 14 Feb 2015 08:13:16 -0700 In-Reply-To: <83wq3k3kl4.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 Feb 2015 11:31:51 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 70.94.38.149 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.25.95 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:183058 Archived-At: Eli Zaretskii writes: >> > I also don't like the -I$(ROOT)/nt/inc thing, it should only be needed >> > for Emacs-specific system-level stuff. Why was it needed here? >> >> some file included ms-w32.h: >> >> stephe@takver$ make >> gcc -std=c99 -ggdb3 -Wall -I../../src -I../../lib `pkg-config libcurl --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. Right. More reason to use configure. > So the question now becomes: what happens if you _remove_ the > "-I../../lib" option from the GCC command line? gcc -std=gnu99 -ggdb3 -Wall -I../../src `pkg-config libcurl --cflags` -c curl.c In file included from curl.c:8:0: ../../src/lisp.h:32:22: fatal error: intprops.h: No such file or directory #include ^ compilation terminated. intprops.h is in lib; that explains why -I../../lib is needed. > 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. Nor . And probably not lots of other things. >> > -Wl,--out-implib=libemacs.dll.a >> >> 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$(EXEEXT) >> 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. -Wl,-E is short for -Wl,--export-all-symbols; that makes all symbols declared in Emacs visible to the module. (Similarly, --export-dynamic makes all symbols visible on Debian). I'm assuming emacs.h will include some annotation to make the symbols declared in that file visible, so we won't need --export-all-symbols (but more below). >> That should be added by configure when Windows and --with-ltdl are >> specified. > > I'd imagine --with-modules, not --with-ltdl, but I didn't take a look > at the branch yet. It's currently --with-ltdl, but I agree --with-modules is a better option name. >> Hmm. We already have: >> >> LIBLTDL = -lltdl -Wl,--export-dynamic >> >> which is included in LIBES, and thus in the temacs.exe link. However, >> that produces a warning: >> >> 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? >> >> 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 this > thread. We don't want to export all the Emacs symbols to the outside > world. Please use -Wl,--out-implib= instead. How does that know which symbols to export? The help for Gnu ld --out-implib doesn't say. Testing; apparently it exports all symbols - emacs.dll.a did not change size. So --export-all-symbols is redundant, but I don't see how we are going to restrict what symbols are available to the module. Unless we are proposing to do that solely via .h files, not at the linker level. I think that's better - compile time errors are easier to understand than link time errors. We'll have to see how well that works. >> So one question is how to make this Makefile do the right thing >> for the current operating system. The intent is for this Makefile to be >> part of the Emacs test suite, so it needs to not require user intervention. > > 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 directories. > > Which configure? the Emacs configure? That'd be a wrong solution, > IMO, as it will require the Emacs maintainers to know about modules in > order to DTRT for them in our mainline configure script. Not modules in general, just the few that are in the Emacs test suite. > So if Autoconf should be used to generate Makefile's in the modules, > it should be their own configure scripts. That is true for normal modules, yes. >> Another is to set flags in modules/tests.py. > > That requires Python, which is an additional requirement for the build > environment. I'd rather we used Emacs for that. Ok. > Alternatively, if the number of different settings is small, we could > assume GNU Make and use its conditional directives to cater to the few > 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. Is there an acceptable (ie portable and reliable) way to determine the OS in a Makefile? I'm not aware of one (short of Gnu config.guess). -- -- Stephe