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: Fri, 13 Feb 2015 10:27:49 +0200 Message-ID: <83zj8i43ne.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> 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 1423816105 7774 80.91.229.3 (13 Feb 2015 08:28:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2015 08:28:25 +0000 (UTC) Cc: stephen_leake@stephe-leake.org, 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 Fri Feb 13 09:28:16 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 1YMBbi-0006L1-MR for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 09:28:14 +0100 Original-Received: from localhost ([::1]:53908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMBbi-0007Ha-2b for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 03:28:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMBbU-0007HK-CK for emacs-devel@gnu.org; Fri, 13 Feb 2015 03:28:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMBbP-00057x-4W for emacs-devel@gnu.org; Fri, 13 Feb 2015 03:28:00 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:43141) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMBbO-00057s-SG for emacs-devel@gnu.org; Fri, 13 Feb 2015 03:27:55 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NJP00A00BGTA400@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 13 Feb 2015 10:27:53 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJP00AZEBIG7X40@a-mtaout20.012.net.il>; Fri, 13 Feb 2015 10:27:53 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:182993 Archived-At: > Date: Thu, 12 Feb 2015 22:51:22 +0100 > From: Aur=C3=A9lien Aptel > Cc: Stephen Leake ,=20 > =09Emacs development discussions >=20 > On Thu, Feb 12, 2015 at 9:34 PM, Eli Zaretskii wrote= : > > Sorry, I don't understand: the Emacs configure script already add= s > > that directory to the include path. So what's wrong? >=20 > He's talking about the module Makefile, which is very basic and > standalone (no includes or preprocessing). I don't really understand what that means, but I hope you will be abl= e to help him. > > 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. Otherwise all this stuff will not work on Windows, be= cause > > the Windows port of the linker must see the import library at lin= k > > time. > > > > The flag to produce the import library should be something like t= his: > > > > -Wl,--out-implib=3Dlibemacs.dll.a > > > > Then you need to link the shared library against -lemacs. >=20 > The configure script adds this to Emacs LD flags when modules are e= nabled: >=20 > -lltdl -Wl,--export-dynamic >=20 > What does that do on Windows? Nothing useful in this case, AFAIK. Reverse dynamic linking doesn't work on Windows. On Windows, when you link a shared library, the linker must be presented with either all the dependency object files, or with their import libraries. That's because the linker records inside the shared library data about the dependent object files and their names. In this case, we need to provide this information about Emacs, since (AFAIU) the module has unresolved externals that need to be dynamically linked to the corresponding Emacs symbols. So we need either to link the module against emacs.exe, or against an import library generated when Emacs is built. The latter is accomplished by using the --out-implib=3D option to the linker. Btw, when using the -Wl,--out-implib=3Dlibemacs.dll.a switch on the l= ink command line, we will be by default exporting _all_ the externally visible symbols. That doesn't sound right (think DSO), and is even a source of possible problems, since Emacs on Windows redirects quite a few C library functions to its own implementations, and also adds som= e C library functions unavailable in the MS runtime. Making them visible to modules might mean trouble for those modules, if they rely on the standard or different implementations of those functions. So we should really have the emacs.h header file with only the functions and variables we want to export, and on Windows we should mark those exported functions and variables with dllexport attribute, so that only they are exported. (It is possible that we should also use some visibility attributes on ELF platforms, for similar reasons.) One other potential issue is with passing file names to modules. Emacs on Windows pretends that file-name-coding-system is UTF-8, so using ENCODE_FILE will produce a UTF-8 encoded file name that Windows runtime cannot grok. Therefore, the glue code, either in Lisp or in C, between Emacs and the module will have to convert the file name to the current system codepage (because most libraries only support that on Windows). > Is there an up-to-date guide to setup a simple build environment > (libs and all) for Emacs on Windows? Yes, see nt/INSTALL.