Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve

[Jaco Kroon]

Hi,
>> Hmm, how would that work?
>> I have package A with a binary /usr/bin/binA linked to liblua51.so (which in
>> your suggestion would change to /usr/lib64/lua5.1/liblua.so) and
>> and /usr/bin/binB linked to liblua52.so (or /usr/lib64/lua5.2/liblua.so).
>> I don't see any ordering of /usr/lib64/lua5.1/ and /usr/lib64/lua5.2/
>> that allows for binA and binB to find their correct lua libraries.
>> (This doesn't need to be for binaries, other shared libraries even)
>>
>> Admittedly, I am not a lua or linker expert...
>>
>> Aisha
>>
>>
> My intention with the suggestion was that the actual library be stored
> in /usr/lib64/liblua52.so (or whatever the appropriate name is), but a
> symlink used for linking be stored in /usr/lib64/lua5.2/liblua.so.  When
> you pass "-L /usr/lib64/lua5.2 -llua" to the compiler, it will find the
> file /usr/lib64/lua5.2/liblua.so and read the DT_SONAME entry in it.
> That will cause the linker to store "liblua52.so" as a DT_NEEDED entry
> in the executable.  At runtime, the runtime linker ld.so
> (/lib64/ld-linux-x86-64.so.2) will read the DT_NEEDED entry, and try to
> find the library liblua52.so, which is in /usr/lib64, so it will be
> found without any ld.so.conf tricks.  This requires no special runtime
> support, as the actual name the compiler/linker will end up storing in
> the output contains the proper version.  This means that if
> /usr/bin/binA linked to liblua51.so (via the linker finding
> /usr/lib64/lua5.1/liblua.so) and /usr/bin/binB linked to liblua52.so
> (likewise), they would both be able to find the correct libraries, as
> the DT_SONAMEs are different.
net-misc/asterisk don't need this (any more,
https://gerrit.asterisk.org/c/asterisk/+/15234), but I'd be in support
of something like this as a general "pattern", both for lua as well as
other SLOT'ed libs.  I might suggest that /usr/lib64/lua5.x/ is perhaps
not the most ideal location, since include headers needs to match too
... and most of these ./configure type things just take --with-lua=PATH
and I think assume $PATH/include + $PATH/lib{,32,64} ... granted they
also allow for additional LUA_INCLUDE environment variables in *some* cases.

So perhaps something we can learn from the "scripting" world ...

/usr/pkgslots/${pkgname}/${version}/{include,lib64,lib32} kind of thing,
with as few as possible actual directories, preferring symlinks and
definitely no files ever.

So for lua5.1, this would be something like:

/usr/pkgslots/lua/5.1/
   include => /usr/include/lua5.1
   for X in so{,.0,.0.0.0} a la:
       lib{32,64}/liblua.$X => /usr/lib{32,64}/liblua5.1.$X

This might be worth an eclass (which I'd love to take a shot at,
probably with LOADS of help) if there is general interest in making this
a kind of pattern.

Having said all of that, I tend to agree that ./configure should as a
rule try to use pkgconfig whenever and wherever possible.

Kind Regards,
Jaco