the cross-compiler flavor of gcc-5.1.0 apparently installs a library in a system dir: Affected: cross-sh4-unknown-linux-gnu/gcc-5.1.0 cross-armv7a-hardfloat-linux-gnu/gcc-5.1.0 cross-h8300-elf/gcc-5.1.0 cross-avr/gcc-5.1.0 cross-mipsel-softfloat-linux-gnu/gcc-5.1.0 NOT affected: cross-aarch64-unknown-linux-gnu/gcc-5.1.0 host x86_64-pc-unknown-linux-gnu/5.1.0 all use the same use flags: [ebuild R *] cross-aarch64-unknown-linux-gnu/gcc-5.1.0:5.1.0::x11 USE="cxx graphite nptl openmp (-altivec) -awt -cilk -doc (-fixed-point) -fortran -gcj -go -hardened -libssp -multilib -multislot -nls -objc -objc++ -objc-gc -regression-test -sanitize -vanilla" 0 KiB [ebuild NS *] cross-mipsel-softfloat-linux-gnu/gcc-5.1.0:5.1.0::x11 [4.9.2:4.9.2::x11] USE="cxx graphite nptl openmp (-altivec) -awt -cilk -doc (-fixed-point) -fortran -gcj -go -hardened -libssp -multilib -multislot -nls -objc -objc++ -objc-gc -regression-test -sanitize -vanilla" 0 KiB [ebuild R *] cross-sh4-unknown-linux-gnu/gcc-5.1.0:5.1.0::x11 USE="cxx graphite nptl openmp (-altivec) -awt -cilk -doc (-fixed-point) -fortran -gcj -go -hardened -libssp -multilib -multislot -nls -objc -objc++ -objc-gc -regression-test -sanitize -vanilla" 0 KiB [ebuild NS *] cross-avr/gcc-5.1.0:5.1.0::x11 [4.9.2:4.9.2::x11] USE="cxx graphite nptl (-altivec) -awt -cilk -doc (-fixed-point) -fortran -gcj -go -hardened -libssp -multilib -multislot -nls -objc -objc++ -objc-gc -openmp -regression-test -sanitize -vanilla" 0 KiB [ebuild NS *] cross-h8300-elf/gcc-5.1.0:5.1.0::x11 [4.9.2:4.9.2::x11] USE="graphite multilib nptl (-altivec) -awt -cilk -cxx -doc (-fixed-point) -fortran -gcj -go -hardened -libssp -multislot -nls -objc -objc++ -objc-gc -openmp -regression-test -sanitize -vanilla" 0 KiB removing executable bit: usr/lib64/libcc1.la * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at http://bugs.gentoo.org unless you report exactly which * two packages install the same file(s). See * http://wiki.gentoo.org/wiki/Knowledge_Base:Blockers for tips on how to * solve the problem. And once again, please do NOT file a bug report * unless you have completely understood the above message. * * Detected file collision(s): * * /usr/lib64/libcc1.la * /usr/lib64/libcc1.so.0.0.0 * /usr/lib64/libcc1.so * /usr/lib64/libcc1.so.0 * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * cross-sh4-unknown-linux-gnu/gcc-5.1.0:5.1.0::x11 * /usr/lib64/libcc1.la * /usr/lib64/libcc1.so * /usr/lib64/libcc1.so.0 * /usr/lib64/libcc1.so.0.0.0 * * Package 'cross-h8300-elf/gcc-5.1.0' NOT merged due to file collisions. * If necessary, refer to your elog messages for the whole content of the * above message. * the sh4 one did install because it was the first cross gcc 5 i built. Reproducible: Always
Also affected: cross-armv6j-hardfloat-linux-gnueabi/gcc-5.1.0 Curious that aarch64 is not affected (I see the same thing); for aarch64 the libcc1 files in question are installed in: /usr/lib/gcc/aarch64-unknown-linux-gnueabi/5.1.0/libcc1.{la,so,so.0,so.0.0.0} Along with other files like libgcc.a. libgcc.a is in the right place in armv6j, but not libcc1.so
FWIW, easy workaround is to set EXTRA_ECONF="--disable-libcc1" before running emerge/crossdev.
the difference with libcc1 vs all the other gcc libs is that it isn't a target lib you link target code against. it is used by the `gcc` command itself. that's why it's in the host paths like /usr/lib64/ (on an x86_64 system).
*** Bug 551348 has been marked as a duplicate of this bug. ***
If that helps collisions come up when there is more, than one crosscompiler: * Messages for package cross-armv5tel-softfloat-linux-gnueabi/gcc-5.1.0: * This package will overwrite one or more files that may belong to other * * Detected file collision(s): * * /usr/lib64/libcc1.la * /usr/lib64/libcc1.so.0.0.0 * /usr/lib64/libcc1.so * /usr/lib64/libcc1.so.0 * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * cross-ia64-unknown-linux-gnu/gcc-5.1.0:5.1.0::local-cross-overlay * /usr/lib64/libcc1.la * /usr/lib64/libcc1.so * /usr/lib64/libcc1.so.0 * /usr/lib64/libcc1.so.0.0.0 Looks like they used to be installed into target-specific dirs: /usr/lib64/gcc/powerpc64-unknown-linux-gnu/5.1.0/libcc1.la /usr/lib64/gcc/s390x-unknown-linux-gnu/5.1.0/libcc1.la /usr/lib64/gcc/sparc64-unknown-linux-gnu/5.1.0/libcc1.la /usr/lib64/gcc/x86_64-pc-linux-gnu/5.1.0/libcc1.la
*** Bug 564568 has been marked as a duplicate of this bug. ***
(In reply to Manuel Lauss from comment #2) > FWIW, easy workaround is to set EXTRA_ECONF="--disable-libcc1" before > running emerge/crossdev. Hi! This work-around works for me (i686-gentoo-linux-gnu, avr)
This seemed to be fixed in 5.2.0 (at least I don't have the work-round in my package.env files for 5.2.0) but it is back again with 5.3.0.
*** Bug 568952 has been marked as a duplicate of this bug. ***
Seems that issue arises only for targets that don't have multiple ABIs (all are gcc-5.3.0). These can coexist freely: powerpc64-unknown-linux-gnu s390x-unknown-linux-gnu sparc64-unknown-linux-gnu But once i've installed ia64-unknown-linux-gnu-5.3.0 It does not allow me installing other single-ABI targets like alpha-unknown-linux-gnu * cross-ia64-unknown-linux-gnu/gcc-5.3.0:5.3.0::local-cross-overlay * /usr/lib64/libcc1.la * /usr/lib64/libcc1.so * /usr/lib64/libcc1.so.0 * /usr/lib64/libcc1.so.0.0.0 * * Package 'cross-alpha-unknown-linux-gnu/gcc-5.3.0' NOT merged due to * file collisions. If necessary, refer to your elog messages for the * whole content of the above message.
(In reply to Manuel Lauss from comment #2) > FWIW, easy workaround is to set EXTRA_ECONF="--disable-libcc1" before > running emerge/crossdev. What functionality do we lose by setting this?
(In reply to Nick Bowler from comment #11) > (In reply to Manuel Lauss from comment #2) > > FWIW, easy workaround is to set EXTRA_ECONF="--disable-libcc1" before > > running emerge/crossdev. > > What functionality do we lose by setting this? libcc1 allows GCC to be embedded in other applications. Notably, GDB uses libcc1 to implement its "compile" command. See https://sourceware.org/gdb/onlinedocs/gdb/Compiling-and-Injecting-Code.html
just my 5 cents: I've the same collision with msp430-elf 5.2.0 and arm-none-eabi 5.3.0 GCCs. Maybe there are all arm* targets affected. Actually, as far as I understand, ALL targets where `$CC -print-multi-os-directory` returns "." — affected. Otherwise (if not ".") — it going to be installed in right, ABI-related location. There was similar issue 6 years ago (still not fixed) in https://bugs.gentoo.org/show_bug.cgi?id=261068 . And there Flameeyes reported patch (fixing that thing) to upstream (still no adequate reaction too): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42276 TL;DR: fixing ./configure{,.ac} with: -multi_os_directory=`$CC -print-multi-os-directory` -case $multi_os_directory in - .) - dbexecdir='$(libdir)/'$gc::PLACEHOLDER::subdir # Avoid /. - ;; - *) - dbexecdir='$(libdir)/'$multi_os_directory/$gc::PLACEHOLDER::subdir - ;; -esac +dbexecdir='$(toolexeclibdir)'/$gc::PLACEHOLDER::subdir (where ::PLACEHOLDER:: contains "library" which is patching, "j" in case of original flameeyes bug) should fix all that issues.
*** Bug 571468 has been marked as a duplicate of this bug. ***
this hacks around it, but at least unblocks people. will probably tweak it as other related libs get moved around. http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9511906a1b16034f98c9f9adee91ed4cb875c620
*** Bug 572294 has been marked as a duplicate of this bug. ***
