Bug 520346

Summary:	=sys-devel/gcc-4.7.4: EAPI=4 makes the ebuild install libgcc_s.so.1 and friends in the wrong place
Product:	Gentoo Linux	Reporter:	Anthony Basile <blueness>
Component:	[OLD] Core system	Assignee:	Gentoo Toolchain Maintainers <toolchain>
Status:	RESOLVED INVALID
Severity:	normal	CC:	hardened
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Anthony Basile gentoo-dev

2014-08-20 19:08:15 UTC

If you emerge gcc-4.7.4 with EAPI=4, you get libgcc_s.so.1, libgomp.so.1.0.0, libstdc++.so.6.0.17, etc installed at /usr/lib64 rather than /usr/lib/gcc/x86_64-gentoo-linux-musl/4.7.4 on a 64-bit system where LIBDIR=lib and not lib64.  Note the CHOST name there.  But the same happens on uclibc amd64.

Switching back to EAPI=2 and all is saved!


I'm not sure the cause is the same but this has been seen before:

https://forums.gentoo.org/viewtopic-t-917722.html?sid=b134556349e1fb3520bc7e85cd7004db



Reproducible: Always

Comment 1 Anthony Basile gentoo-dev

2014-08-20 19:20:02 UTC

This may also be related to bug #433161, but I can reproduceably show that switching eapi's fixes/breaks the installation.

Comment 2 Anthony Basile gentoo-dev

2014-08-20 20:50:30 UTC

I've verified that this also happens on i686.  Ie. gcc-4.7.4 with EAPI=4 installs into /usr/lib, while EAPI=2 installs to /usr/lib/gcc/i686-gentoo-linux-musl/4.7.4/.

Comment 3 Ryan Hill (RETIRED) gentoo-dev

2014-08-25 23:57:57 UTC

Definitely not the case here.  I don't see anything in src_install/gcc_movelibs that would be EAPI affected...

Comment 4 Anthony Basile gentoo-dev

2014-08-31 23:26:46 UTC

(In reply to Ryan Hill from comment #3)
> Definitely not the case here.  I don't see anything in
> src_install/gcc_movelibs that would be EAPI affected...

I'm not sure what triggered this but I can't reproduce it.  It happened in the context of catalyst runs which is a complex environment to debug.  I must have made some change.  Sorry for the noise.