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
