dev-lang/gnat-gcc-4.3.2 fails to compile: C compiler cannot create executables I don't know if to compile is needed same version of that my gcc. Portage 2.1.9.42 (default/linux/amd64/10.0, gcc-4.4.5, libc-0-r0, 2.6.38-gentoo-r6 x86_64) ================================================================= System uname: Linux-2.6.38-gentoo-r6-x86_64-Intel-R-_Core-TM-_i3_CPU_540_@_3.07GHz-with-gentoo-2.0.2 Timestamp of tree: Fri, 17 Jun 2011 16:00:01 +0000 app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.1-r1, 3.2 dev-util/cmake: 2.8.4-r1 sys-apps/baselayout: 2.0.2 sys-apps/openrc: 0.8.2-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.9.6-r3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.5 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.82 sys-kernel/linux-headers: 2.6.36.1 sys-libs/glibc: 2.12.2 virtual/os-headers: 0 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -g0" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" 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.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2" DISTDIR="/media/sources" EMERGE_DEFAULT_OPTS="--with-bdeps y" FEATURES="assume-digests binpkg-logs collision-protect distlocks fixlafiles fixpackages multilib-strict news parallel-fetch protect-owned sandbox sfperms split-log strict test unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="it_IT.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" LINGUAS="zh af ca cs da de el es et fr gl hr hu it nb nl pl pt ro ru sk sl sv uk bg cy en eo fo ga he id ku lt lv mk ms nn sw tn zu ja zh_TW en_GB pt_BR ko zh_CN ar en_CA fi kk oc sr tr fa wa nds as be bn bn_BD bn_IN en_US es_AR es_CL es_ES es_MX eu fy fy_NL ga_IE gu gu_IN hi hi_IN is ka kn ml mr nb_NO nn_NO or pa pa_IN pt_PT rm si sq sv_SE ta ta_LK te th vi ast dz km my om sh ug uz ca@valencia sr@ijekavian sr@ijekavianlatin sr@latin csb hne mai se es_LA fr_CA zh_HK br la no es_CR et_EE sr_CS bo hsb hy mn sr@Latn lb ne bs tg uz@cyrillic xh be_BY brx ca_XV dgo en_ZA gd kok ks ky lo mni nr ns pap ps rw sa_IN sat sd ss st sw_TZ ti ts ve mt ia az me tl" MAKEOPTS="-j4" PKGDIR="/media/sources/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="/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl acpi alsa amd64 apache2 assistant bash-completion berkdb bzip2 cairo cd cdr cli cracklib crypt cuda cups curl cxx dbus device-mapper dri dvd dvdr encode extensions extras ffmpeg fontconfig fortran gdbm gnutls gpm gstreamer gtk iconv icu imagemagick imap ipv6 ithreads jadetex jpeg kde lame mmx mng modules mp3 mudflap multilib mysql ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcre pdo perl png policykit postgres pppd private-headers python qt3support qt4 readline sasl sdl semantic-desktop session sqlite sse sse2 ssl svg symlink sysfs tcpd threads tk truetype unicode v4l v4l2 vhosts vorbis webcam xcb xorg zlib zsh-completion" 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 cgi cgid 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" CALLIGRA_FEATURES="braindump flow karbon kexi kpresenter krita tables words" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="mouse evdev keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="zh af ca cs da de el es et fr gl hr hu it nb nl pl pt ro ru sk sl sv uk bg cy en eo fo ga he id ku lt lv mk ms nn sw tn zu ja zh_TW en_GB pt_BR ko zh_CN ar en_CA fi kk oc sr tr fa wa nds as be bn bn_BD bn_IN en_US es_AR es_CL es_ES es_MX eu fy fy_NL ga_IE gu gu_IN hi hi_IN is ka kn ml mr nb_NO nn_NO or pa pa_IN pt_PT rm si sq sv_SE ta ta_LK te th vi ast dz km my om sh ug uz ca@valencia sr@ijekavian sr@ijekavianlatin sr@latin csb hne mai se es_LA fr_CA zh_HK br la no es_CR et_EE sr_CS bo hsb hy mn sr@Latn lb ne bs tg uz@cyrillic xh be_BY brx ca_XV dgo en_ZA gd kok ks ky lo mni nr ns pap ps rw sa_IN sat sd ss st sw_TZ ti ts ve mt ia az me tl" NGINX_MODULES_HTTP="access auth_basic autoindex browser charset empty_gif fastcgi geo gzip limit_req limit_zone map memcached proxy referer rewrite scgi split_clients ssi upstream_ip_hash userid uwsgi addition cache_purge dav degradation flv geoip gzip_static headers_more image_filter perl push random_index realip secure_link stub_status sub xslt ey_balancer slowfs_cache upload" NGINX_MODULES_MAIL="imap pop3 smtp" PHP_TARGETS="php5-3" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nouveau nvidia" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 277471 [details] config.log
Created attachment 277473 [details] environment
Created attachment 277475 [details] Build log
gnat-gcc-4.3.2 conftest.c:1: error: bad value (native) for -march= switch ...rings a bell ?
if does not work with native, filter-flags should be called.
(In reply to comment #5) > if does not work with native, filter-flags should be called. Filtering -march is tricky, as the value needs to be filtered out and I don't see a "safe-march" substitution func in flag-o-matic. May be just removing -march outright? But that would have to include logics detecting current arch, maintaining "safe database".. Anyway, there is a better solution. I have finished adding new bootstraps for 4.4 which accepts all the flags that gcc-4.4 would (plus it resolves the libmpfr issue). Why don't you use that? Is there any particular reason you are sticking to 4.3? I am planning to produce new bootstraps for 4.3 too (needed for gnat-gpl), so this one will stay. But I am going to pull all the 4.2 and 4.1 versions after I am done with this. (Just a little heads-up, to let those who want it plan accordingly).
(In reply to comment #6) > Filtering -march is tricky, as the value needs to be filtered out and I don't > see a "safe-march" substitution func in flag-o-matic. May be just removing > -march outright? But that would have to include logics detecting current arch, > maintaining "safe database".. You can, imho, drop it...and is a simply job or replace -march flags like: 86? -march=i686 amd64? -march=x86_64 and so on. > > Anyway, there is a better solution. I have finished adding new bootstraps for > 4.4 which accepts all the flags that gcc-4.4 would (plus it resolves the > libmpfr issue). Why don't you use that? Is there any particular reason you are > sticking to 4.3? Yes, it is pulled in by another package that must be stabilized. We can wait ~30days, stabilize new gnat-gcc and reopen the other bug. Is a good idea?
(In reply to comment #7) > > Filtering -march is tricky, as the value needs to be filtered out and I > You can, imho, drop it...and is a simply job or replace -march flags like: > 86? -march=i686 > amd64? -march=x86_64 But this will have to be done conditionally, as the users will then complain that they cannout use their favorite -march=my_uberoptimizer_core_iX (that's why this issue surfaces in the first palce), and that means lots of extra conditionals. The other approach (bumping bootstrap) is cleaner and just simpler. > > sticking to 4.3? > Yes, it is pulled in by another package that must be stabilized. Ok then, I'll prioritize the 4.3 bootstrap then. Should be able to finish amd64 and x86 this week. The change is largely cosmetic (relink against new mpfr and remove an ugly wrapper) and should not perturb the stability, and its a fix anyway. > > We can wait ~30days, stabilize new gnat-gcc and reopen the other bug. Is a good > idea? Stabilizing the 4.4.5 is a good idea in any case, as it is de-facto the most stable one atm.
(In reply to comment #8) > But this will have to be done conditionally, as the users will then complain > that they cannout use their favorite -march=my_uberoptimizer_core_iX (that's > why this issue surfaces in the first palce), and that means lots of extra > conditionals. The other approach (bumping bootstrap) is cleaner and just > simpler. OK, the best solution should be: if -march=native then exit 1 (is only pseudo code) and elog to set gnat-gcc in package.cflags with a correct -march or temporarily in make.conf. Anyway if the latest gnat-gcc:4.4 must be stabilized, i think that this problem can be skipped ;)
If gnat-gcc-4.4.4 is better than 4.4.3, then yes. emerged gnat-gcc-4.4.3, also pulled up with the same malady. Be prepared for shortcomings for 4.4. Usually 'Can't create executables' is related to a linkage flaw, but none evident in this. The gnat-gcc-4.4.3 only emerged in gentoo and64 testing, by both gcc 4.5 and 4.4. Suggests some package is "missing" in stable to support it compiling.
*** Bug 380263 has been marked as a duplicate of this bug. ***
Ok, I've added 4.3.6 with a new bootstrap. Sorry for delay, did not finish that up before going out for most of the summer. It is in now anyway. ATM only ~amd64, but should add x86 today/tomorrow. I had to issue a new version and drop keywords, as some modifications to ebuild were necessary to accomodate new bootstrap. Now, if only I could get someone to give me a 4.3 tbz2 file for sparc, I could issue a new bootstrap for that one too.. After I am done with this, I am going to pull 4.2 and 4.1 (and old 4.3) versions and this issue (along with mpfr one) should be gone for good.
Since this is the bug where we held stabilization discussion, I'll put this one here. Would it help packages depending on gnat if I were to add stable indication to virtual/gnat? For that I'll need to add more ebuilds with minor versions, as atm last ppc stable is 4.3.2 and first 4.3 x86/amd64 stable is 4.3.5. The virtual will not be as tidy, but that should allow stable versions to propagate. Then whatever wants gnat and wants to be stable could depend on virtual/gnat rather than specific gnat implementation.
(In reply to comment #13) > Since this is the bug where we held stabilization discussion, I'll put this one > here. > > Would it help packages depending on gnat if I were to add stable indication to > virtual/gnat? For that I'll need to add more ebuilds with minor versions, as > atm last ppc stable is 4.3.2 and first 4.3 x86/amd64 stable is 4.3.5. The > virtual will not be as tidy, but that should allow stable versions to > propagate. Then whatever wants gnat and wants to be stable could depend on > virtual/gnat rather than specific gnat implementation. Currently there is only one implementation satisfying that virtual, and packages seem to ignore it, depending on gnat-gcc directly. Why do we have the virtual? (I don't know the history...) I don't see much difference in stabelizing the virtual. Ebuilds can depend von gnat-gcc or a slot of it if they wish, so you may skip the hassle of stabilizing the virtual and instead remove it.
(In reply to comment #14) > Currently there is only one implementation satisfying that virtual, and > packages seem to ignore it, depending on gnat-gcc directly. Why do we have the > virtual? (I don't know the history...) You are only looking at the latest SLOTs ;) The reason for virtuals: Ada is considered a "conservative" language with a defined strict standard to which compilers have to adhere. As such, it should be (and largely is) possible to substitute one compiler for another - a perfect situation for a virtual. As it happens, there are two, almost equivalent, gnat compilers, both actively maintained and both present in the tree. gnat-gcc, supported by FSF (gcc) people and gnat-gpl - a GPL version of AdaCore's compiler. First is a "close to gcc" implementation, sticking to the latest backend but grabbing only "already public" parts specific to Ada. gnat-gpl is a "straight from builder's" version - incorporating the latest features (Ada-2005 and even Ada-2011 wise), but it traditionally lags on the backend. For most of the stuff they may be substituted freely, but there may be a difference in the support of latest features.. At present we have both in the tree, although I have not added the latest gnat-gpl yet, plus its traditional lag of backend.. As such, you need to look at the 4.1 circa to see both of them listed in virtual, although even there gnat-gpl-4.1series provide Ada-specific features on par with latest gnat-gcc. There is a new version out, to which I should get right after sorting out 4.3 bootstraps, and this ine is based on the 4.3 backend. So, the virtual will be appropriately full soon again :). As far as stable packages are concerned, the gnat-gpl variant is considered more conservative and, accordingly, more stable. It is, in fact, practically identical to the commercial one (from ACT), sans the support. Therefore, it would make sense to heavily emphasize that one for the stable profile, when I get to it. Thus the virtual will have to be expanded a bit, looks like there is no way around it. I just wanted to get an impression from people dealing with packages using Ada - how they prefer it, and to warn them of the impeding additions :).
(In reply to comment #15) > (In reply to comment #14) > > Currently there is only one implementation satisfying that virtual, and > > packages seem to ignore it, depending on gnat-gcc directly. Why do we have the > > virtual? (I don't know the history...) > You are only looking at the latest SLOTs ;) > > I just wanted to get an impression from people dealing with > packages using Ada - how they prefer it, and to warn them of the impeding > additions :). As you can tell from my blatant ignorance of these matters, I'm not among them. I'm just here for the x86 arch team. As for the stable tree, your plans sound very convincing to me.
(In reply to comment #16) > I'm just here for the x86 arch team. As for the stable tree, your plans sound > very convincing to me. Thanks! So, just to be clear - on the stabilization of virtuals. As there is nothing really to test, can I just add proper ebuilds/dependencies myself, or is it still supposed to go through arch teams in some way?
(In reply to comment #17) > (In reply to comment #16) > > I'm just here for the x86 arch team. As for the stable tree, your plans sound > > very convincing to me. > Thanks! > So, just to be clear - on the stabilization of virtuals. As there is nothing > really to test, can I just add proper ebuilds/dependencies myself, or is it > still supposed to go through arch teams in some way? I'd say yes for versions that just depend on already stable gnat versions. After this initial virtual-stabilization, you would probably file normal stabilization requests (e.g. virtual + new version of gnat-? together)
I just tried to emerge dev-lang/gnat-gcc-4.3.6 and still got the libmpfr.so.1 error. I thought that was the version with the relinked bootstrap?
(In reply to comment #19) > I just tried to emerge dev-lang/gnat-gcc-4.3.6 and still got the libmpfr.so.1 > error. I thought that was the version with the relinked bootstrap? Yes, it is. I just retried building it (x86, libmpfr.so.4.0.1, no libmpfr.so.1 link), seems to be fine..
(In reply to comment #20) > (In reply to comment #19) > > I just tried to emerge dev-lang/gnat-gcc-4.3.6 and still got the libmpfr.so.1 > > error. I thought that was the version with the relinked bootstrap? > Yes, it is. > I just retried building it (x86, libmpfr.so.4.0.1, no libmpfr.so.1 link), seems > to be fine.. Now I can't test it because gnatboot-4.3-amd64.tar.bz2 is missing (Portage tried to download it from gentoo.arcticnetwork.ca, mirror.csclub.uwaterloo.ca, gentoo.osuosl.org, gentoo.ussg.indiana.edu, gentoo-distfiles.mirrors.tds.net, and ftp.halifax.rwth-aachen.de; 404 in all cases).
(In reply to comment #21) > Now I can't test it because gnatboot-4.3-amd64.tar.bz2 is missing Looks like it has been pulled from the mirrors, sorry about that. I changed the SRC_URI to reflect recent infra changes (now we are encouraged to keep files in a special dev place, whereas earlier we were discouraged. Apparently, mirrors started removing unlinked stuff recently as well). Please resync in 30+ min and try again. I'll try rebuilding in the evening, to test it again (faster machine).
Created attachment 302085 [details] The build log This, from an emerge sync today, building dev-lang/gnat-gcc-4.3.6. Did you maybe only relink x86 and not amd64 bootstrap?
No, the relinking was for all. However, due to this mess with uploading stuff directly to mirrors, I apparently forgot to put it to my dev space as well. When reuploaded version got removed from mirrors it started to be pulled directly from the site, where the old lied... Anyway, I reuploaded it where proper and adjusted Manifest to match. Now you should be getting the correct one (give some time for changes to propagate. I hope mirrors pick it up properly and I don't have to changethe name of the file as well). Sorry about this.
Looks like the fixed bootstrap worked its way in and fixed stable 4.3.5 as well; I now see no trouble with march=native or libmpfr.
dev-lang/gnat-gcc-4.3.2 does not seemt to exist. Is this bug report obsolete? If it happens with a version that exists, please update the subject line.
the current stable seems to be fixed.
