[gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime

[gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime

[Robin H. Johnson]

Summary:
--------
gen_ld_script is removing a vital unversioned symlink from some packages, and
this breaks libtool lt_dlopenext consumers at runtime.

Details:
--------
While examining bug #486640, I discovered a concerning interaction [1] between
libtool's lt_dlopenext and gen_ld_script.

I don't have a good handle on how many packages are affected, but it would be
an code that uses lt_dlopenext to try and find a library.

For our example, we're using the fact that sys-power/nut wants to use libusb
from dev-libs/libusb-compat.

dev-libs/libusb-compat has these files:
/usr/lib64/libusb.so  (from gen_ld_script)
/lib64/libusb-0.1.so.4.4.4
/lib64/libusb-0.1.so.4 (symlink to 4.4.4)

lt_dlopenext is given the basename of a library to find. In this case, the
(modified) code tries both libusb and libusb-0.1, with slightly different failures:

1. lt_dlopenext cannot parse linker scripts at all, so the libusb.so from
   gen_ld_script cannot be opened.
2. lt_dlopenext only tries to append .so, it doesn't add version specifiers.

If I manually add a symlink:
/lib64/libusb-0.1.so -> /lib64/libusb-0.1.so.4
then lt_dlopenext succeeds.

This led me to looking at the libusb-compat in more detail.
Before gen_ld_script runs, it has the library and two symlinks in /usr/lib64:
/usr/lib64/libusb-0.1.so.4.4.4
/usr/lib64/libusb-0.1.so.4 (symlink)
/usr/lib64/libusb.so (symlink)
At this stage, lt_dlopenext works still.

Now after gen_ld_script, the unversioned symlink is replaced by a linker
script. The versioned symlink and base file have moved to /lib64.

Since lt_dlopenext cannot handle the linker script, and the unversioned symlink
is gone, we now get a failure.

Proposed Fix:
-------------
I would like to propose that gen_ld_script does NOT remove the unversioned
symlinks, but instead moves them along with the versioned symlinks.

Questions:
----------
How can we sanely get all user systems updated for this subtle bug?

Comments:
---------
In bug #4411, comment 43, vapier noted:
> any package that does dlopen("libfoo.so") without the version info like ".so.X" is broken.
In this case, the lt_dlopenext consumer is explicitly testing multiple versions
of libusb at runtime, and picking the correct interface: it doesn't need to
depend on a specific version. This is also because the lt_dlopenext interface
does NOT accepted files versioned after the .so: it needs the filename with no
extensions.

[1] I do half-expect vapier, flameeyes or patrick to shoot me down, and tell me
the package is doing something wrong, but I've also got a chance of this
actually being a system breakage.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

The reason that gen_usr_ldscript exists is that we  do not install
static libraries in /. I think the argument for this is that they
aren't needed at boot time. I would agree that they are not, but, given
all of the issues we have had in the past with gen_usr_ldscript, and
that issues keep coming up with it, I would like to propose something
different.

I would like to propose that we stop splitting the installation
locations of libraries and use the upstream build systems to install the
libraries where we want them. If we do that, it means we could get rid
of gen_usr_ldscript completely.

We could start doing this today, except that portage has a hard ban
against installing static libraries in /, which I have opened up a bug
about [1]. I don't know when or why the hard ban was introduced, but I'm sure
it was pre-2004 and pre-council.

The down side of doing this that I see would be that people who have
static-libs in their use flags might have / too small to have the static
libs installed there.

Thoughts?

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=492542

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime

[Robin H. Johnson]

On Mon, Jan 06, 2014 at 01:23:53PM -0600, William Hubbs wrote:
> The reason that gen_usr_ldscript exists is that we  do not install
> static libraries in /. I think the argument for this is that they
> aren't needed at boot time. I would agree that they are not, but, given
> all of the issues we have had in the past with gen_usr_ldscript, and
> that issues keep coming up with it, I would like to propose something
> different.
I know the original purpose of gen_usr_ldscript. I'm objecting to the
fact that it removes a critical symlink entirely (instead of moving it).

I was a Gentoo user when gen_usr_ldscript was introduced, and it
certainly helped then for keeping cleaner installs. I don't want it
removed, just improved slightly.

> I would like to propose that we stop splitting the installation
> locations of libraries and use the upstream build systems to install the
> libraries where we want them. If we do that, it means we could get rid
> of gen_usr_ldscript completely.
I'm against that one, for bloat of /. If we ever fully merge /usr and /
like other distros have done, then it will become moot, but not before
then.

> We could start doing this today, except that portage has a hard ban
> against installing static libraries in /, which I have opened up a bug
> about [1]. I don't know when or why the hard ban was introduced, but I'm sure
> it was pre-2004 and pre-council.
I think it was late 2002.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[gentoo-dev] Re: libtool lt_dlopenext vs. gen_ld_script: breakages at runtime

[Steven J. Long]

On Sun, Jan 05, 2014 at 04:09:12AM +0000, Robin H. Johnson wrote:
> Summary:
> --------
> gen_ld_script is removing a vital unversioned symlink from some packages, and
> this breaks libtool lt_dlopenext consumers at runtime.

> lt_dlopenext is given the basename of a library to find. In this case, the
> (modified) code tries both libusb and libusb-0.1, with slightly different failures:
> 
> 1. lt_dlopenext cannot parse linker scripts at all, so the libusb.so from
>    gen_ld_script cannot be opened.
> 2. lt_dlopenext only tries to append .so, it doesn't add version specifiers.
> 
> If I manually add a symlink:
> /lib64/libusb-0.1.so -> /lib64/libusb-0.1.so.4
> then lt_dlopenext succeeds.

> Before gen_ld_script runs, it has the library and two symlinks in /usr/lib64:
> /usr/lib64/libusb-0.1.so.4.4.4
> /usr/lib64/libusb-0.1.so.4 (symlink)
> /usr/lib64/libusb.so (symlink)
> At this stage, lt_dlopenext works still.
> 
> Now after gen_ld_script, the unversioned symlink is replaced by a linker
> script. The versioned symlink and base file have moved to /lib64.

> /usr/lib64/libusb.so  (from gen_ld_script)
> /lib64/libusb-0.1.so.4.4.4
> /lib64/libusb-0.1.so.4 (symlink to 4.4.4)

> Since lt_dlopenext cannot handle the linker script, and the unversioned symlink
> is gone, we now get a failure.
> 
> Proposed Fix:
> -------------
> I would like to propose that gen_ld_script does NOT remove the unversioned
> symlinks, but instead moves them along with the versioned symlinks.

Agreed, a minor change to what it does which makes a lot of sense, meaning
/lib is consistent with what was installed, and the script remains in /usr.

I concur also that static archives belong in /usr; they're only used at
link-time. The only thing I'd ask is whether we can't just install libs
to /lib as WilliamH suggested, and then move the static ones instead in
the image, before emerge makes a pkg.

I don't know what libtool's up to with *.la ofc, but I thought we stopped
installing those a while back? Or it may just be that people mask them.

> [1] I do half-expect vapier, flameeyes or patrick to shoot me down, and tell me
> the package is doing something wrong, but I've also got a chance of this
> actually being a system breakage.

The thing that troubles me is no symlink being installed for 0.1.so - I thought
that was required. Doesn't affect that your proposed change is an improvement,
though, and should definitely go ahead, imo.

Regards,
steveL.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime

[Peter Stuge]

Robin H. Johnson wrote:
> Comments:
> ---------
> In bug #4411, comment 43, vapier noted:
> > any package that does dlopen("libfoo.so") without the version info like ".so.X" is broken.
> In this case, the lt_dlopenext consumer is explicitly testing multiple
> versions of libusb at runtime, and picking the correct interface:
> it doesn't need to depend on a specific version.

vapier is still correct and the consumer is indeed broken, it does
too need to specify the .so version in the dlopen() call, at least
in the case of libusb.

It's fine for programs to try to dlopen() API providers for both
libusb-0.1 and libusb-1.0 APIs and use whichever they find, but that
MUST be done by full filename including ABI version in each call.

dev-libs/libusb-0.1 has only ever existed as libusb-0.1.so.4.4.4 so
either that or libusb-0.1.so.4 is what must be used with dlopen().

libusb-1.0 API providers are by design API as well as ABI incompatible
with libusb-0.1 so there is no way to get libusb-1.0 if you ask for
libusb-0.1.

I believe that libusb-0.1 being the way it is happened by accident
and I know that libusb-1.0 use of libtool is better but can still
improve.


> This is also because the lt_dlopenext interface does NOT accepted
> files versioned after the .so: it needs the filename with no extensions.

Hm, that seems limited?


//Peter

Re: [gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime

[Robin H. Johnson]

On Wed, Jan 08, 2014 at 09:14:43PM +0100, Peter Stuge wrote:
> Robin H. Johnson wrote:
> > Comments:
> > ---------
> > In bug #4411, comment 43, vapier noted:
> > > any package that does dlopen("libfoo.so") without the version info like ".so.X" is broken.
> > In this case, the lt_dlopenext consumer is explicitly testing multiple
> > versions of libusb at runtime, and picking the correct interface:
> > it doesn't need to depend on a specific version.
> vapier is still correct and the consumer is indeed broken, it does
> too need to specify the .so version in the dlopen() call, at least
> in the case of libusb.
> > This is also because the lt_dlopenext interface does NOT accepted
> > files versioned after the .so: it needs the filename with no extensions.
> Hm, that seems limited?
It's NOT calling dlopen directly. It's calling the lt_dlopenext
interface from libtool. That iterates over the possible combinations
that end with ".so", and never iterates over the numbered suffixes.

lt_dlforeachfile actully complicates it even more, but also doesn't see
the numbered suffixes.

So should you're saying that we need to change libtool's code now?

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/08/2014 03:27 PM, Robin H. Johnson wrote:
> On Wed, Jan 08, 2014 at 09:14:43PM +0100, Peter Stuge wrote:
>> Robin H. Johnson wrote:
>>> Comments:
>>> ---------
>>> In bug #4411, comment 43, vapier noted:
>>>> any package that does dlopen("libfoo.so") without the version info like ".so.X" is broken.
>>> In this case, the lt_dlopenext consumer is explicitly testing multiple
>>> versions of libusb at runtime, and picking the correct interface:
>>> it doesn't need to depend on a specific version.
>> vapier is still correct and the consumer is indeed broken, it does
>> too need to specify the .so version in the dlopen() call, at least
>> in the case of libusb.
>>> This is also because the lt_dlopenext interface does NOT accepted
>>> files versioned after the .so: it needs the filename with no extensions.
>> Hm, that seems limited?
> It's NOT calling dlopen directly. It's calling the lt_dlopenext
> interface from libtool. That iterates over the possible combinations
> that end with ".so", and never iterates over the numbered suffixes.
> 
> lt_dlforeachfile actully complicates it even more, but also doesn't see
> the numbered suffixes.
> 
> So should you're saying that we need to change libtool's code now?
> 

Or we could just stop randomly moving libs across the system and
breaking things then hackmeating things back to a "working" state with
gen_ld_script.

The whole reason for having gen_ld_script is because people wanted
dynamic libs in / and static libs in /usr (which seems insane) and it
broke everything (because that idea is insane).  Maybe we could just
install all the libs together (either / or /usr) and stop pretending
that what we are doing isn't wrong?

Just my 0.02$

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSzbhaAAoJEKXdFCfdEflKsJ4QAIhT02bWH1FxtZG5ALMQcEmr
tnj9YeulX5zp7NCaX+k4MfUn/VgSCAlcjPcWhJW2D2nYIhAFs8uUUb75jhgaFiOr
CIE5PamUE4FeE5NJ3tp2W2T+OXECmo0D0FUBg1ceDBadXDHncwjHS7Go3jTKdcsP
BgVTda3kigoN2BTfj4Gd8WBL2qFMFbRSQlZ9RcmiWTKCNTRvp2bMovgCMpOSgTwg
wIozmzaBTcYJH3TVC2p+Vkf0EZI00nMHAsLVyI/hbT97YVAxZWJG7N5UayK6IxBs
zUxREifT8ZEDXliWuJLBIa6S6HiujViZeKty/1axuMPonM7oEBXeGKS6dT1IJz3J
Hq1HEdccu66rfY1q8BakbKoR4SH2jeQhjP3Uaf/1NXb0sTRRqd7M9rnoTgmMMTfk
HQw8iUWgrHoEkE/VV/2L8kAVAdYPP+Igpyqobib+2gLD6wiufCXRUog0jGtYMCZA
wmGi43zWbXSqDhZ8tsyFLaHVbSqBlNRdiSW3XDB4hIrrveEF4++Cd0ecl3VIyXii
gGxSNJajZxGXtDwQer2dF15J8GSi6inZ+ZJLSj30EcTnPzsLcdcZItnE9m/getQs
3OMMDqnTvfYw/HrT9xcnOhg+YP2+NuufpOXXbQTbJXyQm0uDn6iFKIXVUPhek9R7
SEtDxmqBYrL95+c9IvQq
=8D0j
-----END PGP SIGNATURE-----

[gentoo-dev] Re: libtool lt_dlopenext vs. gen_ld_script: breakages at runtime

[Steven J. Long]

On Wed, Jan 08, 2014, Rick "Zero_Chaos" Farina wrote:
> Or we could just stop randomly moving libs across the system and
> breaking things then hackmeating things back to a "working" state with
> gen_ld_script.
> 
> The whole reason for having gen_ld_script is because people wanted
> dynamic libs in / and static libs in /usr (which seems insane) and it
> broke everything (because that idea is insane).

No it's not: it makes no sense whatsoever to have static libs in /; they
can only ever be used when one is compiling software, so by definition
have /usr available. And moving a dynamic lib is perfectly fine in terms
of the system running. That's what /etc/ld.so.cache is for.

I agree that it hasn't been done brilliantly fwtw. But there is no
reason on earth not to make the change proposed until such time
as an alternative impl is put in place; it can only make /lib more
consistent.

>  Maybe we could just
> install all the libs together (either / or /usr) and stop pretending
> that what we are doing isn't wrong?

I'm still at a loss to understand why building the pkg with libdir=/lib
and then simply moving the static libs to /usr is not an option.
/usr/lib is automatically looked up by the linker, so that won't affect
builds: the only issue I can see would be a minor edit of any pkgconf
file, if libs are under a subdir, and that only affects static linking.

In no event, could not having static libs available under /lib be an
issue at startup, in stark contrast to dynamic ones. So the ld_script
approach seems really odd, no doubt a result of my ignorance. If all
else failed wrt libtool, one could easily symlink static libs under
/usr/lib to their lt install location under /lib.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)