Gentoo Archives: gentoo-dev

From: "Robin H. Johnson" <robbat2@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime
Date: Sun, 05 Jan 2014 04:09:20
1 Summary:
2 --------
3 gen_ld_script is removing a vital unversioned symlink from some packages, and
4 this breaks libtool lt_dlopenext consumers at runtime.
6 Details:
7 --------
8 While examining bug #486640, I discovered a concerning interaction [1] between
9 libtool's lt_dlopenext and gen_ld_script.
11 I don't have a good handle on how many packages are affected, but it would be
12 an code that uses lt_dlopenext to try and find a library.
14 For our example, we're using the fact that sys-power/nut wants to use libusb
15 from dev-libs/libusb-compat.
17 dev-libs/libusb-compat has these files:
18 /usr/lib64/ (from gen_ld_script)
19 /lib64/
20 /lib64/ (symlink to 4.4.4)
22 lt_dlopenext is given the basename of a library to find. In this case, the
23 (modified) code tries both libusb and libusb-0.1, with slightly different failures:
25 1. lt_dlopenext cannot parse linker scripts at all, so the from
26 gen_ld_script cannot be opened.
27 2. lt_dlopenext only tries to append .so, it doesn't add version specifiers.
29 If I manually add a symlink:
30 /lib64/ -> /lib64/
31 then lt_dlopenext succeeds.
33 This led me to looking at the libusb-compat in more detail.
34 Before gen_ld_script runs, it has the library and two symlinks in /usr/lib64:
35 /usr/lib64/
36 /usr/lib64/ (symlink)
37 /usr/lib64/ (symlink)
38 At this stage, lt_dlopenext works still.
40 Now after gen_ld_script, the unversioned symlink is replaced by a linker
41 script. The versioned symlink and base file have moved to /lib64.
43 Since lt_dlopenext cannot handle the linker script, and the unversioned symlink
44 is gone, we now get a failure.
46 Proposed Fix:
47 -------------
48 I would like to propose that gen_ld_script does NOT remove the unversioned
49 symlinks, but instead moves them along with the versioned symlinks.
51 Questions:
52 ----------
53 How can we sanely get all user systems updated for this subtle bug?
56 ---------
57 In bug #4411, comment 43, vapier noted:
58 > any package that does dlopen("") without the version info like ".so.X" is broken.
59 In this case, the lt_dlopenext consumer is explicitly testing multiple versions
60 of libusb at runtime, and picking the correct interface: it doesn't need to
61 depend on a specific version. This is also because the lt_dlopenext interface
62 does NOT accepted files versioned after the .so: it needs the filename with no
63 extensions.
65 [1] I do half-expect vapier, flameeyes or patrick to shoot me down, and tell me
66 the package is doing something wrong, but I've also got a chance of this
67 actually being a system breakage.
69 --
70 Robin Hugh Johnson
71 Gentoo Linux: Developer, Infrastructure Lead
72 E-Mail : robbat2@g.o
73 GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85