[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49232: load-foreign-library does not find versioned .so files

From: Sören Tempel
Subject: bug#49232: load-foreign-library does not find versioned .so files
Date: Sat, 26 Jun 2021 13:37:31 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (berkeley-unix)


Many Linux distributions (e.g. Alpine Linux and Debian) split packages
into multiple subpackages. For instance, library development headers are
usually separated from .so files since the former are commonly not
needed as a run-time dependency. As part of this split, only versioned
sonames are commonly provided by library packages (e.g.
libexample.so.4.2.0), the symbolic link to the current .so (e.g.
libexample.so -> libexample.so.4.2.0) is provided in a separate
development subpackage for every library. This is done to ensure that
the unversioned .so symbolic link is only used during compilation, for
loading purposes a versioned .so name should always be used. This eases
rebuilding packages on ABI changes (i.e. soname version bumps).

Many scripting languages, e.g. python, implement a fuzzy search in their
FFI library to also match .so files with version numbers [1].
Unfortunately, guile's load-foreign-library does not do so. That is,
(load-foreign-library "libexample") will only match libexample.so but
not libexample.so.4.2.0. As a consequence, guile packages using FFI will
always require a run-time dependency on development subpackages
(including headers), only for the .so symbolic link, which is very
inconvenient for us at Alpine [2].

Would it be possible to modify load-foreign-library to also match .so
file names with a version postfix (like python does for instance)?

Please CC me, I am not subscribed to the list.


[2]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12783

reply via email to

[Prev in Thread] Current Thread [Next in Thread]