Summary: | crossdev fails with file collisions due to a commit on toolchain.eclass | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joe Breuer <gentoo> |
Component: | Eclasses | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ansla80, armin76, dirk, gentoo, l33tmmx, radegand, spartacus06, sven.koehler, wtt6, xaviermiller |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.518&r2=1.519 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
cross-i686-pc-linux-gnu-info.log
cross-i686-pc-linux-gnu-gcc-stage1.log.gz gcc-build-logs.tar.bz2 |
Description
Joe Breuer
2012-03-03 12:56:16 UTC
Created attachment 304121 [details]
cross-i686-pc-linux-gnu-info.log
Created attachment 304123 [details]
cross-i686-pc-linux-gnu-gcc-stage1.log.gz
Created attachment 304125 [details]
gcc-build-logs.tar.bz2
On the system which DID have a working install of cross-i686-pc-linux-gnu/gcc-4.5.3-r2, 'emerge -bDNauvt @world' just tried to recompile this cross-gcc (due to the unset libffi use flag being removed, if I understand emerges output correctly: [ebuild R ] cross-i686-pc-linux-gnu/gcc-4.5.3-r2 USE="cxx fortran nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -graphite -gtk -hardened -libssp -lto -mudflap -multilib -multislot -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla (-libffi%)" 0 kB [1] This rebuild also fails with file collisions, in this case: /usr/bin/cpp-4.5.3 /usr/bin/gcc-4.5.3 /usr/bin/g++-4.5.3 /usr/bin/c++-4.5.3 /usr/bin/gfortran-4.5.3 ... ah and that's more files because it's a rebuild of the latest stage, not a stage1 build. The changes in gcc-4.5.3-r2.ebuild look innocent enough since it was stabilized: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/gcc/gcc-4.5.3-r2.ebuild?r1=1.8&view=log So my guess is that the problem lies within an eclass used by the gcc-4.5.3-r2.ebuild. ~amd64 crossdev-20120214 fails in the same way as stable amd64 crossdev-20111221. I also tried crossdev-20120301, this immediately gives me an error message: * please convert /etc/portage/package.env to a directory According to the gentoo handbook, /etc/portage/package.env is supposed to be a file and I cannot find any information on how to "convert it to a directory": http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=6#doc_chap2 I get the same error using crossdev-20120301 on host amd64 and target arm @Andrei: Just for clarification, please: Do you get the "colliding files" or the "please convert package.*" error? Digging around in 'man 5 portage' I found out how to convert /etc/portage/package.* into directories; I'm in the process of doing this now (ultimately to be able to test with crossdev-20120301). crossdev-20120301 fails the same with colliding /usr/bin/cpp-4.5.3 and /usr/bin/gcc-4.5.3 in cross-i686-pc-linux-gnu/gcc-4.5.3-r2 stage1. Digging down after changes in the toolchain.eclass, the fix for bug 220149 looks like a hot candidate for causing this breakage. I'll test with this change locally reverted: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/toolchain.eclass?r1=1.518&r2=1.519 The complete cross i686-pc-linux-gnu toolchain correctly builds here with toolchain.eclass reverted as described in comment 8. Staring hard at the fix for bug 220149 leads me to believe that the fix, as is, may not be correct - or at least may not be what's described by cJ. The files that are now erroneously generated are named /usr/bin/{gcc,g++}-<version>, whereas cJ requested /usr/bin/${CTARGET}-{gcc,g++}-<version>. The latter form would not lead to conflicts. I'm guessing the fix for 220149 causes /usr/bin/{gcc,g++}-<version> to be generated as well as /usr/bin/${CTARGET}-{gcc,g++}-<version>, so it should be restricted to only create the latter form. Until this is properly fixed, see my attachment to bug 220149 for a patch against /usr/portage/eclass/toolchain.eclass which fixes this problem. same error with cross-arm-softfloat-elf/gcc, cross-avr/gcc, etc. Yes, cross-i486-pc-linux-gnu fails here, too Hello, Same problem with *any* cross architectures, with gcc-4.6.2 - cross-i686 - cross-arm - cross-mingw32 It seems the ROOT is not correctly set? Confirmed. 1.524 fixes this issue for me. |