From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Fri, 13 Feb 2015 08:20:09 -0800 Message-ID: <54DE2439.5080809@dancol.org> References: <85k31coixa.fsf@stephe-leake.org> <85oapy5kt6.fsf@stephe-leake.org> <83y4oiiw81.fsf@gnu.org> <838ugdf251.fsf@gnu.org> <54D80098.3020209@cs.ucla.edu> <54D85304.1030600@cs.ucla.edu> <54D9AC29.2020603@cs.ucla.edu> <54DA8539.1020905@cs.ucla.edu> <87zj8ktq8f.fsf@lifelogs.com> <54DD6413.1000403@cs.ucla.edu> <83wq3m436s.fsf@gnu.org> <54DDEB4D.5040300@dancol> <83egpt4zz6.fsf@gnu.org> <54DE12E9.504@[87.69.4.28]> <83a90h4xr8.fsf@gnu.org> <54DE1F14.9010807@dancol.org> <838ug14wti.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="c6O1KjOxASJfb4tXrjopAUE1rxJCQ2G1O" X-Trace: ger.gmane.org 1423844459 27736 80.91.229.3 (13 Feb 2015 16:20:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Feb 2015 16:20:59 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 13 17:20:52 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 1YMIz5-0004tJ-FI for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 17:20:51 +0100 Original-Received: from localhost ([::1]:56170 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMIz4-0002eV-Os for ged-emacs-devel@m.gmane.org; Fri, 13 Feb 2015 11:20:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMIyg-0002eO-F5 for emacs-devel@gnu.org; Fri, 13 Feb 2015 11:20:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMIyX-0006Ur-I7 for emacs-devel@gnu.org; Fri, 13 Feb 2015 11:20:26 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:49641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMIyX-0006UR-51; Fri, 13 Feb 2015 11:20:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=EbYuotxkT7IYsnehkol4T14vljWR+hCXt7p9ihiA7/s=; b=Er7rkZ6y68L/KWYvzcIHacwQk7N3wsjeiR6F2rgvXJMs0lQSki0bmm7XdKxuKfffNu3z9h5FcFcNKZYrDAm+6BIOCQGqYYUGgmyeSqDlyizFfv6mEg1x0bjcmA0uxHe6UU+fJD/wdT/wrK6HxcPgCqB7ack9ittS6Ew1EIf/kSfhBiJEeaVD6ggvpDJQHAjY7Ozwe82P6qAbYsr+zdE1G9AmxpHZHkzlwvi09lnvftq0e82uuei3QGYxw/I8Hecchlyxu0eFCICsJ3bGU2DOa59VCanrrvwCLoi4sxRf4JLjQP0UOjyFeTufMo9rFLQG24PNoFYSn/V44+79S3CnyA==; Original-Received: from c-73-221-38-18.hsd1.wa.comcast.net ([73.221.38.18] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YMIyS-0004VV-On; Fri, 13 Feb 2015 08:20:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: <838ug14wti.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:183012 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c6O1KjOxASJfb4tXrjopAUE1rxJCQ2G1O Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/13/2015 08:10 AM, Eli Zaretskii wrote: >> Date: Fri, 13 Feb 2015 07:58:12 -0800 >> From: Daniel Colascione >> CC: eggert@cs.ucla.edu, emacs-devel@gnu.org >> >> 1) Shared libraries traditionally expose stable ABIs; when ABIs change= >> incompatibly, libraries change sonames. Shared libraries need stable >> ABIs whether or not Emacs loads them: they're linked into other progra= ms >> and aren't necessarily rebuilt at the same time as their dependencies.= >> The Emacs core has never had a stable ABI, and creating one would >> constrain our optimization opportunities. >> >> (That is, libpng.so's ABI ought to change a lot less often than >> /usr/bin/emacs's: the former promises to provide a stable ABI and the >> latter never has.) >=20 > Sorry, I don't share your optimism about the stability of their ABI. My optimism is rooted in reality. Most shared library interfaces are stable the vast majority of the time. If ABIs were generally unstable, we'd have to rebuild programs constantly, yet I can run very old binaries (especially on Windows) without trouble. > In particular, image libraries are a bad example on which to build > your point: look at the versonitis we need to employ in w32-win.el to > support all their different ABIs. Each new revision there breaks > Emacs build with them. w32-win.el isn't that bad, especially for a module that loads quite a few different image libraries. Besides: using modules tightly coupled to the Emacs core doesn't actually help. Instead of elisp coupled to one module's stable ABI, you have a piece of native code tightly coupled not only to that module's stable ABI, but _also_ to the volatile Emacs internal ABI. As jwz would say, now you have two problems. Using a CFFI-like approach both reduces the volatility of the interface (since now there's a strong boundary in only one direction) and makes it easier to fix problems when they do come up. > And we didn't yet start talking about problems with passing FILE > pointers and malloc'ed buffers between Emacs and the modules. You have that problem anyway: a tightly-bound Emacs module for bridging the Emacs core and some third-party library would have to link against _some_ libc, and unless both the Emacs core and the third-party library used the same libc, you'd lose. A better idea is not to pass C runtime objects between dynamically loaded components. --c6O1KjOxASJfb4tXrjopAUE1rxJCQ2G1O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJU3iQ5AAoJEN4WImmbpWBlvMMQAKUpwqbjtnQDOrzY5AYXFtZY SgA43g/Az9WzbtJ/Brv3WLHXP8+Kl/yB1wUYfFcbiJZ613icWhMJHtRw1V71/dC1 oHiy/SzzXttkagCPGI02NkLQLlI1dghzXvV5CLsXiDExblOLcFCNVgM5zbivOrox o9D3qcxNz5PWz/3+njXZm0SRhWLUZ4CUaw/MrOMUvhTrs3lWANDNcH5xdzQP9NcG SAVbltyWh2USdzs8+lEUgh3nmfYkAUJYwFH+YijIxLeDbPP5IqIvUucmkeBUb9VC y9aTpVD7E7/Kt/6onDY5hRsgnFTl20VkplFuixm0KkmJ7fWbqWry1I0FfVmYcocg sZLDx3caNh/08Z3iBq7kOBJV/uBt8WOD7O60NehP4XtIt2PzTyIfjXDFiguf5kln onSTxwg2NOVFfihag25Fs1r1xjT3XTEC9k6mkXNKPQDb5P2dhue0nF2l81V+l9tK Oz5naOy5rexd7vVcfXT3GS1lSi1OTJeDYBUrW3my2MnM3BLbWeQQ4umZhXlcbQLf c40bIsTLR/PdXT0RN/OazQr3isFtcYbUjm9U+C7u7YRL9TesLNaUNTXA0+PzVfNp vEZFWqGeUzFc+WIpPVqc0UwtQLML4iOhajeXg6sJN1xw0C/kou2y9DLaItjuRioo 8fmHmDmkC9QvIDWyf4XJ =kC4w -----END PGP SIGNATURE----- --c6O1KjOxASJfb4tXrjopAUE1rxJCQ2G1O--