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 17:51:11 +0200 Message-ID: <83pp9cwky8.fsf@gnu.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> <85bnkwil1c.fsf@stephe-leake.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423929111 26238 80.91.229.3 (14 Feb 2015 15:51:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Feb 2015 15:51:51 +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 16:51: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 1YMf0P-0003I8-Kz for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2015 16:51:41 +0100 Original-Received: from localhost ([::1]:60219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMf0O-00048N-Uv for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2015 10:51:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMf04-00043I-5V for emacs-devel@gnu.org; Sat, 14 Feb 2015 10:51:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMezz-00084e-75 for emacs-devel@gnu.org; Sat, 14 Feb 2015 10:51:20 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:55944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMezy-00084M-Jo for emacs-devel@gnu.org; Sat, 14 Feb 2015 10:51:15 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NJR00O00Q52NL00@mtaout28.012.net.il> for emacs-devel@gnu.org; Sat, 14 Feb 2015 17:49:30 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJR00NLMQMIWD20@mtaout28.012.net.il>; Sat, 14 Feb 2015 17:49:30 +0200 (IST) In-reply-to: <85bnkwil1c.fsf@stephe-leake.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.184 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:183063 Archived-At: > From: Stephen Leake > Date: Sat, 14 Feb 2015 09:13:03 -0600 > > > 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. No, it means including lisp.h without any changes will get you in trouble. > > 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. None of the Emacs header files in src/ include config.h. But they might include other headers not appropriate for modules, like intprops.h above. This really is something that needs to be figured out and fixed before the modules are announced operational, at least on MS-Windows. > >> > -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). As soon as some symbols are declared for export, -Wl,--out-implib= takes care to export only them, whereas -E will still export everything. > > 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 Yes, that's why I said --export-all-symbols should not be used. You don't need it. > but I don't see how we are going to restrict what symbols are > available to the module. The way to restrict the export is to declare the symbols you want to export with __declspec(dllexport). Then only those symbols will be exported. Note that, since emacs.h will be included by modules as well, we will need something like #ifdef WINDOWS # ifdef emacs # define EMACS_EXPORT __declspec(dllexport) # else # define EMACS_EXPORT __declspec(dllimport) # endif # else # define EMACS_EXPORT #endif That's because they should be exported by Emacs, but imported by modules. > 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). Windows can be detected by looking at environment variables. Since Make converts them to Make variables, they are easily accessed. Another possibility is to invoke "gcc -dumpmachine" via the $shell function. We could also invoke uname in a similar manner, but that requires MSYS or Coreutils to be installed. We could even invoke Make itself with the --version option, and see what follows the "Built for" header. So ways to do that exist, we just need to decide whether we want to go that way.