gnatgcc is build against gcc-4.1, who is beginning to be very old. it doesn't support -march=amdfam10 nor -march=k8-ss3... workaround : use -march=k8 Reproducible: Always Steps to Reproduce: 1. set -march=amdfam10 2. emerge gnat-gcc Actual Results: at the ./configure : [..] checking target system type... x86_64-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for x86_64-pc-linux-gnu-gcc... /var/tmp/portage/dev-lang/gnat-gcc-4.3.3/work/usr/bin/gnatgcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. * * ERROR: dev-lang/gnat-gcc-4.3.3 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3843: Called gnatbuild_src_compile 'configure' 'make-tools' 'bootstrap' * environment, line 2722: Called die * The specific snippet of code: * CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}" "${S}"/configure --prefix=${PREFIX} --bindir=${BINPATH} --includedir=${INCLUDEPATH} --libd$ * The die message: * configure failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/dev-lang/gnat-gcc-4.3.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-lang/gnat-gcc-4.3.3/temp/environment'. *
Created attachment 196758 [details] fail config.log
Yes, this is the case indeed, and I am planning to update bootstrap when I issue the 4.4 version. That, however, turned out to be not completely straightforward. Some work is needed on it, but I have to push out a paper (in fact, even two of them) ASAP, so, my Gentoo time was a bit short lately. Nonetheless, I'll try to get at it again soon. I am changing the summary on this bug, to reflect the real issue. BTW, the final gnat (just as gcc itself) gets boostrapped off itself and will understand whatever -march you can legally throw at 4.3. So, the issue is really a minor one, but update is overdue at this point..
I just tried to emerge gnat-gcc on a new amd64 (Intel Core2 Duo) system and got the same error ("C compiler cannot create executables" and config.log ends with 77). I have -march=native -msse4.1 in CFLAGS in /etc/make.conf. I tried to remove only the first, but it did not work. Then I tried without both and it worked. Then I added them back and expected to be able to emerged gnat-gcc again. But it failed! so it seems to use the bundled bootstrap compiler even though the system has a working compiler.
My issue isn't so much that the bootstrap compiler is ancient, it's that the bootstrap compiler is ancient *and* doesn't understand modern CFLAGS in a way that causes the build to fail. This morning was at least the second time I've gone through config.log to diagnose this problem. It'd be nice, now that this bug has languished for six months, if we could get at minimum a note in the ebuild on failure explaining how to workaround.
Do you need any help to get this thing going, and in that case what is needed to be done?
>My issue isn't so much that the bootstrap compiler is ancient, it's that the >bootstrap compiler is ancient *and* doesn't understand modern CFLAGS in a way >that causes the build to fail. This is not so straightforward, as this would require keeping a database of good/bad flags. The best I can do is to pass the CFLAGS through test-flag-CC and abort in pkg_setup.. >Do you need any help to get this thing going, and in that case what is needed >to be done? Yes, actually: I just issued a new bootstrap based on gcc-4.3, however it is amd64 only, as I don't have ppc here and my 32bit chroot is long gone. I would appreciate if somebody would give me a built package (the tbz2 file you get in /usr/portage/packages/All by "emerge -b" or "quickpkg" if its already installed) of gnat-gcc-4.3.3 on x86 or ppc. I'll then package it properly for bootstrapping (it has a simplified layout with all the extra stuff removed and arch/release depended libs streamlined, to simplify setting dirs in gnatbuild.eclass). The x86 I can do myself, however that'd require more waiting as I would need to setup 32bit chroot again (so, even here, help would speed things along ;)). The ppc version I really need somebody else to do..
*** Bug 283457 has been marked as a duplicate of this bug. ***
On issuing gnat-gcc-4.4: This appears to be not a simple rename of an old ebuil. The build fails somewhere midway with obscure compile error and so this requires further investigation. Hopefully, I'll get to this reasonably soon (yea, I am really lagging on this, sorry about that). In terms of help, if somebody can trace the cause of error or even suggest an idea, that could move things along.. It might even be that new bootstrap will alleviate the problem..
(In reply to comment #6) > I would appreciate if > somebody would give me a built package (the tbz2 file you get in > /usr/portage/packages/All by "emerge -b" or "quickpkg" if its already > installed) of gnat-gcc-4.3.3 on x86 or ppc. Do you need the bootstrap from an machine running x86 och ~x86 or it does not matter? I have a gentoo x86 system running default/linux/x86/10.0, gcc-4.4.2, glibc-2.11-r1. Can it work and what CFLAGS/LDFLAGS should I use? (In reply to comment #8) > On issuing gnat-gcc-4.4: > This appears to be not a simple rename of an old ebuil. The build fails > somewhere midway with obscure compile error and so this requires further > investigation. For me it did not even work that far, gnat-gcc-4.3.3 complains about broken gcc (think it is my CFLAGs), and a renamed ebuild seems to break during eautoconf in the eclass. But lets fix an ebuild for portage ~arch that we can report bug against first.
http://xake.rymdraket.net/gnat-gcc-4.3.3.tbz2 Build command: LDFLAGS="" CFLAGS="-march=i386 -mtune=i386 -pipe -fomit-frame-pointer" emerge -b gnat-gcc Build system: Portage 2.2_rc61 (default/linux/x86/10.0, gcc-4.4.2, glibc-2.11-r1, 2.6.33-rc4 i686) ================================================================= System uname: Linux-2.6.33-rc4-i686-Intel-R-_Core-TM-_Duo_CPU_T2350_@_1.86GHz-with-gentoo-2.0.1 Timestamp of tree: Thu, 21 Jan 2010 16:30:23 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p35 dev-lang/python: 2.6.4, 3.1.1-r1 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.0 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.0 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.65 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=native -mtune=native -O2 -pipe -floop-interchange -floop-strip-mine -floop-block -fomit-frame-pointer -ftree-vectorize" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo" CXXFLAGS="-march=native -mtune=native -O2 -pipe -floop-interchange -floop-strip-mine -floop-block -fomit-frame-pointer -ftree-vectorize" DISTDIR="/var/portage/distfiles" FEATURES="assume-digests ccache distlocks fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.sunet.se/pub/os/Linux/distributions/gentoo" LANG="sv_SE.UTF-8" LDFLAGS="-Wl,--as-needed -Wl,-O1 -Wl,--sort-common -Wl,--warn-once,--hash-style=gnu" LINGUAS="sv" MAKEOPTS="-j3 -l10 " PKGDIR="/var/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/x11 /usr/local/portage/mine" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amr avahi bash-completion berkdb bzip2 cdr cli consolekit cracklib crypt cxx dirac dri dts dvd dvdr enca encode faac faad fbcondecor ffmpeg gdbm gif git gmp graphite gsm hal iconv idn ieee1394 jbig joystick jpeg jpeg2k lame laptop lzma mktemp mms mmx modules mp3 mpeg mpi mudflap musepack ncurses network network-cron nls nptl nptlonly ntp ogg opencore-amr opengl openmp optimization pam pcre png pppd quicktime rar readline reflection schroedinger session speex spl sse sse2 ssl strong-optimization svg sysfs tcpd theora threads tiff unicode vcd vorbis x264 x86 xorg xrandr xv xvid zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="sv" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Shouldn't matter, as long as it builds. Perhaps -march=i686 would be a nice common ground. You may go with i586 if you want to be extra safe, but I doubt you'll find anything below that or even i686 still functional today, not even mentioning that compiling gcc of 4.x series on something like that would be totally insane.. BTW, you don't need separate -mtune, as -march sets it. You use both if you want to force arch but tune for some special variant (then they are different). arch vs ~arch only regulates whether you will be able to emerge the particular version of a package. It does not affect the outcome. >For me it did not even work that far, gnat-gcc-4.3.3 complains about broken gcc >(think it is my CFLAGs), and a renamed ebuild seems to break during eautoconf >in the eclass. Ah, right. IIRC, when I tried it, there were few straightforward problems during autoconf, which I went around before it proceeded further. I'll need to look into this again. But indeed, lets complete the 4.x based bootstraps first.
http://xake.rymdraket.net/gnat-gcc-4.3.3-take2.tbz2 Build command: LDFLAGS="" CFLAGS="-march=i586 -pipe -fomit-frame-pointer" emerge -b gnat-gcc
Please also add -O2. There is not point in skipping it, besides it might not work properly without (IIRC there were problems with either gcc or glibc, even though long ago, it needed at least -O1)
(In reply to comment #13) > Please also add -O2. There is not point in skipping it, besides it might not > work properly without (IIRC there were problems with either gcc or glibc, even > though long ago, it needed at least -O1) > It was compiled with -O2, forgot to list it.
Thanks Xake! Almost done, but I forgot to ask you to dump specs for the 4.3 version. I need these for the wrapper used during build to force using the bootstrap compiler. Could you please activite the corresponding compiler (eselect gnat set x86-pc-linux-gnu-gnat-gcc-4.3, or whatever is the right name of it on x86, followed by . /etc/profile) and the do: gnatgcc -dumpspecs > specs and then attach this file here or put it up in the same place.. Thanks!
http://xake.rymdraket.net/specs.bz2
Thanks! ~x86 in, please test.
Are you planning a 4.4?
Yes, however this is not so straightforward. Please see my comment #8 above. BTW, did you have a chance to try the new (-r1) version with 4.3 bootstrap on x86? I'd appreciate a report, as I cannot test it locally.
Added ppc arch team to CC, as it is unlikely that users can help this issue on ppc any time soon. ppc team: could somebody please do: emerge -b =dev-lang/gnat-gcc-4.3.3 eselect gnat list eselect gnat set ppc-whatever-linux-gnu-gnat-gcc-4.3 source /etc/profile gnatgcc -dumpspecs > somewhere/specs and then let me grub the built "gnat-gcc-4.3.3.tbz2" and the "specs" files, so that I could complete issuing the bootstrap for all keyworded arches? (if you don't want to leave stable, there is 4.3.2 marked as ppc which will also do) Please see comments above if you have any questions.
I get: configure: creating ./config.status config.status: creating Makefile config.status: creating testsuite/Makefile config.status: creating config.h config.status: executing default commands In file included from /var/tmp/portage/dev-lang/gnat-gcc-4.3.3-r1/work/gcc-4.3.3/libiberty/regex.c:185: /usr/include/limits.h:125:26: error: no include path in which to search for limits.h make[3]: *** [regex.o] Error 1 make[2]: *** [all-stage1-libiberty] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [bootstrap] Error 2
(In reply to comment #21) > I get: > > configure: creating ./config.status > config.status: creating Makefile > config.status: creating testsuite/Makefile > config.status: creating config.h > config.status: executing default commands > In file included from > /var/tmp/portage/dev-lang/gnat-gcc-4.3.3-r1/work/gcc-4.3.3/libiberty/regex.c:185: > /usr/include/limits.h:125:26: error: no include path in which to search for > limits.h > make[3]: *** [regex.o] Error 1 > make[2]: *** [all-stage1-libiberty] Error 2 > make[1]: *** [stage1-bubble] Error 2 > make: *** [bootstrap] Error 2 > What is your emerge --info? For me it compiled fine. I have just not had the time to runtime test it.
emerge --info: Portage 2.2_rc61 (default/linux/x86/10.0, gcc-4.4.2, glibc-2.11-r1, 2.6.32-gentoo-r2 i686) ================================================================= System uname: Linux-2.6.32-gentoo-r2-i686-VIA_Esther_processor_1300MHz-with-gentoo-2.0.1 Timestamp of tree: Wed, 27 Jan 2010 01:45:01 +0000 app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4-r1, 3.1.1-r1 dev-python/pycrypto: 2.1.0 dev-util/cmake: 2.8.0-r1 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.0-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.65 sys-devel/automake: 1.10.3, 1.11.1 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-Os -march=i686 -mmmx -msse -msse2 -msse3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-Os -march=i686 -mmmx -msse -msse2 -msse3 -pipe" DISTDIR="/mnt/space/gentoo/distfiles" EMERGE_DEFAULT_OPTS="--keep-going" FEATURES="assume-digests buildpkg collision-protect distlocks fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" INSTALL_MASK="*.la" LDFLAGS="-Wl,-O1,--hash-style=gnu,--sort-common,--as-needed" MAKEOPTS="-j1 -s" PKGDIR="/mnt/space/gentoo/packages/chris" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/science /usr/portage/local/layman/x11 /usr/portage/local/layman/java-overlay /usr/portage/local/layman/sunrise /usr/portage/local/layman/stoile /usr/portage/local/layman/nx /usr/portage/local/layman/mpd /usr/portage/local/layman/pure-funtoo" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="acl apache2 bash-completion berkdb bzip2 caps cli cracklib crypt cups cxx dri fortran gd gdbm git iconv idn ipv6 jpeg jpeg2k ldap logrotate lua lzo mmx modules mudflap mysql ncurses nls nptl nptlonly pam pcre perl png postgres pppd python readline reflection session snmp spl sqlite3 sse sse2 sse3 ssl subversion sysfs tcpd tiff unicode vhosts x86 xattr xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, FFLAGS, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS I have not investigated teh problem any further. I will run tests with older versions to make sure, it's not some problem with my system.
(In reply to comment #21) > I get: > > In file included from > /var/tmp/portage/dev-lang/gnat-gcc-4.3.3-r1/work/gcc-4.3.3/libiberty/regex.c:185: > /usr/include/limits.h:125:26: error: no include path in which to search for > limits.h Sorry, looks like in 4.3 limits.h was moved to another include dir. I put all .h files together and reissued the bootstrap. Please resync and try again..
Looks like I got all the strange mistakes. It has been building for more than 23 hours now, which is a lottle too long. Normal are 3-4 hours. The server has been doing nothing during that time, which could explain the behaviour. ... /usr/bin/install -c -m 644 $h /var/tmp/portage/dev-lang/gnat-gcc-4.3.3-r1/image/${thd}; \ done; \ fi make[3]: Entering directory `/var/tmp/portage/dev-lang/gnat-gcc-4.3.3-r1/work/build/libiberty/testsuite' make[3]: Nothing to be done for `install'. make[3]: Leaving directory `/var/tmp/portage/dev-lang/gnat-gcc-4.3.3-r1/work/build/libiberty/testsuite' make[2]: Leaving directory `/var/tmp/portage/dev-lang/gnat-gcc-4.3.3-r1/work/build/libiberty' That is what I am seeing. I reattached the screen 15 minutes ago, nothing changed in that time. 23848 root 40 0 110m 106m 636 R 89.3 11.3 1062:46 gnatls This is a line from top. Gnatls seems to misbehave, I think.
Killed it after about 36 hours. Running "# /var/tmp/portage/dev-lang/gnat-gcc-4.3.3-r1/work/usr/bin/gnatls -v" by hand works just fine.
Sorry for neglecting this last issue for a while - I was not sure what to make of it and could not recreate this myself. However, yesterday's chat with Tomas Touceda made me realize that this seems to be limited to x86_32 and may be related to the new bootstrap. Therefore I reissued the bootstrap (thanks Thomas for building it in 32bit!) this morning. Please sync and try again. This was updated for gnat-gcc-4.3.4. The 4.3.3-rX's use older "updated" (4.3 based) bootstrap and 4.3.3 and before use old 4.1 based bootstrap. Anyway, the name of the new bootstrap file is: gnatboot-4.3-i686.tar.bz2 (just a way to check if you want to make sure its the right one). ppc team: bump on request for running a "quick" build? (comment #20)
On the 4.4 version, I am hiting this when trying to build last version (4.4.3 atm): checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[2]: *** [configure-stage1-zlib] Error 1 has anybody ever seen anything like that? Sadly, google is not very helpful, with the best (in fact the only) suggestion of editing the configure file to bypass the check.. Although, this happens in the -m32 section of bundled zlib (which though it shouldn't even touch since there is --with-system-zlib explicitly passed), so this may be related to multilib. Still, if anybody could explain just what that error is about..
I've put the specs up at http://dev.gentoo.org/~josejx/specs.gnat If you need anything else from PPC, please re-add us.
*** Bug 328741 has been marked as a duplicate of this bug. ***
Hm, now I am hitting the same issues with 4.3.5, but, interestingly, not 4.3.4. Something, apparently, has changed recently in gcc internals, and this should give me a better chance to understand what. Still, if toolchain people (just added to CC) could take a quick look and tell me if this rings a bell (pls see comment #28), that could save me quite a bit of trouble..
you'd have to look at the config.log from the relevant subdir. the error quoted (no link tests after GCC_NO_EXECUTABLES) can be caused by way too many different things. it just means an earlier test failed for some reason.
(In reply to comment #32) > you'd have to look at the config.log from the relevant subdir. Sorry for the delay. This is just as above - this happens during the principal configure in the zlib dir (even though --with-system-zlib is passed specifically) in the -m32 run on multilib profile(s). Incidentally, zlib dir was added in all new versions that fail and from the diff between 4.3.4 and 4.3.5 I see that there are not that many changes other than that. Definitely nothing else that seems to be related. So, I tried removing the zlib dir and it seems to proceed fine. Oh, I see with the --with-system-zlib - it has been removed. Instead,I guess, I could use --without-zlib (in lieu of removing the dir), but will this do something undesired? What is the recommended way to deal with zlib in later gcc?
Ok, just checked. --without-zlib is, apparently, ignored. This leaves removing the zlib dir as the only easy way around. Is this undesirable for any reason? So far I don't see any ill-effects.
The output of grep BOOT_SLOT=\"4.4\" -r /usr/portage/dev-lang/gnat-gcc indicates that this bug report should be closed.
