| 1 |
<snip> |
| 2 |
>> |
| 3 |
>> |
| 4 |
> |
| 5 |
> My intention with the suggestion was that the actual library be stored |
| 6 |
> in /usr/lib64/liblua52.so (or whatever the appropriate name is), but a |
| 7 |
> symlink used for linking be stored in /usr/lib64/lua5.2/liblua.so. When |
| 8 |
> you pass "-L /usr/lib64/lua5.2 -llua" to the compiler, it will find the |
| 9 |
> file /usr/lib64/lua5.2/liblua.so and read the DT_SONAME entry in it. |
| 10 |
> That will cause the linker to store "liblua52.so" as a DT_NEEDED entry |
| 11 |
> in the executable. At runtime, the runtime linker ld.so |
| 12 |
> (/lib64/ld-linux-x86-64.so.2) will read the DT_NEEDED entry, and try to |
| 13 |
> find the library liblua52.so, which is in /usr/lib64, so it will be |
| 14 |
> found without any ld.so.conf tricks. This requires no special runtime |
| 15 |
> support, as the actual name the compiler/linker will end up storing in |
| 16 |
> the output contains the proper version. This means that if |
| 17 |
> /usr/bin/binA linked to liblua51.so (via the linker finding |
| 18 |
> /usr/lib64/lua5.1/liblua.so) and /usr/bin/binB linked to liblua52.so |
| 19 |
> (likewise), they would both be able to find the correct libraries, as |
| 20 |
> the DT_SONAMEs are different. |
| 21 |
> |
| 22 |
> Jonathan Callen |
| 23 |
> |
| 24 |
|
| 25 |
Yes, this sounds doable and should work! |
| 26 |
|
| 27 |
Only problem is that if there is an actual liblua.so with the proper |
| 28 |
SONAME available in /usr/lib64 (I dunno if Gentoo has any provider of |
| 29 |
liblua.so with that SONAME, IIRC SLOT=0 currently does that) then it |
| 30 |
will ignore the wrong SONAMEd even with the -L/usr/lib64/lua5.2/ |
| 31 |
|
| 32 |
Aisha |
Archives