On 12/23/20 4:34 PM, Aisha Tammy wrote: > On 12/23/20 3:01 PM, Michael Orlitzky wrote: >> On 12/23/20 1:14 PM, Aisha Tammy wrote: >>> >>> I've recently had the same problem for TACC/Lmod which uses >>> autotools to get lua versions and lua.cpath and lua.path and did infact >>> manage >>> to push the horrendously large patch upstream - >>> https://github.com/TACC/Lmod/commit/0913bf05dd7e8f478f69d5297e26d744ddb5073a >>> >>> Maybe something similar can work for your use case? >> >> Yes, patching the build system works. >> > > Ah, I was unclear. > I meant this kind of patch would not be something that > upstream will hate, as it is backwards compatible. > That's the biggest problem with creating large backwards > compatible patches >.< > >> >>> The problem with just using -L/path/to/lua/lib/ -llua would be loading >>> library at runtime, unless autotools is smart enough to actually change this >>> CFLAGs into a -Wl,-rpath,/path/to/lua/lib -L/path/to/lua/lib -llua. >>> I am not sure how intelligent autotools is to be able to do this or not. >>> >> >> We already add entries to /etc/ld.so.conf to make things like slotted LLVM >> work. >> > > 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. Jonathan Callen
