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

Re: How to determine the filename for dlopen()



Guillem Jover <guillem@debian.org> writes:

> On Mon, 2017-11-13 at 13:23:01 +0100, Ferenc Wágner wrote:
>
>> I'm packaging a program which wants to dlopen() some library.  It finds
>> this library via pkg-config (PKG_CHECK_MODULES).  How to best determine
>> the filename to use in the dlopen() call?  It should work cross-distro,
>> for cross-compilation and whatnot.  Is it always safe to use the SONAME
>> as the filename?  I'm currently considering something like
>> 
>> ld -shared -o dummy.so $(my_LIBS)
>> objdump -p dummy.so | fgrep NEEDED
>> 
>> coded up properly for Automake.  I'd be grateful for any insight.
>
> IMO dlopen()ing an external library that is not part of the same
> project is a practice that should be very strongly discouraged, if
> not completely abolished.
>
> Please see this very nice mail from Simon McVittie [S], my reply [G],
> and Florian Weimer's [F], for several of the reasons why.
>
>  [S] https://lists.debian.org/debian-devel/2017/03/msg00164.html
>  [G] https://lists.debian.org/debian-devel/2017/03/msg00343.html
>  [F] https://lists.debian.org/debian-devel/2017/03/msg00346.html

Thanks for pointing out this discussion, Guillem.  Fortunately, most of
those points are already taken care of in upstream: they took my patches
exposing the full set of used symbols in throwaway binaries, which I can
process with dpkg-shlibdeps.  SONAMEs are also determined automatically
(though this seems somewhat fragile).  Portability beyond BSDs isn't a
concern either.  Still, the "pedantically correct" way has some appeal,
I'll probably look into implementing it.  At least I can't see any other
way to express alternative groups of library dependencies like ((libnss
and libnspr) or libssl), which would be needed for crypto plugins.
Symbol versioning is neglected as well, as pointed out by Florian.  The
downside is the proliferation of small plugin binary packages.

BTW what are "shared libraries that define themselves to the ABI and
SONAME level" you mention?  Do you mean libraries which expose their
SONAMEs like the various libc compnents do in lib-names.h?
-- 
Thanks,
Feri


Reply to: