From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D37B4138247 for ; Sun, 5 Jan 2014 04:09:20 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B407DE09EE; Sun, 5 Jan 2014 04:09:15 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6E1DBE09C0 for ; Sun, 5 Jan 2014 04:09:14 +0000 (UTC) Received: from grubbs.orbis-terrarum.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id A833533F5D1 for ; Sun, 5 Jan 2014 04:09:13 +0000 (UTC) Received: (qmail 16273 invoked by uid 10000); 5 Jan 2014 04:09:12 -0000 Date: Sun, 5 Jan 2014 04:09:12 +0000 From: "Robin H. Johnson" To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime Message-ID: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 45acf414-15c3-4c33-9c52-5d8421f78dfc X-Archives-Hash: af97cef2d86122dc1aa8634364891805 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