From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Vong Subject: Re: (dynamic-link "libm") doesn't work on guile Date: Sun, 10 Jan 2016 14:05:44 +0800 Message-ID: <87bn8u9dfr.fsf@gmail.com> References: <87bn8x65i9.fsf@gmail.com> <87a8ogbvii.fsf@member.fsf.org> <87bn8w9r89.fsf@gmail.com> <87vb74ji1y.fsf@gnu.org> <87fuy6rgky.fsf@gmail.com> <87poxabqk6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aI98S-0002I8-07 for help-guix@gnu.org; Sun, 10 Jan 2016 01:05:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aI98O-0008C7-QW for help-guix@gnu.org; Sun, 10 Jan 2016 01:05:51 -0500 In-Reply-To: <87poxabqk6.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 09 Jan 2016 18:39:21 +0100") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: help-guix@gnu.org ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Alex Vong skribis: > >> ludo@gnu.org (Ludovic Court=C3=A8s) writes: > > [...] > >>> I think that=E2=80=99s because libm.so and libc.so are linker scripts, = whereas >>> libm-2.22.so and libc-2.22.so are the actual ELF files: >>> >>> $ cat ~/.guix-profile/lib/libm.so >>> /* GNU ld script >>> */ >>> OUTPUT_FORMAT(elf64-x86-64) >>> GROUP ( >>> /gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib/libm.so.6 >>> AS_NEEDED ( >>> /gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib/libmvec.so.1 >>> ) ) >>> $ cat ~/.guix-profile/lib/libc.so >>> /* GNU ld script >>> Use the shared library, but some functions are only in >>> the static library, so try that secondarily. */ >>> OUTPUT_FORMAT(elf64-x86-64) >>> GROUP ( >>> /gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib/libc.so.6 >>> /gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib/libc_nonshar= ed.a >>> AS_NEEDED ( >>> /gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib/ld-linux-x86= -64.so.2 >>> ) ) >>> >> I think you are right, libm.so is a binary file in Debian, > > That=E2=80=99s because Debian uses libc < 2.22 (libc 2.22 introduced libm= vec, > hence the linker script.) > I see, this is new to me. >> Is there way to specify an ABI version (I suppose 6 is the ABI version >> since we have libm.so.6) when dlopening a shared library to avoid this >> glitch? > > Unfortunately no, that=E2=80=99s a long-standing libltdl bug: > > https://lists.gnu.org/archive/html/guile-devel/2011-03/msg00021.html > https://lists.gnu.org/archive/html/bug-libtool/2011-03/msg00029.html > One of replies suggested making symlink pointing to the library you want to use and it works for me on Debian stable! (use-modules (system foreign)) (let* ((tmpd (pointer->string ((pointer->procedure '*=20 (dynamic-func "mkdtemp"= =20 (dynamic-l= ink)) '(*)) (string->pointer "/tmp/XXXXXX")))) (libc-path (string-append tmpd "/libc.so"))) (begin (symlink "/lib/x86_64-linux-gnu/libc.so.6" libc-path) (setenv "LTDL_LIBRARY_PATH" tmpd) (let ((libc (dynamic-link "libc"))) (delete-file libc-path) (rmdir tmpd) libc))) would return `$2 =3D #`. I use the more secure function `mkdtemp' to create temporary directory, but is it inheritedly dangerous to dynamic-link a symlink in /tmp? Does this count as a workaround? (It works once you know the absolute path of the shared library.) > You=E2=80=99d make a lot of people happy by fixing libltdl. ;-) > > Thanks, > Ludo=E2=80=99. Cheers, Alex