Summary: | sys-devel/gcc-5: cross-compilers install libcc1 in system dir | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Manuel Lauss <manuel.lauss> |
Component: | [OLD] Development | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | achurch+gentoo, alex, alexander, alexanders83, asolokha, bertrand, Christopher.Lundgren, conikost, DL7RAY, jj, maekke, mva, nbowler, phobosk, slyfox, uzytkownik2, xaviermiller |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=261068 https://bugs.gentoo.org/show_bug.cgi?id=582002 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Manuel Lauss
2015-04-26 05:16:05 UTC
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. *** |