Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 547754 - sys-devel/gcc-5: cross-compilers install libcc1 in system dir
Summary: sys-devel/gcc-5: cross-compilers install libcc1 in system dir
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal with 2 votes (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 551348 564568 568952 571468 572294 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-04-26 05:16 UTC by Manuel Lauss
Modified: 2016-05-25 21:02 UTC (History)
17 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Manuel Lauss 2015-04-26 05:16:05 UTC
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
Comment 1 John Bowler 2015-04-26 22:37:34 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
Comment 2 Manuel Lauss 2015-04-27 10:50:21 UTC
FWIW, easy workaround is to set EXTRA_ECONF="--disable-libcc1" before running emerge/crossdev.
Comment 3 SpanKY gentoo-dev 2015-05-04 06:19:46 UTC
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).
Comment 4 SpanKY gentoo-dev 2015-06-07 04:35:02 UTC
*** Bug 551348 has been marked as a duplicate of this bug. ***
Comment 5 Sergei Trofimovich gentoo-dev 2015-06-14 16:16:50 UTC
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
Comment 6 Michael Palimaka (kensington) gentoo-dev 2015-11-10 15:25:43 UTC
*** Bug 564568 has been marked as a duplicate of this bug. ***
Comment 7 Xavier Miller gentoo-dev 2015-11-25 20:01:19 UTC
(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)
Comment 8 John Bowler 2015-12-07 01:05:59 UTC
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.
Comment 9 SpanKY gentoo-dev 2015-12-26 22:52:49 UTC
*** Bug 568952 has been marked as a duplicate of this bug. ***
Comment 10 Sergei Trofimovich gentoo-dev 2015-12-27 11:16:20 UTC
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.
Comment 11 Nick Bowler 2016-01-05 17:10:46 UTC
(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?
Comment 12 Matt Whitlock 2016-01-05 18:40:36 UTC
(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
Comment 13 Vadim A. Misbakh-Soloviov (mva) gentoo-dev 2016-01-09 21:10:10 UTC
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.
Comment 14 SpanKY gentoo-dev 2016-01-13 03:05:39 UTC
*** Bug 571468 has been marked as a duplicate of this bug. ***
Comment 15 SpanKY gentoo-dev 2016-01-16 10:00:10 UTC
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
Comment 16 SpanKY gentoo-dev 2016-02-01 04:37:30 UTC
*** Bug 572294 has been marked as a duplicate of this bug. ***