[email protected] (Ludovic Courtès) writes: > Alex Vong <[email protected]> skribis: > >> [email protected] (Ludovic Courtès) writes: > > [...] > >>> I think that’s 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_nonshared.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’s because Debian uses libc < 2.22 (libc 2.22 introduced libmvec, > 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’s 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 '* (dynamic-func "mkdtemp" (dynamic-link)) '(*)) (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 = #<dynamic-object "libc">`. 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’d make a lot of people happy by fixing libltdl. ;-) > > Thanks, > Ludo’. Cheers, Alex
