Summary: | dev-lang/gnat-gcc-4.3.4 - precompiled bundled gcc is linked against old libmpfr | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Graham Murray <graham> |
Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | crazycasta, dark, esigra, kanelxake, mgorny, pacho, phobosk, sascha_lucas |
Priority: | High | ||
Version: | 10.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Build log
configure log |
Description
Graham Murray
2010-07-05 20:18:53 UTC
Please attach the entire dev-lang/gnat-gcc build log and reopen this bug report. Created attachment 237659 [details]
Build log
The build log, as requested
Created attachment 237661 [details]
configure log
Reopening after providing the build and configure logs. Extra info: On my system libmpfr.so.1 was replaced by libmpfr.so.4 by the upgrade to dev-libs/mpfr-3.0.0 on 2010-06-20. I second this. The bundled gnat-gcc in the bin dir is linked against old mpfr and gmp. This is a packaging bug, Bootstrap bins should be linked statically NEVER dynamically against system libs. Temporary workaround: lrwxrwxrwx 1 root root 12 Jul 6 00:39 libmpfr.so.1 -> libmpfr.so.4 lrwxrwxrwx 1 root root 12 Jul 6 00:38 libgmp.so.3 -> libgmp.so.10 Should give you the ability to compile gnat-gcc. I guess this is one of the reasons why vapier tried to slot mpfr... (In reply to comment #6) Ha! The workaround works! Thank you. dev-lang/gnat-gcc-4.4.3 has the same problem dev-lang/gnat-gcc-4.3.5 has the same problem!!! Does anyone actually check before uploading to main gentoo tree if the ebuilds are building at all?!? BTW dev-lang/gnat-gcc-4.3.5 is missing libgmp.so.3 also: cc1: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory Sorry, many bugs open against ada (and little time - real life stuff..), missed this one, and yes, I do check stuff - apparently there was no problem building gnat on my side (and people were really pushing for 4.4 to get in). I'll look into this, but first I'll need to reproduce the issue. once mpfr-3 goes stable, we'll add an ABI mpfr-2. you could then simply depend on that. (In reply to comment #5) > Bootstrap bins should be linked statically NEVER dynamically > against system libs. Well, since gnat needs Ada-enabled compiler we need compiled gnat to build gnat, which is essentially gcc with another frontend. I was looking for how to build it statically, but all I can find are pointers on how this is hopeless. So, unless somebody can point me to the guide on building gcc statically, the only option is to issue a new bootstrap and readjust deps when mpfr gets SLOTted.. As far I as can see, this only affects x86, not amd64. Can anybody on ppc check whether it affects that arch? (In reply to comment #14) > As far I as can see, this only affects x86, not amd64. Can anybody on ppc check > whether it affects that arch? That is not right... one of the distroes i have the problem, is an amd64 gentoo... Another thing I am wondering: Would it be feasible to use an installed (and working) gnat compiler, for building? This would make it possible to link the gnat-gcc beeing built against the local newer libmpfr and in place not running into the same problem when newer version come out. This of course doesn'T help for an initial bootstrap, but updating would be a straight forward process I guess. (In reply to comment #16) > Would it be feasible to use an installed (and working) gnat compiler, for > building? In principle yes, but that would require quite a bit of mangling of the gnatbuild.eclass - the build logic will be more complicated for one (with detection of gnat, which one is present and setting all the paths appropriately as well..). It is far easier to just create a new bootstrap from the installed gnat (via quickpkg and then moving stuff around). Sorry, I am slipping on this again, it is just that releasing a broken bootstrap is the last thing we want in this situation and doing it carefully requires certain concentration for a while and I am a bit swamped in real life atm. But I do feel bad about it, honest :). I'll try to get to this next week perhaps.. No worries. It was just a though for another possibility making life easier. (In reply to comment #17) > (In reply to comment #16) > > Would it be feasible to use an installed (and working) gnat compiler, for > > building? > In principle yes, but that would require quite a bit of mangling of the > gnatbuild.eclass - the build logic will be more complicated for one (with > detection of gnat, which one is present and setting all the paths appropriately > as well..). It is far easier to just create a new bootstrap from the installed > gnat (via quickpkg and then moving stuff around). > > Sorry, I am slipping on this again, it is just that releasing a broken > bootstrap is the last thing we want in this situation and doing it carefully > requires certain concentration for a while and I am a bit swamped in real life > atm. But I do feel bad about it, honest :). I'll try to get to this next week > perhaps.. Ok, 4.4.5 is in, using new bootstrap. Sorry everybody for delay. Actually, the new bootstrap is only for amd64 at the moment; x86 is underway (I need to refresh my 32bit chroot first though). Still, I would appreciate test reports. While at it, I managed to remove the need for the shell wrapper for gnatgcc (some old versions did not use builtin pec automatically, thus the need in old times). So, overall procedure is cleaner and should result in "proper" version strings passed through during build. Also, if somebody can produce a .tbz2 for sparc, that would be great. I will be able, then, to issue the bootstrap for sparc too and close this bug completely. Same goes for ppc - last versions even lost the keyword, but if, by chance, an old one still builds, this should suffice. To produce the tbz2 file, just emerge --buildpkg gnat-gcc and just put the produced package to some accessible place. I am CCing relevant arches in the hope of getting some reaction. However if any users on the CC have access to sparc or ppc, this should be way faster. OK, I can generate a tbz2 for SPARC, I take it you'd like a generic SPARC build? Yes, generic -march please. You can still pass optimizations, like -O2/-fomit-frame-pointer or whatever is appropriate for sparc (just not too aggressive). OK, here's the package for gnat-gcc-4.4.3.tbz2, you can pick it up from http://www.munted.org.uk/programming/gnat-gcc-4.4.3.tbz2 Any problems, let me know. I've tested it by building and running my old ADA programs and all ran just fine. Thank Alex! I prepared the bopotstrap and updated the ebuild. Please test. In case you encounter problems with build complaining about missing .h files, please search for those on your system and put them under usr/lib/include in the bootstrap that it downloads, or simply upload them where I can get them, like before. I collected all the relevant .h files from the provided tbz2 file in that include dir, but there are more on amd64, so it might be that some are still missing (and they, naturally, have to come from a sparc system). *** Bug 301446 has been marked as a duplicate of this bug. *** >>OK, here's the package for gnat-gcc-4.4.3.tbz2, you can pick it up from
>I prepared the bootstrap and updated the ebuild. Please test.
So, I take it, no problems with new ~sparc bootstrap for 4.4?
Alex: could you please do the same for 4.3.5? I am "backporting" these fixes to 4.3, as there are some requests. Likely due to 4.4 not being yet stabilized. I am planning to remove 4.2 and 4.1 afterwards, so this should be the last such update, at least for near future.
Sigh...i(as the sparc team lead) don't plan to maintain this...if you want to maintain this on sparc, let me know and i can give access to the sparc dev box, otherwise go ahead and drop the keyword. Not sure if this is related or not but I can't emerge the 4.4.5 version. It acts as if the file does not exist reporting: --- Invalid atom in /etc/portage/package.keywords: cross-msp430/[latest] !!! 'dev-lang/gnat-gcc-4.4.5' is not a valid package atom. !!! Please check ebuild(5) for full details. (You can ignore the msp430 bit since that's in there from crossdev). It seems to be doing okay with: ebuild /usr/portage/dev-lang/gnat-gcc/gnat-gcc-4.4.5.ebuild merge This means: 1. The core issue of libmpfr.so.1/libgmp.so.3 seems to be fixed for me (libmpfr.so.1 failing was why I up went to 4.4.5 in the first place, 4.3.5 wasn't working). 2. Maybe there's something wrong with the way that 4.4.5 is written/put in the tree. P.S. I'd like to second the request for a backport of this fix to the 4.3 line. Ofc ideally the packages would just use 4.4.5, but ghdl for instance has not yet done this. IMHO the bad packages (at least 4.3.5 though I wouldn't be surprised if the older ones have the same issue) should be masked. Then it would be up to whoever's in charge of all the gnat packages to decide whether a working 4.3 package is needed or everyone should be forced to move up to 4.4. The existence of an unmasked broken package is deceptive because it allows all other packages to say "well just use 4.3.5". This is valid for them because 4.3.5 isn't masked and it isn't their job to know that 4.3.5 is really broken. sparc keywords dropped What is the current situation with 4.3.6? :/ removed |