1 |
On 12/23/20 3:01 PM, Michael Orlitzky wrote: |
2 |
> On 12/23/20 1:14 PM, Aisha Tammy wrote: |
3 |
>> |
4 |
>> I've recently had the same problem for TACC/Lmod which uses |
5 |
>> autotools to get lua versions and lua.cpath and lua.path and did infact manage |
6 |
>> to push the horrendously large patch upstream - |
7 |
>> https://github.com/TACC/Lmod/commit/0913bf05dd7e8f478f69d5297e26d744ddb5073a |
8 |
>> |
9 |
>> Maybe something similar can work for your use case? |
10 |
> |
11 |
> Yes, patching the build system works. |
12 |
> |
13 |
|
14 |
Ah, I was unclear. |
15 |
I meant this kind of patch would not be something that |
16 |
upstream will hate, as it is backwards compatible. |
17 |
That's the biggest problem with creating large backwards |
18 |
compatible patches >.< |
19 |
|
20 |
> |
21 |
>> The problem with just using -L/path/to/lua/lib/ -llua would be loading |
22 |
>> library at runtime, unless autotools is smart enough to actually change this |
23 |
>> CFLAGs into a -Wl,-rpath,/path/to/lua/lib -L/path/to/lua/lib -llua. |
24 |
>> I am not sure how intelligent autotools is to be able to do this or not. |
25 |
>> |
26 |
> |
27 |
> We already add entries to /etc/ld.so.conf to make things like slotted LLVM work. |
28 |
> |
29 |
|
30 |
Hmm, how would that work? |
31 |
I have package A with a binary /usr/bin/binA linked to liblua51.so (which in |
32 |
your suggestion would change to /usr/lib64/lua5.1/liblua.so) and |
33 |
and /usr/bin/binB linked to liblua52.so (or /usr/lib64/lua5.2/liblua.so). |
34 |
I don't see any ordering of /usr/lib64/lua5.1/ and /usr/lib64/lua5.2/ |
35 |
that allows for binA and binB to find their correct lua libraries. |
36 |
(This doesn't need to be for binaries, other shared libraries even) |
37 |
|
38 |
Admittedly, I am not a lua or linker expert... |
39 |
|
40 |
Aisha |