$ lddtree /lib/udev/hid2hci hid2hci => /lib/udev/hid2hci (interpreter => /lib64/ld-linux-x86-64.so.2) libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 libpthread.so.0 => /lib64/libpthread.so.0 libudev.so.1 => /lib64/libudev.so.1 librt.so.1 => /lib64/librt.so.1 libc.so.6 => /lib64/libc.so.6 This is a regression from dev-libs/libusb:0 simply call gen_usr_ldscript -a libname; people that do not want this can simply ask for a feature to toolchain-funcs.eclass maintainers to noop gen_usr_ldscript if a given variable is set.
I'm not sure what "simply call gen_usr_ldscript -a libname" means, but since the ebuilds run configure shouldn't it be easy to pass --libdir=$(something) in the ebuild or perhaps in an even more general way inside econf?
(In reply to Peter Stuge from comment #1) > I'm not sure what "simply call gen_usr_ldscript -a libname" means, but since > the ebuilds run configure shouldn't it be easy to pass --libdir=$(something) > in the ebuild or perhaps in an even more general way inside econf? no, this causes problems: static libs will end up in /lib where they are useless, and moving only the .so to /lib might cause the linker to pick the static lib first. moreover it can't be disabled easily by nooping the gen_usr_ldscript function. see dev-libs/libusb:0 for an example, its really a one liner.
(In reply to Alexis Ballier from comment #0) > $ lddtree /lib/udev/hid2hci to which package does hid2hci belong to? certainly not sys-fs/udev. it's a known fact initramfs is required for sep. /usr, so I don't think thesetype of bugs should be filed at all anymore.
(In reply to Samuli Suominen from comment #3) > (In reply to Alexis Ballier from comment #0) > > $ lddtree /lib/udev/hid2hci > > to which package does hid2hci belong to? bluez > certainly not sys-fs/udev. it's a > known fact initramfs is required for sep. /usr, it is also a known fact that its because of these kind of bugs that lot of people went the lazy way and declared this as a new requirement. > so I don't think thesetype > of bugs should be filed at all anymore. it is a one liner... and one step in the right direction.
POC: Index: libusbx-1.0.16.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/dev-libs/libusbx/libusbx-1.0.16.ebuild,v retrieving revision 1.1 diff -u -B -r1.1 libusbx-1.0.16.ebuild --- libusbx-1.0.16.ebuild 15 Jul 2013 08:42:02 -0000 1.1 +++ libusbx-1.0.16.ebuild 31 Jul 2013 12:34:13 -0000 @@ -3,7 +3,7 @@ # $Header: /var/cvsroot/gentoo-x86/dev-libs/libusbx/libusbx-1.0.16.ebuild,v 1.1 2013/07/15 08:42:02 ssuominen Exp $ EAPI=5 -inherit eutils +inherit eutils toolchain-funcs DESCRIPTION="Userspace access to USB devices" HOMEPAGE="http://libusbx.sourceforge.net/" @@ -45,6 +45,8 @@ src_install() { default + gen_usr_ldscript -a usb-1.0 + if use examples; then insinto /usr/share/doc/${PF}/examples doins examples/*.{c,h} Index: libusb-compat-0.1.5.ebuild =================================================================== RCS file: /var/cvsroot/gentoo-x86/dev-libs/libusb-compat/libusb-compat-0.1.5.ebuild,v retrieving revision 1.12 diff -u -B -r1.12 libusb-compat-0.1.5.ebuild --- libusb-compat-0.1.5.ebuild 2 Jul 2013 07:44:37 -0000 1.12 +++ libusb-compat-0.1.5.ebuild 31 Jul 2013 12:34:40 -0000 @@ -3,7 +3,7 @@ # $Header: /var/cvsroot/gentoo-x86/dev-libs/libusb-compat/libusb-compat-0.1.5.ebuild,v 1.12 2013/07/02 07:44:37 ago Exp $ EAPI=5 -inherit eutils +inherit eutils toolchain-funcs DESCRIPTION="Userspace access to USB devices (libusb-0.1 compat wrapper)" HOMEPAGE="http://libusb.sourceforge.net/" @@ -34,6 +34,8 @@ src_install() { default + gen_usr_ldscript -a usb + insinto /usr/share/doc/${PF}/examples doins examples/*.c
(In reply to Alexis Ballier from comment #4) > (In reply to Samuli Suominen from comment #3) > > (In reply to Alexis Ballier from comment #0) > > > $ lddtree /lib/udev/hid2hci > > > > to which package does hid2hci belong to? > > bluez > > > certainly not sys-fs/udev. it's a > > known fact initramfs is required for sep. /usr, > > it is also a known fact that its because of these kind of bugs that lot of > people went the lazy way and declared this as a new requirement. but bluez uses glib-2 too, are we going to move it and it's dependencies like gio, and gio's extension gvfs and it's dependencies udisks, upower, ... ? some couple of dozen libraries in the bluez deptree last I checked
(In reply to Samuli Suominen from comment #6) hid2hci, which is the one that matters here, does not as you can see from comment #0
(In reply to Alexis Ballier from comment #7) > (In reply to Samuli Suominen from comment #6) > > hid2hci, which is the one that matters here, does not as you can see from > comment #0 okay i've applied your fix to libusb-compat (0.1.5-r1), libusb (1.0.9-r1), libusbx (1.0.16-r1) because if we give up with the / vs. /usr linking, surely we can convert gen_usr_ldscript to be no-op later on
(In reply to Samuli Suominen from comment #8) > (In reply to Alexis Ballier from comment #7) > > (In reply to Samuli Suominen from comment #6) > > > > hid2hci, which is the one that matters here, does not as you can see from > > comment #0 > > okay > > i've applied your fix to libusb-compat (0.1.5-r1), libusb (1.0.9-r1), > libusbx (1.0.16-r1) > thx > because if we give up with the / vs. /usr linking, surely we can convert > gen_usr_ldscript to be no-op later on yes; not that I care much but IMHO gen_usr_ldscript should already be a no-op if a given variable, say GENTOO_USR_MOVE, is set, so that people can start the usr move work if they like.
This commit caused two regressions. See the blocked bugs.
(In reply to Peter Stuge from comment #10) > This commit caused two regressions. See the blocked bugs. 2 x INVALID
