On Thu, 09 Jun 2022 at 13:03:25 +0500, Andrey Rahmatullin wrote:
> The normal way for this is putting it into
> /usr/lib/<triplet>/pkgname/foo.so, and according to the code below you'll
> need the full path at the run time so you indeed need the triplet at both
> build and run time.
You can do something like
handle = dlopen("/usr/${LIB}/pkgname/foo.so", flags);
(that's a literal string passed to dlopen!) and ld.so/libdl will expand
${LIB} at runtime to the token that was configured into our glibc, which
in Debian's case is "lib/x86_64-linux-gnu" or similar. On non-Debian
distributions, ${LIB} typically expands to "lib64" or "lib32" or "lib"
instead, whichever one is most appropriate for the architecture and the
distro's layout.
Then you'd install the private library into what Autotools would refer to
as ${libdir}/pkgname/foo.so (adjust as necessary for other build systems)
and it will usually end up in the correct place. This assumes that
${libdir} is configured to something like
${exec_prefix}/lib/x86_64-linux-gnu or ${exec_prefix}/lib64 as appropriate
for the distribution, but that's normally true anyway, and in particular
should be true in debhelper.
Replace /usr with the ${exec_prefix} determined at compile-time if you
want to send code upstream that supports custom installation prefixes.
(Historical note: this is broken on ancient/EOL versions of Debian and
maybe some of the Extended Security Maintenance versions of Ubuntu,
where ${LIB} mistakenly expanded to the multiarch tuple without the
"lib/" prefix. Non-FHS distributions like Exherbo and NixOS might also
need to adjust it a bit, but they have to adjust everything else anyway,
so they should be used to that...)
smcv
