unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: "Sören Tempel" <soeren@soeren-tempel.net>
To: 49232@debbugs.gnu.org
Subject: bug#49232: load-foreign-library does not find versioned .so files
Date: Sat, 26 Jun 2021 13:37:31 +0200	[thread overview]
Message-ID: <23TGNISPS9PPL.2YOENNQD9V56X@8pit.net> (raw)

Hello,

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.

Greetings,
Sören

[1]: https://docs.python.org/3/library/ctypes.html?highlight=find_library#ctypes.util.find_library
[2]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12783





             reply	other threads:[~2021-06-26 11:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-26 11:37 Sören Tempel [this message]
2022-07-23 11:09 ` [PATCH] load-foreign-library: perform substring match on library files soeren
2022-07-23 13:17   ` Maxime Devos
2022-07-24 12:16     ` Sören Tempel
2022-08-20 13:52       ` Sören Tempel
2022-08-20 18:30         ` bug#49232: " Maxime Devos
2022-08-20 18:30       ` Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=23TGNISPS9PPL.2YOENNQD9V56X@8pit.net \
    --to=soeren@soeren-tempel.net \
    --cc=49232@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).