(dynamic-link "libm") doesn't work on guile

(dynamic-link "libm") doesn't work on guile

[Alex Vong]

Hi people,


I got the following error message when trying to dlopen a shared library
in ~/guix-profile/bin/guile installed by guix:

scheme@(guile-user)> (dynamic-link "libm")
ERROR: In procedure dynamic-link:
ERROR: In procedure dynamic-link: file: "libm", message: "file not found"

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.


I think it is a guix-specific problem since /usr/bin/guile installed by
debian works fine:

scheme@(guile-user)> (dynamic-link "libm")
$1 = #<dynamic-object "libm">


Any idea?

Thanks,
Alex

Re: (dynamic-link "libm") doesn't work on guile

[Leo Famulari]

On Thu, Jan 07, 2016 at 06:36:14PM +0800, Alex Vong wrote:
> Hi people,
> 
> 
> I got the following error message when trying to dlopen a shared library
> in ~/guix-profile/bin/guile installed by guix:
> 
> scheme@(guile-user)> (dynamic-link "libm")
> ERROR: In procedure dynamic-link:
> ERROR: In procedure dynamic-link: file: "libm", message: "file not found"
> 
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> 
> 
> I think it is a guix-specific problem since /usr/bin/guile installed by
> debian works fine:
> 
> scheme@(guile-user)> (dynamic-link "libm")
> $1 = #<dynamic-object "libm">
> 
> 
> Any idea?

Usually when a Debian package works while the Guix package fails, I
examine the Debian packaging, especially the file at 'debian/rules'.

You can find those on the package web page [0] as the [...]debian.tar.xz
file and surely through some command-line tool.

[0] Make sure to select your Debian release (Jessie, Stretch, etc):
https://packages.debian.org/stretch/guile-2.0
> 
> Thanks,
> Alex
> 

Re: (dynamic-link "libm") doesn't work on guile

[Alex Vong]

Leo Famulari <leo@famulari.name> writes:

> On Thu, Jan 07, 2016 at 06:36:14PM +0800, Alex Vong wrote:
>> Hi people,
>> 
>> 
>> I got the following error message when trying to dlopen a shared library
>> in ~/guix-profile/bin/guile installed by guix:
>> 
>> scheme@(guile-user)> (dynamic-link "libm")
>> ERROR: In procedure dynamic-link:
>> ERROR: In procedure dynamic-link: file: "libm", message: "file not found"
>> 
>> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>> 
>> 
>> I think it is a guix-specific problem since /usr/bin/guile installed by
>> debian works fine:
>> 
>> scheme@(guile-user)> (dynamic-link "libm")
>> $1 = #<dynamic-object "libm">
>> 
>> 
>> Any idea?
>
> Usually when a Debian package works while the Guix package fails, I
> examine the Debian packaging, especially the file at 'debian/rules'.
>
> You can find those on the package web page [0] as the [...]debian.tar.xz
> file and surely through some command-line tool.
>
> [0] Make sure to select your Debian release (Jessie, Stretch, etc):
> https://packages.debian.org/stretch/guile-2.0

Thanks, but I think I am out of luck finding clues from the Debian
package. Btw, the source is also avaliable in
<https://sources.debian.net/src/guile-2.0/>, so no tarball downloading
is needed. Currently, the package page has no hyperlink pointing to it,
I think it should be added.

>> 
>> Thanks,
>> Alex
>> 

Re: (dynamic-link "libm") doesn't work on guile

[宋文武]

Alex Vong <alexvong1995@gmail.com> writes:

> Hi people,
>
>
> I got the following error message when trying to dlopen a shared library
> in ~/guix-profile/bin/guile installed by guix:
>
> scheme@(guile-user)> (dynamic-link "libm")
> ERROR: In procedure dynamic-link:
> ERROR: In procedure dynamic-link: file: "libm", message: "file not found"
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
>
>
> I think it is a guix-specific problem since /usr/bin/guile installed by
> debian works fine:
>
> scheme@(guile-user)> (dynamic-link "libm")
> $1 = #<dynamic-object "libm">
The `dynamic-link` will search and dlopen the shared library.  The guile
from guix doesn’t search common places like ‘/usr/lib’, so you need to
set the environment variable `LD_LIBRARY_PATH` or `LTDL_LIBRARY_PATH`
explicitly to the directory contains `libm.so`.

by the way, since guile is linked with libm.so, we can just use
`(dynamic-link)` here.

well, I also find `(dynamic-link "libm-2.22")` work too, but it doesn’t
seem to be what we want to use.

Re: (dynamic-link "libm") doesn't work on guile

[Ludovic Courtès]

iyzsong@member.fsf.org (宋文武) skribis:

> The `dynamic-link` will search and dlopen the shared library.  The guile
> from guix doesn’t search common places like ‘/usr/lib’, so you need to
> set the environment variable `LD_LIBRARY_PATH` or `LTDL_LIBRARY_PATH`
> explicitly to the directory contains `libm.so`.

‘LTDL_LIBRARY_PATH’ is safer in that it only affects software that uses
libltdl’s dlopen facility.

> by the way, since guile is linked with libm.so, we can just use
> `(dynamic-link)` here.

Yup!

Ludo’.

Re: (dynamic-link "libm") doesn't work on guile

[Alex Vong]

iyzsong@member.fsf.org (宋文武) writes:

> The `dynamic-link` will search and dlopen the shared library.  The guile
> from guix doesn’t search common places like ‘/usr/lib’, so you need to
> set the environment variable `LD_LIBRARY_PATH` or `LTDL_LIBRARY_PATH`
> explicitly to the directory contains `libm.so`.
>
> by the way, since guile is linked with libm.so, we can just use
> `(dynamic-link)` here.
>
> well, I also find `(dynamic-link "libm-2.22")` work too, but it doesn’t
> seem to be what we want to use.

I think it is weird. It seems only dynamic linking with "libc" or "libm"
fails, dynamic linking with external library like "libpcre2-8" or
anyhome-made shared library would work. And yes, "libc-2.22" and
"libm-2.22" also works for me. As you have mentioned, since guile is
already linked with "libc" and "libm", so it is pratically not a
problem. I am just wondering if it is a bug or the intended behavior.

Below are the selected output from running
`LD_DEBUG=all LD_LIBRARY_PATH="$HOME/.guix-profile/lib" guile`:

scheme@(guile-user)> (dynamic-link "libm")
     29677:	
     29677:	file=/home/alexvong1995/.guix-profile/lib/libm.so [0];  dynamically loaded by /home/alexvong1995/.guix-profile/lib/libltdl.so.7 [0]
     29677:	
     29677:	file=/gnu/store/5i87jzm90nw8j692y7z1j2qfx16h6ni3-guile-2.0.11/lib/libm.so [0];  dynamically loaded by /home/alexvong1995/.guix-profile/lib/libltdl.so.7 [0]
     29677:	
     29677:	file=/gnu/store/5i87jzm90nw8j692y7z1j2qfx16h6ni3-guile-2.0.11/lib/guile/2.0/extensions/libm.so [0];  dynamically loaded by /home/alexvong1995/.guix-profile/lib/libltdl.so.7 [0]
ERROR: In procedure dynamic-link:
ERROR: In procedure dynamic-link: file: "libm", message: "file not found"

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

scheme@(guile-user)> (dynamic-link "libc")
     29677:	
     29677:	file=/home/alexvong1995/.guix-profile/lib/libc.so [0];  dynamically loaded by /home/alexvong1995/.guix-profile/lib/libltdl.so.7 [0]
     29677:	
     29677:	file=/gnu/store/5i87jzm90nw8j692y7z1j2qfx16h6ni3-guile-2.0.11/lib/libc.so [0];  dynamically loaded by /home/alexvong1995/.guix-profile/lib/libltdl.so.7 [0]
     29677:	
     29677:	file=/gnu/store/5i87jzm90nw8j692y7z1j2qfx16h6ni3-guile-2.0.11/lib/guile/2.0/extensions/libc.so [0];  dynamically loaded by /home/alexvong1995/.guix-profile/lib/libltdl.so.7 [0]
ERROR: In procedure dynamic-link:
ERROR: In procedure dynamic-link: file: "libc", message: "file not found"

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.

Re: (dynamic-link "libm") doesn't work on guile

[Ludovic Courtès]

Alex Vong <alexvong1995@gmail.com> skribis:

> I think it is weird. It seems only dynamic linking with "libc" or "libm"
> fails, dynamic linking with external library like "libpcre2-8" or
> anyhome-made shared library would work. And yes, "libc-2.22" and
> "libm-2.22" also works for me.

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:

--8<---------------cut here---------------start------------->8---
$ 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 ) )
--8<---------------cut here---------------end--------------->8---

Ludo’.

Re: (dynamic-link "libm") doesn't work on guile

[Alex Vong]

ludo@gnu.org (Ludovic Courtès) writes:

> Alex Vong <alexvong1995@gmail.com> skribis:
>
>> I think it is weird. It seems only dynamic linking with "libc" or "libm"
>> fails, dynamic linking with external library like "libpcre2-8" or
>> anyhome-made shared library would work. And yes, "libc-2.22" and
>> "libm-2.22" also works for me.
>
> 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, while it is a
linker script in guix. That's why it is not working.

To understand the problem, I find this thread on the glibc mailing list
<https://sourceware.org/ml/libc-alpha/2011-07/msg00139.html>,
where the developer said ``no one is saying that dlopening the C library
is wrong, but we are saying that dlopening "libc.so" instead of
"libc.so.6" is wrong.``.

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?

> Ludo’.

Re: (dynamic-link "libm") doesn't work on guile

[Ludovic Courtès]

Alex Vong <alexvong1995@gmail.com> skribis:

> ludo@gnu.org (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.)

> 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

You’d make a lot of people happy by fixing libltdl.  ;-)

Thanks,
Ludo’.

Re: (dynamic-link "libm") doesn't work on guile

[Alex Vong]

ludo@gnu.org (Ludovic Courtès) writes:

> Alex Vong <alexvong1995@gmail.com> skribis:
>
>> ludo@gnu.org (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