Hi Linus, On Mon, 11 Jan 2021 15:24:44 +0200, Linus Vanas <linus@vanas.fi> wrote: > I've been working on packaging libstrangle: > https://salsa.debian.org/Huitsi/libstrangle > > The library is only meant to be used with LD_PRELOAD and not linked with > at build-time, but an upstream script assumes the lib is in the ld > search path. To my understanding of the policy, this would mean having > to comply with "8. Shared libraries" despite the library really not > being suited for it. I'd rather patch the script than make the library > comply with shared library policy but I'm unsure how to do that in a > multiarch-compatible way. > > Am I reading the situation correctly and if so, how should I solve it? I agree it would be better to patch the script. However you don’t have to make the package multiarch-compliant; you can install your library in a package-private directory, the same on all architectures, and leave it at that. That said, given that i386 libstrangle would be useful on amd64, alongside amd64 libstrangle, it might be better to look into the Rpath token expansions which are supported by ld.so in LD_PRELOAD, e.g. $PLATFORM — although it doesn’t fully match the multiarch requirements. (See man ld.so for details.) See olla for an example of a non-multiarch LD_PRELOAD library; it installs /etc/bash_completion.d/olla /etc/olla.conf /usr/lib/olla/libolla.so /usr/lib/olla/libolla.so.1 /usr/lib/olla/libolla.so.1.0 /usr/share/doc/olla/README.markdown /usr/share/doc/olla/changelog.gz /usr/share/doc/olla/copyright Regards, Stephen
Attachment:
pgpTPJou4QmPq.pgp
Description: OpenPGP digital signature