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 attachment 57602 [details] config.log Fails to find libusb usageable because of missing CTL_HW and HW_PHYSMEM.
Created attachment 57603 [details] 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 attachment 57604 [details] 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
