Summary: | dev-lang/gnat-gcc-4.3.2 fails to compile: C compiler cannot create executables | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | ada team [OBSOLETE] <ada+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra, msulli1355, tomka |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
config.log
environment Build log The build log |
Description
Agostino Sarubbo
2011-06-18 12:38:45 UTC
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. |