| Summary: | dev-libs/libusb-1.0.19[abi_x86_32] fails when udev[-abi_x86_32] is installed | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Patrizio Bassi <patrizio.bassi> |
| Component: | [OLD] Library | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | systemd |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
config.log |
||
|
Description
Patrizio Bassi
2015-05-17 13:15:17 UTC
Please attach config.log. Created attachment 403868 [details]
config.log
there it is...it is compiling for 32bit target without having the right deps installed it was suggested here https://wiki.gentoo.org/wiki/Multilib_System_without_emul-linux_Packages dev-libs/libusb abi_x86_32 dev-libs/libusb-compat abi_x86_32 and probably required by some packages. i'm going to check. configure:12070: x86_64-pc-linux-gnu-gcc -m32 -o conftest -O2 -pipe -mtune=core2 -march=core2 -fomit-frame-pointer -mmmx -msse -msse2 -msse3 -mfpmath=sse -Wl,-O1 -Wl,--sort-common -W$ /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../libudev.so when searching for -lud$ /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libudev.so when searching for -ludev /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -ludev collect2: error: ld returned 1 exit status (In reply to Patrizio Bassi from comment #3) yes, if you want 32bit libusb, then you need 32bit libs for every package libusb needs. the libusb ebuild already deps on virtual/udev correctly: RDEPEND="udev? ( >=virtual/libudev-208:=[${MULTILIB_USEDEP}] ) and it looks to me like the libudev is correct: >=sys-fs/udev-208-r1:0/0[${MULTILIB_USEDEP},static-libs?] >=sys-apps/systemd-208:0/0[${MULTILIB_USEDEP}] not sure why portage didn't throw an error here. post the output of the command: $ emerge -pv libusb virtual/libudev udev systemd Calculating dependencies... done!
[ebuild R ] app-arch/lz4-0_p120::gentoo USE="{-test} -valgrind" ABI_X86="32* (64) (-x32)" 0 KiB
[ebuild R ] virtual/udev-217::gentoo USE="(systemd)" 0 KiB
[ebuild R ] sys-apps/systemd-219_p112:0/2::gentoo USE="acl curl gudev idn introspection kmod lz4 pam (policykit) seccomp ssl -apparmor -audit -cryptsetup -doc -elfutils -gcrypt -http -importd (-kdbus) -lzma -nat -python -qrcode (-selinux) -sysv-utils -terminal {-test} -vanilla -xkb" ABI_X86="32* (64) (-x32)" PYTHON_SINGLE_TARGET="python2_7 -python3_3 -python3_4" PYTHON_TARGETS="python2_7 python3_3 -python3_4" 0 KiB
[ebuild R ] virtual/libudev-215-r1:0/1::gentoo USE="(systemd*) (-static-libs)" ABI_X86="32 (64) (-x32)" 0 KiB
[ebuild R ] dev-libs/libusb-1.0.19:1::gentoo USE="udev -debug -doc -examples -static-libs {-test}" ABI_X86="32* (64) (-x32)" 0 KiB
Total: 5 packages (5 reinstalls), Size of downloads: 0 KiB
The following USE changes are necessary to proceed:
(see "package.use" in the portage(5) man page for more details)
# required by virtual/libudev-215-r1::gentoo
# required by dev-libs/libusb-1.0.19::gentoo[udev]
# required by libusb (argument)
>=sys-apps/systemd-219_p112 abi_x86_32
# required by sys-apps/systemd-219_p112::gentoo[lz4]
# required by virtual/libudev-215-r1::gentoo
# required by dev-libs/libusb-1.0.19::gentoo[udev]
# required by libusb (argument)
>=app-arch/lz4-0_p120 abi_x86_32
(In reply to Patrizio Bassi from comment #5) looks to me like portage is doing the right thing. how exactly did you get libusb to build ? did you use --nodeps or something ? does `emerge libusb` not show the same errors ? It's possible that the following sequence triggers this: 1. Start with sys-fs/udev[abi_x86_32] and virtual/libudev[abi_x86_32] installed. 2. emerge sys-apps/systemd[-abi_x86_32]; this will remove sys-fs/udev since they block each other. 3. emerge dev-libs/libudev[abi_x86_32] I'm not sure if portage would check reverse deps of systemd in step 2. If it does, that's probably the issue here. (In reply to Mike Gilbert from comment #7) > I'm not sure if portage would check reverse deps of systemd in step 2. If it > does, that's probably the issue here. That should say "If it does not check reverse deps ...". (In reply to Mike Gilbert from comment #7) Nevermind; in testing, it seems the conflict there gets caught in step 3. So we are back to "how did you manage to get emerge to rebuild libusb without rebuilding systemd?" if OP is still here and can still reproduce, please follow up to the last few questions we posted |
