1 |
On 12/23/20 4:34 PM, Aisha Tammy wrote: |
2 |
> On 12/23/20 3:01 PM, Michael Orlitzky wrote: |
3 |
>> On 12/23/20 1:14 PM, Aisha Tammy wrote: |
4 |
>>> |
5 |
>>> I've recently had the same problem for TACC/Lmod which uses |
6 |
>>> autotools to get lua versions and lua.cpath and lua.path and did infact manage |
7 |
>>> to push the horrendously large patch upstream - |
8 |
>>> https://github.com/TACC/Lmod/commit/0913bf05dd7e8f478f69d5297e26d744ddb5073a |
9 |
>>> |
10 |
>>> Maybe something similar can work for your use case? |
11 |
>> |
12 |
>> Yes, patching the build system works. |
13 |
>> |
14 |
> |
15 |
> Ah, I was unclear. |
16 |
> I meant this kind of patch would not be something that |
17 |
> upstream will hate, as it is backwards compatible. |
18 |
> That's the biggest problem with creating large backwards |
19 |
> compatible patches >.< |
20 |
> |
21 |
>> |
22 |
>>> The problem with just using -L/path/to/lua/lib/ -llua would be loading |
23 |
>>> library at runtime, unless autotools is smart enough to actually change this |
24 |
>>> CFLAGs into a -Wl,-rpath,/path/to/lua/lib -L/path/to/lua/lib -llua. |
25 |
>>> I am not sure how intelligent autotools is to be able to do this or not. |
26 |
>>> |
27 |
>> |
28 |
>> We already add entries to /etc/ld.so.conf to make things like slotted LLVM work. |
29 |
>> |
30 |
> |
31 |
> Hmm, how would that work? |
32 |
> I have package A with a binary /usr/bin/binA linked to liblua51.so (which in |
33 |
> your suggestion would change to /usr/lib64/lua5.1/liblua.so) and |
34 |
> and /usr/bin/binB linked to liblua52.so (or /usr/lib64/lua5.2/liblua.so). |
35 |
> I don't see any ordering of /usr/lib64/lua5.1/ and /usr/lib64/lua5.2/ |
36 |
> that allows for binA and binB to find their correct lua libraries. |
37 |
> (This doesn't need to be for binaries, other shared libraries even) |
38 |
> |
39 |
> Admittedly, I am not a lua or linker expert... |
40 |
> |
41 |
> Aisha |
42 |
> |
43 |
> |
44 |
|
45 |
My intention with the suggestion was that the actual library be stored |
46 |
in /usr/lib64/liblua52.so (or whatever the appropriate name is), but a |
47 |
symlink used for linking be stored in /usr/lib64/lua5.2/liblua.so. When |
48 |
you pass "-L /usr/lib64/lua5.2 -llua" to the compiler, it will find the |
49 |
file /usr/lib64/lua5.2/liblua.so and read the DT_SONAME entry in it. |
50 |
That will cause the linker to store "liblua52.so" as a DT_NEEDED entry |
51 |
in the executable. At runtime, the runtime linker ld.so |
52 |
(/lib64/ld-linux-x86-64.so.2) will read the DT_NEEDED entry, and try to |
53 |
find the library liblua52.so, which is in /usr/lib64, so it will be |
54 |
found without any ld.so.conf tricks. This requires no special runtime |
55 |
support, as the actual name the compiler/linker will end up storing in |
56 |
the output contains the proper version. This means that if |
57 |
/usr/bin/binA linked to liblua51.so (via the linker finding |
58 |
/usr/lib64/lua5.1/liblua.so) and /usr/bin/binB linked to liblua52.so |
59 |
(likewise), they would both be able to find the correct libraries, as |
60 |
the DT_SONAMEs are different. |
61 |
|
62 |
Jonathan Callen |