| 1 |
On Sun, Jan 05, 2014 at 04:09:12AM +0000, Robin H. Johnson wrote: |
| 2 |
> Summary: |
| 3 |
> -------- |
| 4 |
> gen_ld_script is removing a vital unversioned symlink from some packages, and |
| 5 |
> this breaks libtool lt_dlopenext consumers at runtime. |
| 6 |
|
| 7 |
> lt_dlopenext is given the basename of a library to find. In this case, the |
| 8 |
> (modified) code tries both libusb and libusb-0.1, with slightly different failures: |
| 9 |
> |
| 10 |
> 1. lt_dlopenext cannot parse linker scripts at all, so the libusb.so from |
| 11 |
> gen_ld_script cannot be opened. |
| 12 |
> 2. lt_dlopenext only tries to append .so, it doesn't add version specifiers. |
| 13 |
> |
| 14 |
> If I manually add a symlink: |
| 15 |
> /lib64/libusb-0.1.so -> /lib64/libusb-0.1.so.4 |
| 16 |
> then lt_dlopenext succeeds. |
| 17 |
|
| 18 |
> Before gen_ld_script runs, it has the library and two symlinks in /usr/lib64: |
| 19 |
> /usr/lib64/libusb-0.1.so.4.4.4 |
| 20 |
> /usr/lib64/libusb-0.1.so.4 (symlink) |
| 21 |
> /usr/lib64/libusb.so (symlink) |
| 22 |
> At this stage, lt_dlopenext works still. |
| 23 |
> |
| 24 |
> Now after gen_ld_script, the unversioned symlink is replaced by a linker |
| 25 |
> script. The versioned symlink and base file have moved to /lib64. |
| 26 |
|
| 27 |
> /usr/lib64/libusb.so (from gen_ld_script) |
| 28 |
> /lib64/libusb-0.1.so.4.4.4 |
| 29 |
> /lib64/libusb-0.1.so.4 (symlink to 4.4.4) |
| 30 |
|
| 31 |
> Since lt_dlopenext cannot handle the linker script, and the unversioned symlink |
| 32 |
> is gone, we now get a failure. |
| 33 |
> |
| 34 |
> Proposed Fix: |
| 35 |
> ------------- |
| 36 |
> I would like to propose that gen_ld_script does NOT remove the unversioned |
| 37 |
> symlinks, but instead moves them along with the versioned symlinks. |
| 38 |
|
| 39 |
Agreed, a minor change to what it does which makes a lot of sense, meaning |
| 40 |
/lib is consistent with what was installed, and the script remains in /usr. |
| 41 |
|
| 42 |
I concur also that static archives belong in /usr; they're only used at |
| 43 |
link-time. The only thing I'd ask is whether we can't just install libs |
| 44 |
to /lib as WilliamH suggested, and then move the static ones instead in |
| 45 |
the image, before emerge makes a pkg. |
| 46 |
|
| 47 |
I don't know what libtool's up to with *.la ofc, but I thought we stopped |
| 48 |
installing those a while back? Or it may just be that people mask them. |
| 49 |
|
| 50 |
> [1] I do half-expect vapier, flameeyes or patrick to shoot me down, and tell me |
| 51 |
> the package is doing something wrong, but I've also got a chance of this |
| 52 |
> actually being a system breakage. |
| 53 |
|
| 54 |
The thing that troubles me is no symlink being installed for 0.1.so - I thought |
| 55 |
that was required. Doesn't affect that your proposed change is an improvement, |
| 56 |
though, and should definitely go ahead, imo. |
| 57 |
|
| 58 |
Regards, |
| 59 |
steveL. |
| 60 |
-- |
| 61 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |
Archives