From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.bugs Subject: bug#21076: dynamic-link often fails to load libraries Date: Fri, 17 Jul 2015 01:00:23 +0200 Message-ID: <87r3o7pv20.fsf@delenn.home.rotty.xx.vu> References: <2096431437065554@web11m.yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1437087681 4202 80.91.229.3 (16 Jul 2015 23:01:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Jul 2015 23:01:21 +0000 (UTC) Cc: 21076@debbugs.gnu.org To: Frank Webster Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Fri Jul 17 01:01:11 2015 Return-path: Envelope-to: guile-bugs@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 1ZFs9O-0008D7-DR for guile-bugs@m.gmane.org; Fri, 17 Jul 2015 01:01:10 +0200 Original-Received: from localhost ([::1]:42280 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFs9N-0006q5-Rj for guile-bugs@m.gmane.org; Thu, 16 Jul 2015 19:01:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFs9J-0006py-Gq for bug-guile@gnu.org; Thu, 16 Jul 2015 19:01:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFs9G-0004hg-AG for bug-guile@gnu.org; Thu, 16 Jul 2015 19:01:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFs9G-0004ha-7E for bug-guile@gnu.org; Thu, 16 Jul 2015 19:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZFs9F-0001O2-SK for bug-guile@gnu.org; Thu, 16 Jul 2015 19:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andreas Rottmann Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 16 Jul 2015 23:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21076 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 21076-submit@debbugs.gnu.org id=B21076.14370876364275 (code B ref 21076); Thu, 16 Jul 2015 23:01:01 +0000 Original-Received: (at 21076) by debbugs.gnu.org; 16 Jul 2015 23:00:36 +0000 Original-Received: from localhost ([127.0.0.1]:51477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZFs8p-00016V-BH for submit@debbugs.gnu.org; Thu, 16 Jul 2015 19:00:36 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:54396) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZFs8l-0000zF-Rf for 21076@debbugs.gnu.org; Thu, 16 Jul 2015 19:00:33 -0400 Original-Received: from delenn.home.rotty.xx.vu ([91.119.182.207]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lyj4F-1Yvwgo2OuN-0167Ls; Fri, 17 Jul 2015 01:00:25 +0200 Original-Received: by delenn.home.rotty.xx.vu (Postfix, from userid 1000) id D0B1D321428; Fri, 17 Jul 2015 01:00:23 +0200 (CEST) In-Reply-To: <2096431437065554@web11m.yandex.ru> (Frank Webster's message of "Thu, 16 Jul 2015 19:52:34 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-Provags-ID: V03:K0:Y+dZpfRwqh9dN+hNA8R+dODy9Loi9bX04HyO91kYBV017tiZUUz 8yXe7W94hXf7uVEF7Bu19pGwrtSdGUzHqgmjICBeN/Ac7/XJEarXWcJdq/fw+7+vqyLNkIv LLG91eVZIH9eE/J8Pq8xUExIoOYmiE3Zx0AQkjRyrAdazfuEckyS9KWEfTNA92EyzWpTsLf aikL1vt+wBiRtmw7aMp5A== X-UI-Out-Filterresults: notjunk:1;V01:K0:kqk1MPYbcGQ=:xWiIY100DBATwMg8Khl7jS AfUllHdGRchYxdYD+rt4zN8PMwq90/6e8pbosc6Eo1/3bwOR1FIDs2wMsmToeFnpnA0IGdaFD LxozZ+8qRQO8aoqJBSBOyy65h5T1Y48eMxJc3yYQkORUOkTM41lNIEGyj4JE6da41xlmzYYk0 xunct+LXI57Oa+3lLfMPgvavrv9uN3lGLgLVSVJjTUqFmHDhW4vjUhxXrWLxznMxgt33QwM2s 7tlzi4+jPvLFoPZuQYmys+4vT1kGuqV+p8hS9WMIkeDBA5b1kD1GbQvTxxqLeWLNxUIhqxzic WIMaorhtVvoWq4hptgxNj+4W7rcK2RmYDe0gaqqpi8T2l1OPcSR9jcOMveuekUJB/tLEBjdel Gj6UginoON0pvML+A0oFugmcg7Pb9jcofMtEErC0DeddGoH4zJTjXNry+mSYAUiECeO13OFPa hoO7ZzpEZGKi2Mlk1ZGd0YOSaOtSrdrQvHuSHmOjQ/3vyz7LTOBr7v4AvPNj+S1qgtiGjU5wC ffxIutbd7KkZFOW0hIbEj5TLw/kBYCkWC08KOOZ1fl+6wyWxZ11R04ocfc0unN9kTmZP/jjs/ du7TzA6vSO6GlDOSLDijBCYsmFK/yq0hXwuUq0SsmCTwP9GYGhb2FpPX5/fdhn89WUX9V+aHj a5EKYg0dYF+QCQg+p8K6qcHg9j5RSkB79qfBZaEWjD0vi+6mQfrtjKDb2V0IlEfD80nw= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7812 Archived-At: Frank Webster writes: > On my Debian system, `dynamic-link' often fails to load shared > libraries: > > Loading using a versioned soname never works: > > scheme@(guile-user)> (dynamic-link "libGL.so.1") > ERROR: In procedure dynamic-link: > ERROR: In procedure dynamic-link: file: "libGL.so.1", message: "file not found" > > Loading without a library extension doesn't work unless the > corresponding *-dev package is installed: > > scheme@(guile-user)> (dynamic-link "libGL") > ERROR: In procedure dynamic-link: > ERROR: In procedure dynamic-link: file: "libGL", message: "file not found" > > It is supposed to work with or without the extension, however because > of limitations in the underlying lt_dlopenext function in libtool, > neither works. > I'd argue that using the second variant (or using `(dynamic-link "libGL.so")') is kinda inherently broken in an application loading general-use (public) shared libraries, as opposed to plugins specific to an application: you have no idea what ABI the library you just loaded has. This means you may later use of symbols from that library in a way that violates the ABI. Unfortunatly, how the ABI is encoded into the shared library name is platform-dependent, and this is also (as I read between the lines of the bug thread referenced by you [0]) one of the reasons why the libtool developers are not sure how a solution to this problem should look like. I think to write an application that is somewhat protected against ABI changes, you need to have a mapping from ABIs supported by your application to shared library file names (including the version extension). You might have only one supported ABI, but the mapping is still platform-dependent, so you have to either have a run-time or build/install-time switch choosing the appriopriate shared library name. Now, to make matters worse, you can't do that using libltdl, as you noticed: > The first doesn't work because contrary to its > documentation, lt_dlopenext doesn't always try loading > the bare filename first, without appending an extention. > Yes, this is a really annoying bug, and is what kept me from (trying to) port sbank[1] (a gobject-introspection binding) to Guile a few years back. In gobject-introspection, you get the full shared library file name, along with a machine-readable ABI description, but you can't open the shared library using the versioned name in Guile. [1] https://github.com/rotty/sbank > The second doesn't work because the versioned soname extension (.so.1) > isn't among the ones that lt_dlopenext tries to append. It does try the > unversioned extension (.so), but in Debian the unversioned symlink > is only available when the corresponding *-dev package is installed. > Yeah, but IMHO, this kind of use with a bare shared library name (without SONAME/ABI information) is already misguided in the first place, unless you have some other way of knowing the ABI. Debian and the likes not installing .so files (or .la files) by default only exposes the inherent potential breakage. [0] > Here is a related libtool bug report: https://debbugs.gnu.org/8976 > > Note that there are arguably two distinct issues: > (1) lt_dlopenext not trying the bare filename in all cases > (2) lt_dlopenext not trying versioned soname extensions. > > Obviously one way to address this would be to fix these two issues in > lt_dlopenext in libtool. > As mentioned, solving problem (2) is not a good idea IMO -- the versions are there for a reason, and you cannot (should not) guess them. > Alternatively, the (system foreign) module in guile could provide a > simple low-level wrapper around lt_dlopen, and possibly implement > the higher level functionality of `dynamic-link' (additional search > paths, guessing extensions etc.) in scheme. > +1 Regards, Rotty -- Andreas Rottmann --