Created attachment 316051 [details] info libusb-compat-0.1.4 wont compile make[2]: Entering directory `/var/tmp/portage/dev-libs/libusb-compat-0.1.4/work/libusb-compat-0.1.4/libusb' /bin/sh ../libtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused -Wstrict-prototypes -Werror-implicit-function-declaration -Wno-pointer-sign -Wshadow -I/usr/include/libusb-1.0 -O2 -march=core2 -mtune=generic -fomit-frame-pointer -pipe -mssse3 -mfpmath=sse -c -o libusb_la-core.lo `test -f 'core.c' || echo './'`core.c libtool: compile: i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused -Wstrict-prototypes -Werror-implicit-function-declaration -Wno-pointer-sign -Wshadow -I/usr/include/libusb-1.0 -O2 -march=core2 -mtune=generic -fomit-frame-pointer -pipe -mssse3 -mfpmath=sse -c core.c -fPIC -DPIC -o .libs/libusb_la-core.o core.c:35:6: error: nested redefinition of 'enum usbi_log_level' core.c:35:6: error: redeclaration of 'enum usbi_log_level' /usr/include/libusb-1.0/libusb.h:962:6: note: originally defined here core.c:36:2: error: redeclaration of enumerator 'LOG_LEVEL_DEBUG' /usr/include/libusb-1.0/libusb.h:967:2: note: previous definition of 'LOG_LEVEL_DEBUG' was here core.c:37:2: error: redeclaration of enumerator 'LOG_LEVEL_INFO' /usr/include/libusb-1.0/libusb.h:966:2: note: previous definition of 'LOG_LEVEL_INFO' was here core.c:38:2: error: redeclaration of enumerator 'LOG_LEVEL_WARNING' /usr/include/libusb-1.0/libusb.h:965:2: note: previous definition of 'LOG_LEVEL_WARNING' was here core.c:39:2: error: redeclaration of enumerator 'LOG_LEVEL_ERROR' /usr/include/libusb-1.0/libusb.h:964:2: note: previous definition of 'LOG_LEVEL_ERROR' was here make[2]: *** [libusb_la-core.lo] Error 1 make[2]: Leaving directory `/var/tmp/portage/dev-libs/libusb-compat-0.1.4/work/libusb-compat-0.1.4/libusb' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/dev-libs/libusb-compat-0.1.4/work/libusb-compat-0.1.4' make: *** [all] Error 2 * ERROR: dev-libs/libusb-compat-0.1.4 failed (compile phase): * emake failed
Created attachment 316053 [details] build.log
Created attachment 316055 [details] environment
Same problems here also.
Same here also
Replacing dev-libs/libusbx with dev-libs/libusb seems to fix it.
(In reply to comment #5) > Replacing dev-libs/libusbx with dev-libs/libusb seems to fix it. Could you explain the process you used? I also replaced and it did not fix the issue for me.
(In reply to comment #6) > (In reply to comment #5) > > Replacing dev-libs/libusbx with dev-libs/libusb seems to fix it. > > Could you explain the process you used? I also replaced and it did not fix > the issue for me. emerge -C dev-libs/libusbx emerge --oneshot dev-libs/libusb emerge --oneshot libusb-compat this works for me
I use paludis,so mine was cave uninstall dev-libs/libusbx -x cave resolve uninstall dev-libs/libusb -x
(In reply to comment #7) > emerge -C dev-libs/libusbx > emerge --oneshot dev-libs/libusb > emerge --oneshot libusb-compat > > this works for me I had this bug, and these steps fixed it.
does anyone know the reason why this happens at all? i dont feel that comfortable deleting packages to fix compiling of other packages without knowing why to do this at all
Oook, fixed in Portage: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-libs/libusb-compat/libusb-compat-0.1.4.ebuild?r1=1.8&r2=1.9 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-libs/libusb-compat/files/libusb-0.1-libusbx.patch?rev=1.1&content-type=text/plain Alternatively this could have been fixed by 1-liner sed like: sed -i -e '/^enum usbi_log_level/,/^}\;$/d' libusb/core.c || die But I decided it might not be readable to everyone... So patch is simpler... Mailed upstream about it
(I'm the libusb maintainer.) The bug is in libusbx-1.0.12, which moved an internal enum into the public header file in http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx;a=commitdiff;h=933a319469bcccc962031c989e39d9d1f44f2885 Emerging libusb-1.0.9 is a fine solution. Feel free to swap back priority in the virtual.
libusbx upstream and libusbx upstream doesn't seem to have agreement over the issue yet: http://libusb.org/ticket/138 (here libusb-compat upstream says this is a libusbx bug) http://sourceforge.net/apps/trac/libusbx/ticket/31 (waiting reply from libusbx upstream here...)
libusb-compat-0.1.4 still fails. i test ~arch stage builds (with metro tool) and libusb-compat failing with libusbx-1.0.12 (the only libusb:1 in system). I'd consider to re-open this bug until a clear workaround/patch found. vitual/libusb-1 is forcing libusbx-1.0.12 on ~arch.
(In reply to comment #14) > I'd consider to re-open this bug until a clear workaround/patch found. One solution is to simply change virtual/libusb-1 back to prefer libusb over libusbx. The libusbx propaganda is effective, but still only propaganda. libusb is not dead at all; the 1.0.9 release was made a few months ago and libusb development continues as it always has. > vitual/libusb-1 is forcing libusbx-1.0.12 on ~arch. I suggest to explicitly merge libusb-1.0.9, which also satisfies the virtual, and which does not have (and never would have) the namespace pollution in libusbx-1.0.12.
sure, the virtual is fixed in funtoo, but i can't consider this bug as resolved fixed, because libusb-compat is failing with patch applied.
(In reply to comment #16) > i can't consider this bug as resolved fixed, because libusb-compat is failing Yes, I agree.
also, libusb-compat failing randomly even if there is no libusbx installed, with libusb-10.9 and 32-bit stages builds problem remains.
(In reply to comment #18) > libusb-compat failing randomly even if there is no libusbx installed, > with libusb-10.9 and 32-bit stages builds problem Please tell more about this? Is there a bug report about it anywhere? I believe I have not heard about this before.
the build failure is exactly the same as in provided build.log, do i need to send the same log?
(In reply to comment #20) > the build failure is exactly the same as in provided build.log The build failure in build.log is caused by the namespace pollution in libusbx-1.0.12. libusb-1.0.9 does not have that problem. As I understand your previous comment you're saying that a 32-bit stage (which one, where is it?) with libusb-1.0.9 does show the same problem? I would like more information about that. > do i need to send the same log? Feel free to send it to me privately at least. I must be missing something about the circumstances. Thanks!
