Bugzilla Bug 90777

I have libusb 0.1.10a installed and the configure script complains about a
missing libusb. I talked to the Developers and they said it must be a Gentoo
error.

The stable version is 2.1.5 now BTW (came out in december), with 2.1.6rc1
beeing the newest unstable version.

I downloaded libgphoto2 2.1.6rc1 manually and compiled it with the same
./configure line that is used for the 2.1.4 and 2.1.5 ebuilds by my emerge. The
error about the "missing" libusb reappears, at the end the summary says "USB
Support: yes, via /usr" (identical to the output of the ebuilds) but in the end
I have USB support. Maybe one of the patches that the ebuilds apply is broken?
I have no problems now accessing my camera with digikam.

I tried to emerge libgphoto2/gphoto2 on a standard x86 machine (32 Bit), the
stable ebuild 2.1.4 is built with USB support as expected. So it may be an
x86_64-only problem.

could you provide your emerge info and attach a log of the build?

I can provide the portage and config.log logs. It seems to be trying to use a
sysctl thing, and then complains about CTL_HW and HW_PHYSMEM not being defined
(they're not, at least according to grep -r CTL_HW /usr/include). I think
they're only on BSD anyway -- which suggests that the configure script is
seeing us as usb. Anyway, the logs are below.

Created an attachment (id=57602) [edit]
config.log

Fails to find libusb usageable because of missing CTL_HW and HW_PHYSMEM.

Created an attachment (id=57603) [edit]
Emerge log -- cut short

Stopped because the configure obviously failed.

Scratch what I said in #4 -- I was talking bollocks, sorry. It fails to find a
usable libusb, in configuring for libgphoto2_port instead. Doesn't find
usb_busses. I've attached the relevant config.log below.

Created an attachment (id=57604) [edit]
config.log for libgphoto2_port

Sorry for the spamming... but I think I've found the problem. libusb installs a
libusb.a, but usbutils also does this. As covered in bug #25571, the conflict
is known. Looking at the ebuild for usbutils, it removes everything in /usr/lib
instead of ${D}/usr/$(get_libdir) as the guidelines now say. Obviously this
only screws up on amd64 (and other multilib, I guess) installs. Using this,
re-emerging usbutils and then libusb seems to sort things out.

Adding you alistair -- because you did the original patch for this package
removing the libusb collision.

I'm running the latest usbutils, and it seems that libusb.so still comes with
it, although Alistair said he removed it from usbutils (at least this is what I
understood, sorry if I'm wrong)

[ Searching for packages matching usbutils... ]
sys-apps/usbutils-0.11-r5
* Contents of sys-apps/usbutils-0.11-r5:
/usr
/usr/lib64
/usr/lib64/libusb.a
/usr/lib64/libusb.la
/usr/lib64/libusb.so -> libusb.so.0.0.0
/usr/lib64/libusb.so.0 -> libusb.so.0.0.0
/usr/lib64/libusb.so.0.0.0
/usr/sbin
/usr/sbin/lsusb
/usr/sbin/usbmodules
/usr/share
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/lsusb.8.gz
/usr/share/man/man8/usbmodules.8.gz
/usr/share/misc
/usr/share/misc/usb.ids

It is fixed on x86 (and other non-multilib installs). It currently removes
everything from the /usr/lib folder of the temporary install image, which
contains nothing on amd64 as it all goes in /usr/lib64. I believe that the
gentoo docs say /usr/$(getlibdir) is the recommended incantation now which
replaces lib with lib64 or lib32 as needed.

I see, thank you Gen Zhang.
So, should I 
1. reopen #25571 with your fix
2. submit a new bug for usbutils with a link to this bug where you identified the problem
3. do nothing and hope, as this bug is still open, that somebody will fix usbutils ebuild the way you suggested.

I'd opt for 3: Alastair recently claimed this bug for himself -- I just hope
he's gonna do that oneliner soon.... ;) In any case, you can work around the
issue by:

1. emerge usbutils
2. rm the files in /usr/lib64 that it put there
3. emerge libusb

That should hold long enough for you to emerge libgphoto2 without problems.

I filed bug #91923 for usbutils... My libusb also builds libs without the .so
extension... just running aclocal/automake/autoconf seems to fix it... 
libusb-0.1.10a seems to be fixed too 

will be fixed in the next rev bump for usbutils, waiting for the mirrors to
sync up with the new usb.ids before committing the new version.

usbutils fixed for ~x86, and i guess ~amd64, please test

-r5 is fine. Thanks.

closing