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
