This problem occurred when trying to bootstrap Prefix Portage on Solaris/x86 today (2007-08-05). The bootstrapping followed the May 7, 2007 version of <http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml>, with small deviations. The exact details can be found in this script: <http://wb748077.bahnhofbredband.se/prefix-gentoo/setup-prefix-2007.08.04.sh>. Step 1.8-gcc (emerge gcc) terminated with zero exit codes throughout, but the following suspicious message was seen: * Your gcc has a bug with GCC_SPECS. * Please re-emerge gcc. * http://bugs.gentoo.org/68395 The following step (1.6-catchup) intends to emerge sed. Here things go wrong altogether: checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. !!! Please attach the following file when seeking support: !!! /var/tmp/2007-08-04/var/tmp/portage/sys-apps/sed-4.1.5/work/sed-4.1.5/config.log * * ERROR: sys-apps/sed-4.1.5 failed.
I've seen the same message today (bootstrapping on OSX here), but the compiler appears to work fine here. I'm wondering what change made this come up again. This is the test that is being performed: $ env GCC_SPECS="" "${EPREFIX}"/usr/bin/gcc -v which indeed just works for me. Can you try that on your system?
Sure. This is what I get (my EPREFIX is /var/tmp/2007-08-04): Using built-in specs. Target: i386-pc-solaris2.10 Configured with: /var/tmp/2007-08-04/var/tmp/portage/sys-devel/gcc-4.2.0/work/gcc-4.2.0/configure --prefix=/var/tmp/2007-08-04/usr --bindir=/var/tmp/2007-08-04/usr/i386-pc-solaris2.10/gcc-bin/4.2.0 --includedir=/var/tmp/2007-08-04/usr/lib/gcc/i386-pc-solaris2.10/4.2.0/include --libdir=/var/tmp/2007-08-04/usr/lib/gcc/i386-pc-solaris2.10/4.2.0 --datadir=/var/tmp/2007-08-04/usr/share/gcc-data/i386-pc-solaris2.10/4.2.0 --mandir=/var/tmp/2007-08-04/usr/share/gcc-data/i386-pc-solaris2.10/4.2.0/man --infodir=/var/tmp/2007-08-04/usr/share/gcc-data/i386-pc-solaris2.10/4.2.0/info --with-gxx-include-dir=/var/tmp/2007-08-04/usr/lib/gcc/i386-pc-solaris2.10/4.2.0/include/g++-v4 --host=i386-pc-solaris2.10 --build=i386-pc-solaris2.10 --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --with-local-prefix=/var/tmp/2007-08-04/usr --with-gnu-ld Thread model: posix gcc version 4.2.0 (Gentoo 4.2.0 p1.4)
I added code to the script to mask gcc-4.2.0. This caused gcc-4.1.2 to be emerged instead. However, the same failure occurs when emerging the next package (sed in my case; the error message being: checking for C compiler default output file name... configure: error: C compiler cannot create executables). So, it seems that the exact gcc version is not the issue. I include the very last lines of console output from the "emerge gcc" step, just in case that might give some clue...: Can't open /var/tmp/2007-08-04/var/tmp/2007-08-04//etc/make.conf * Switching native-compiler to i386-pc-solaris2.10-4.1.2 ... * Your gcc has a bug with GCC_SPECS. * Please re-emerge gcc. * http://bugs.gentoo.org/68395 [ ok ] * If you intend to use the gcc from the new profile in an already * running shell, please remember to do: * (bash) # source /var/tmp/2007-08-04/etc/profile * or * (tcsh) # source /var/tmp/2007-08-04/etc/csh.login * If you have issues with packages unable to locate libstdc++.la, * then try running 'fix_libtool_files.sh' on the old gcc versions. >>> sys-devel/gcc-4.1.2 merged. >>> No packages selected for removal by clean >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * Messages for package sys-devel/gcc-4.1.2: * Can't read /config.sub, skipping.. * Can't read /config.guess, skipping.. * eprefixify: /var/tmp/2007-08-04/var/tmp/portage/sys-devel/gcc-4.1.2/temp/awk/fixlafiles.awk-no_gcc_la does not exist * eprefixify: /var/tmp/2007-08-04/var/tmp/portage/sys-devel/gcc-4.1.2/temp/awk/fixlafiles.awk does not exist * If you have issues with packages unable to locate libstdc++.la, * then try running 'fix_libtool_files.sh' on the old gcc versions. * GNU info directory index is up-to-date. (the lines below were generated by `env GCC_SPECS="" "${EPREFIX}"/usr/bin/gcc -v' in the bootstrap script) Using built-in specs. Target: i386-pc-solaris2.10 Configured with: /var/tmp/2007-08-04/var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure --prefix=/var/tmp/2007-08-04/usr --bindir=/var/tmp/2007-08-04/usr/i386-pc-solaris2.10/gcc-bin/4.1.2 --includedir=/var/tmp/2007-08-04/usr/lib/gcc/i386-pc-solaris2.10/4.1.2/include --libdir=/var/tmp/2007-08-04/usr/lib/gcc/i386-pc-solaris2.10/4.1.2 --datadir=/var/tmp/2007-08-04/usr/share/gcc-data/i386-pc-solaris2.10/4.1.2 --mandir=/var/tmp/2007-08-04/usr/share/gcc-data/i386-pc-solaris2.10/4.1.2/man --infodir=/var/tmp/2007-08-04/usr/share/gcc-data/i386-pc-solaris2.10/4.1.2/info --with-gxx-include-dir=/var/tmp/2007-08-04/usr/lib/gcc/i386-pc-solaris2.10/4.1.2/include/g++-v4 --host=i386-pc-solaris2.10 --build=i386-pc-solaris2.10 --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --with-local-prefix=/var/tmp/2007-08-04/usr --with-gnu-ld Thread model: posix gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1)
Can you look in the config.log file of sed to see why it thinks the compiler cannot create binaries? Maybe that gives me a hint as to what to look for.
Created attachment 127237 [details] build.log from `emerge sed' just after gcc was built
Created attachment 127239 [details] config.log from `emerge sed' just after gcc was built
Created attachment 127311 [details, diff] toolchain.eclass patch i386-pc-solaris2.10-gcc -I/var/tmp/2007-08-04/usr/include -L/var/tmp/2007-08-04/usr/lib -R/var/tmp/2007-08-04/usr/lib -L/var/tmp/2007-08-04/lib -R/var/tmp/2007-08-04/lib conftest.c >&5 ld: fatal: file elf_i386: open failed: No such file or directory collect2: ld returned 1 exit status hmmm.... ok.. scary. Can you easily test the attached patch to toolchain.eclass?
When should the eclass patch be applied? Just after emerging gcc, and before emerging the next package (sed in my case)?
I tried executing the patch as described. The result is the same, emerging sed fails. Working a little by trial-and-error, since the machine is idle anyway, I will now execute the patch *before* emerging gcc instead.
sorry, yeah, it needs to be applied before building gcc. Even though that is an expensive operation, I'm affraid the patch (I attached the reverse) broke for everything, but on Darwin it fixed something.
Good news this time; the patch is applied just after emerging bash and before emerging baselayout-prefix, flex, binutils-config, binutils, gcc-config, ..., gcc, and now the packages just after gcc seem to emerge fine.
thanks! I reverted the change in svn now. I'll soon release a new snapshot so this should be solved for a new bootstrap. Leaving this bug open till that time.
*** Bug 188765 has been marked as a duplicate of this bug. ***
I can't bump the snapshot, as the svn tree is down. I made a new snapshot though that should work for you: http://www.gentoo.org/~grobian/distfiles/prefix-overlay-20070806.tar.bz it's not up-to-date as the svn tree is down, so can't update.
new snapshot made, added to bootstrap-prefix.sh. This bug should be fixed now. Sorry for the wait!
I can confirm that my bootstrap script (2007-08-04 version at http://wb748077.bahnhofbredband.se/prefix-gentoo/) now works on Solaris/x86. I have good hope for Solaris/SPARC as well; it is crunching along but has not reached the "emerge gcc" stage yet.
good to hear. Someone yesterday bootstrapped Solaris/Sparc, with some success, so I hope it works for you too.
