From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Newsgroups: gmane.emacs.devel Subject: Re: emacs-dynamic-module in Emacs Git? Date: Mon, 1 Dec 2014 14:59:00 +0100 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1417442362 25148 80.91.229.3 (1 Dec 2014 13:59:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Dec 2014 13:59:22 +0000 (UTC) Cc: Emacs development discussions To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 01 14:59:17 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 1XvRVU-0003RQ-93 for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 14:59:16 +0100 Original-Received: from localhost ([::1]:60236 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvRVT-00008j-VI for ged-emacs-devel@m.gmane.org; Mon, 01 Dec 2014 08:59:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44088) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvRVP-00008Z-OQ for emacs-devel@gnu.org; Mon, 01 Dec 2014 08:59:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvRVN-0004Pr-CZ for emacs-devel@gnu.org; Mon, 01 Dec 2014 08:59:11 -0500 Original-Received: from mail-la0-x233.google.com ([2a00:1450:4010:c03::233]:42855) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvRVG-0004OS-Dc; Mon, 01 Dec 2014 08:59:02 -0500 Original-Received: by mail-la0-f51.google.com with SMTP id ms9so8748688lab.38 for ; Mon, 01 Dec 2014 05:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pYGyR1PQ7015rDxR/3XxEx0OeMJkVEVx9vUcojTPbPA=; b=XCsSqp+pmog6SGPaVT6mQCFixjxGXPaW9ldiUQj7fCQIbHBkZeGvt5hUXUdhH7A3Za LFOjfGYIMFvTquRUROmqGhzCkmSfFo8z21Tl9vu3wrU+isEo0ze93xEsEr6ClwzD7/zn HIyPRgfknEEF+89ofVZrYOFhArZGSoOLW0JMyA1Nqr46PIDyCubnGAntMadC1l4bb8KW 1uXGltvP+mLmf2K9n6CFdyWxQ2t8n8X82X7EV0bZB61uuMM5FffIIUAA6PN7YJX2GcA9 CQz/p8d5eRGnGdMu/TKYjKI27+9z9HwmC7fAsop4nQUTJi18xS3PXMnHX7HqZPDowOah InYg== X-Received: by 10.112.199.233 with SMTP id jn9mr5332567lbc.18.1417442340455; Mon, 01 Dec 2014 05:59:00 -0800 (PST) Original-Received: by 10.114.77.131 with HTTP; Mon, 1 Dec 2014 05:59:00 -0800 (PST) In-Reply-To: <8361dyaqf1.fsf@gnu.org> X-Google-Sender-Auth: 7rijAjRoIDRkz2WXSe-_FsjIeeI X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::233 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:178578 Archived-At: 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. What's the point of doing it this way? Honest question. > . The Makefile's use literal .so extension for the dynamic libraries > being built -- this is non-portable and should be determined at > configure time. The makefile is temporary. It can be replaced by a more portable script or elisp afterwards. > . 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 for I had to add a linker flag to expose every symbol of Emacs. See the relevant commit: http://git.savannah.gnu.org/cgit/emacs.git/commit/configure.ac?h=dynamic-modules&id=5c710fba15e0a3a2ae5d831e5cdb555332238752 > Windows (the link command that produces the shared object will > fail), unless we mark such exportable functions and build an > import library that will be passed to the linker when the module's > shared object is built. Likewise with global variables defined by > Emacs. I've never used Windows much for developement. Isn't there a similar flag we can use on mingw? > (In general, I question why "modules" that require such tight > integration with Emacs internals are a good idea: why not simply > add them to the Emacs core and be done with that? What do we gain > by having them as separate .so shared objects?) We could directly add them to Emacs I guess... It's just that time has shown no-one actually agrees to do it. > . I don't understand why load-module-suffixes includes extensions > from different platforms, nor why is this variable needed at all. `load' has complex logic based on suffixes and knowing the type of files based on them. I tried to re-use what I could without risking breaking something. > AFAIK, libltdl is perfectly capable of finding shared objects on > each platform without us feeding it the extension to use. It > knows what extensions are used by the underlying platform for > shared libraries. Moreover, trying to load .dylib or .dll on > GNU/Linux will hardly produce good results, so why risk that by > exposing the platform-specific extensions at all? I've never had other shared libraries than my system native ones, especially in an emacs related dir. I don't think it's a problem given you can load a module using the full path to it. > > Please note that the above is based solely on examining the > source-level diffs; I didn't yet try to build this branch or use it. > > Thanks again for working on this. Thanks for the feedback :-)