After successful compilation of gcc installation fails. All install invocations in log refer to image/nuke-me directory, which seems to be nuked after all. Logs are attached. Error message: sed: can't read .//Users/konstantintokarev/Gentoo/usr/lib/gcc/powerpc-apple-darwin9/4.7.2/*.la: No such file or directory sed: can't read .//Users/konstantintokarev/Gentoo/usr/lib/gcc/powerpc-apple-darwin9/4.7.2/*.la: No such file or directory * ERROR: sys-devel/gcc-4.7.2-r1 failed (install phase): * gcc not found in /Volumes/Development/Gentoo/var/tmp/portage/sys-devel/gcc-4.7.2-r1/image/Users/konstantintokarev/Gentoo/ * * Call stack: * ebuild.sh, line 93: Called call-ebuildshell 'src_install' * environment, line 680: Called src_install * environment, line 4319: Called toolchain_src_install * environment, line 5119: Called die * The specific snippet of code: * [[ -r ${ED}${BINPATH}/gcc${EXEEXT} ]] || die "gcc not found in ${ED}"; * * If you need support, post the output of `emerge --info '=sys-devel/gcc-4.7.2-r1'`, * the complete build log and the output of `emerge -pqv '=sys-devel/gcc-4.7.2-r1'`. * * Please include /Volumes/Development/Gentoo/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build/gcc-build-logs.tar.bz2 in your bug report * * The complete build log is located at '/Volumes/Development/Gentoo/var/tmp/portage/sys-devel/gcc-4.7.2-r1/temp/build.log'. * The ebuild environment file is located at '/Volumes/Development/Gentoo/var/tmp/portage/sys-devel/gcc-4.7.2-r1/temp/environment'. * Working directory: '/Volumes/Development/Gentoo/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build' * S: '/Volumes/Development/Gentoo/var/tmp/portage/sys-devel/gcc-4.7.2-r1/work/build'
Created attachment 344654 [details] Build logs
Created attachment 344656 [details] Complete build log
Ping
* Your ${EPREFIX} contains one or more symlinks. GCC has a * bug which prevents it from working properly when there are * symlinks in your ${EPREFIX}. * See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29831 * Continuing with your EPREFIX set to: * /Volumes/Development/Gentoo /Volumes/Development/Gentoo/usr/portage/eclass/toolchain.eclass: line 573: EPREFIX: доступная только на чтение переменная No idea what the cyrillic says, but this is likely the cause of this problem.
Cyrillic says EPREFIX is read-only variable. How can it be read-only?
I had the same error a while ago, which is why I added a similar symlink check to the bootstrap script. (In reply to Konstantin Tokarev from comment #5) > Cyrillic says EPREFIX is read-only variable. > > How can it be read-only? EPREFIX is read-only inside the ebuild environment.
http://prefix.gentooexperimental.org/hg/prefix-tree/rev/cc684a78773d Result of that commit is that if you want to push it, it will just do it. If it will work, is not guaranteed though.
@grobian: why not realEPREFIX=$(cd "$EPREFIX"; pwd -P) ?
(In reply to Christoph Junghans from comment #8) > @grobian: why not realEPREFIX=$(cd "$EPREFIX"; pwd -P) ? nut /var/tmp $ pwd -P /private/var/tmp nut /var/tmp $ mkdir dir1 nut /var/tmp $ ln -s dir2 nut /var/tmp $ (cd dir2 && pwd -P) bash: cd: dir2: Too many levels of symbolic links nut /var/tmp $ python -c 'import os; print(os.path.realpath("dir2"))' /private/var/tmp/dir2 nut /var/tmp $
(In reply to Fabian Groffen from comment #9) > (In reply to Christoph Junghans from comment #8) > > @grobian: why not realEPREFIX=$(cd "$EPREFIX"; pwd -P) ? > > nut /var/tmp $ pwd -P > /private/var/tmp > nut /var/tmp $ mkdir dir1 > nut /var/tmp $ ln -s dir2 What is this line supposed to do? dir2 -> dir2 ? And is this actually allowed as EPREFIX? realEPREFIX=$(cd "$EPREFIX" && pwd -P) would be empty and hence different from EPREFIX, too. > nut /var/tmp $ (cd dir2 && pwd -P) > bash: cd: dir2: Too many levels of symbolic links > nut /var/tmp $ python -c 'import os; print(os.path.realpath("dir2"))' > /private/var/tmp/dir2 > nut /var/tmp $
(In reply to Christoph Junghans from comment #10) > > nut /var/tmp $ pwd -P > > /private/var/tmp > > nut /var/tmp $ mkdir dir1 > > nut /var/tmp $ ln -s dir2 > What is this line supposed to do? > dir2 -> dir2 ? > And is this actually allowed as EPREFIX? > realEPREFIX=$(cd "$EPREFIX" && pwd -P) would be empty and hence different > from EPREFIX, too. BUAH! I FAIL. There was, however, a reason for this in the past. Now, the only thing we care about is that we reliably figure out if the EPREFIX is going to cause trouble or not.
