I stupidly installed Gentoo thinking it would have decent Ada support, how wrong was I? So, I'd like to try to start a constructive thread about how this can be rectified.
I've have a look around portage for Ada related stuff, the unmasked available compiler is ancient, so no chance of Ada 2012 (the version I use now). The unmasked latest version is 4.6.4, still ancient and doesn't seem to build cleanly at all failing at the last step with a missing /etc/ada/primary_compilers, whatever that is, then it doesn't add the compiler to the usual PATH.
Seems there aren't many Ada developers for Gentoo, George and Nerdboy (who I know from #Ada). Nerdboy tells me that George has gone off to a warzone, so there'll be no Ada update on Gentoo for god knows how long. Nerdboy's ebuilds don't work for me, told him, got no reply. Are there any other Ada developers here? Please chime in and show who you are.
From looking at how the compilers are built, it seems that fortran, go and c++ all have USE flags, why doesn't Ada have a USE flag for gcc? That would make a lot more sense. That way the compiler would be a first class citizen on Gentoo rather than the ugly stepchild it currently is. People will probably argue that the GPL GNAT would be a conflicting package, why can't they sit along side each other?
Also, the gnatboot archive is a little strange, having the gnat1 and cc1 compilers in /usr/bin, is there a reason for this?
On a side note, I have scripts that I've been using for a while to get access to updated GNAT/GCC trees, I build most of the compilers in my scripts, but it gives me access to the latest 2012 features of the language. I've been using one I built on Debian successfully on Gentoo since I realised the state it was in here. That is, until I tried an interlanguage linking, seems 4.9 introduces an ABI change re libstdc++ that hasn't been rectified, I'm trying to wrack my brain to remember what it was, but I think it was time related. I don't have a log of the build and I can't remember what it was I was linking (as soon as I remember I'll retest and post the result, I did find a thread about it online as well).
Thanks,
Luke.
The state of Ada on Gentoo
Message
I saw it, and left no comment because I had nothing to say. To be perfectly honest, I've never actually done anything with Ada besides look at it and fiddle around with it some. Back in the day I did a pile of stuff with Pascal (Extended of course, is there any other useful kind of Pascal?) and did quite a bit with Modula-2, again extended.
As far as I can tell, Ada is about the only surviving strongly-typed language. In this day when buffer overflows and unreferenced pointers are still a problem, it's rather annoying that the road not taken was quite plainly there and functional.
I keep thinking that some time when I have more time I might try Ada again.
As far as I can tell, Ada is about the only surviving strongly-typed language. In this day when buffer overflows and unreferenced pointers are still a problem, it's rather annoying that the road not taken was quite plainly there and functional.
I keep thinking that some time when I have more time I might try Ada again.
.sigs waste space and bandwidth
Actually, I hadn't seen your message. It's not every time I look in the Portage & Programming forum. Since it gets a lot of traffic, new topics can get buried pretty quickly.Lucretia wrote:131 views and nothing? I can only assume nobody cares about Ada on Gentoo then?
In any event, a few months ago I looked at building an Ada package not only on Gentoo (the easy part) but also for portability to other OS's, including Mac OSX. (Man, am I ever glad I don't use that routinely!) I got hung up trying to figure out what I should do for strings. There were three basic strings packages to work through, but I didn't know enough of the language to sort out well what would be the best to use
What I didn't do was look very far into how gnat-gcc gets built, let alone gnat-gpl, which I never tried.
As to your question as to why there is no ada USE flag whereas there is one for cxx, fortran, go, and gcj, I suspect that the reason is that gnat has to be bootstrapped: the source for the Ada compiler is written in Ada. Bootstrapping is a bit tricky. The eclass that supports the gnat ebuilds (/usr/portage/eclass/gnatbuild.eclass) is 24k long, making it longer than the average eclass. (Eclasses are include files for ebuilds.) The gnatboot tarballs required for bootstrapping are more than 20 megabytes long. I see that gnat-gpl uses that same eclass.
In case you hadn't guessed, bootstrapping is how one gets around the chicken-and-egg problem implicit in a self-hosted language. The first stage for building the compiler is to make an interpreter or simple compiler for the language using a compiler for an available language (typically C). This gets you a compiler or interpreter that usually lacks features and is inefficient. The build process then uses this compiler generate something that is fiinally usable--or maybe requires another iteration or two to get to usability. Finally, with the target compiler in place, the build system is now in a position to build the language's standard libraries. I haven't looked through gnatboot, but I'm sure that's what explains its complexity. What I don't know is why the bootstrap-process' intermediate stages would be installed in the final emerge except that they are useful somehow in the production environment.
Another element complicating the ebuilds is that there are separate per-architecture patches. These *might* be unnecessary in later versions of Ada, but I don't know.
You asked about installing gnat-gpl alongside gnat-gcc. That kind of installation ought to work OK when the two packages happen to refrain from installing any file to a path that the other one uses, but this pair of packages can't do that: they both need to expose commands like gnat and gnatbind, after all. Gentoo does offer a way out, though. There is an eselect module that lets you change from one gnat provider to another. You can have gnat-gcc and gnat-gpl installed at the same time. Here is a command I ran on machine with its output shown:
Code: Select all
mike@host ~ $ eselect gnat list
Available gnat compilers:
[1] x86_64-pc-linux-gnu-gnat-gcc-4.3 *One thing I have not been able to tell so far is where you would find Ada 2012 support. My guess off hand is that gnat-gpl is more likely to have it than gnat-gcc. The announcements at adacore point to gnat-gpl's having v 2012 support even if the editions FAQ does not indicate this. Does gcc also support Ada 2012? When you refer to 4.9, do you mean gcc or gnat-gpl?
It seems to me that there aren't a whole lot of Ada developers period, let alone in Gentoo. Gentoo is, itself, on the relative fringe. So yes, you're multiplying two small fractions.Lucretia wrote:Seems there aren't many Ada developers for Gentoo
That said, I don't know what might keep Ada developers away from using Gentoo except what would be the deal-killer: iffy compiler support. So let's look for a remedy.Oftentimes ebuilds will work pretty much unchanged from one version of a package or another, but sometimes not. The gnat-gcc-4.5.4 ebuild is not awfully different from the 4.6.4 ebuild, but the error message you found indicates that there should likely be some larger difference. It's accounting for such changes that can make ebuilds "fun" to maintain.
I haven't tried it out, but maybe something I can do in the next day or so is try setting up a later version of gnat in an overlay and seeing how I come out with the ebuild. I'm not super-experienced in this, but I can try my luck.
What would help to know is where you got your packages. For gnat-gcc, this means knowing what versions of GCC have Ada 2012 support (if any do) and, importantly, if these GCC versions are stable in Gentoo. For gnat-gpl, that means knowing if I can get the source tarballs without signing my life away. I don't know if you've heard of fetch restrictions. That's the unhappy fact of life that some upstreams have chosen to make it so that Portage can't simply download the tarballs: the user must go through manual license-agreement or registration steps before getting the goods.
Ada 2012 support has been in GCC .4.x for ages, just varying quality and has really become really usable from around 4.7.x upwards.
What I want to do is get rid of this Frankenstein approach to an Ada compiler, have no weird separate GNAT tree based on a different lesser version of GCC than the main system compiler, had enough of that on Debian, tbh. Just because GNAT has to have an Ada compiler to build is irrelevant, we just need bootstrap packages and there are some, whether they can compile the later GNAT's I'm not so sure.
I only build FSF GNAT's so there'll be no download restrictions. But there should also be a GNAT GPL ebuild, but like you say, that can go into a separate slot as AdaCore do provide a full compiler, C, C++ and Ada (probably others too) and if you're building it from scratch, well there's no reason you cannot apply the same use flags to that ebuild.
I want to make Ada a first class GCC language at the system compiler level, i.e. USE=ada turns on the compiler support for that language.
So, is there any reason why this can't be done? What's the best way to start?
Thanks,
Luke.
What I want to do is get rid of this Frankenstein approach to an Ada compiler, have no weird separate GNAT tree based on a different lesser version of GCC than the main system compiler, had enough of that on Debian, tbh. Just because GNAT has to have an Ada compiler to build is irrelevant, we just need bootstrap packages and there are some, whether they can compile the later GNAT's I'm not so sure.
I only build FSF GNAT's so there'll be no download restrictions. But there should also be a GNAT GPL ebuild, but like you say, that can go into a separate slot as AdaCore do provide a full compiler, C, C++ and Ada (probably others too) and if you're building it from scratch, well there's no reason you cannot apply the same use flags to that ebuild.
I want to make Ada a first class GCC language at the system compiler level, i.e. USE=ada turns on the compiler support for that language.
So, is there any reason why this can't be done? What's the best way to start?
Thanks,
Luke.
Frankly, I have my doubts about the feasiblity of getting gnat via USE=ada applied to gcc. Gcc, after all, is a critical component of Gentoo, a fundamental part of the installation process. It's not hard to find discussions on how problems in new upstream versions of GCC delay stabilization of these versions. Sometimes there have to be Gentoo-specific patches.
Now throw in gnat, which, given the large size of the gnat eclass, the complexity of gnatboot, and wonkiness like that to which you allude in the language bindings in gcc 4.9, would mean even more problems for the Base System team in stabilizing new versions of GCC. Indeed, there is no mechanism in Gentoo to say that package X is stable except when the Y USE flag is applied. Considering that GCC is in the critical sys-devel category, I doubt they'd ever want that.
The main problem with Ada in Gentoo is that people like Steve Arnold and George Shapovalov have not been keeping up. From what I can gather, managing the bootstrap process is a bit tricky. Also, it is quite possible that the gcc 4.9 problems are from an upstream regression. It would be Really Bad if your Ada compiler were tied up to a new slick version of GCC that didn't play nice with its gnat side. You'd have to eselect an older gcc to make gnat work and then eselect to the newest because some package liked that one better.
So, be careful what you wish for! I really suspect it is better to think in terms of keeping up with patches applied to a version of gcc that is well known to work properly with gnat. The only thing is to do them often enough.
There are precedents for this situation of packages that are patches of other source packages. There are several kernel patchsets out and around, like tuxonice, ck, hardened, and yes, even gentoo. All of these patchsets lag behind the official Linux sources, sometimes by a good way (though gentoo-sources does stay pretty close to the tip, others are more laggy). There was a series of patches called Suhosin that applied to PHP; the maintainers gave up after trying to patch every PHP version. Gentoo's own eudev is basically a patched version of, ahem, something which will go nameless.
So, I'll take a look at the gnat-gcc ebuild. *Maybe* I'll see things about it that would make think it could be merged into sys-devel/gcc, but I'm doubtful about that. The big thing is to get up-to-date Ada support into Gentoo.
Now throw in gnat, which, given the large size of the gnat eclass, the complexity of gnatboot, and wonkiness like that to which you allude in the language bindings in gcc 4.9, would mean even more problems for the Base System team in stabilizing new versions of GCC. Indeed, there is no mechanism in Gentoo to say that package X is stable except when the Y USE flag is applied. Considering that GCC is in the critical sys-devel category, I doubt they'd ever want that.
The main problem with Ada in Gentoo is that people like Steve Arnold and George Shapovalov have not been keeping up. From what I can gather, managing the bootstrap process is a bit tricky. Also, it is quite possible that the gcc 4.9 problems are from an upstream regression. It would be Really Bad if your Ada compiler were tied up to a new slick version of GCC that didn't play nice with its gnat side. You'd have to eselect an older gcc to make gnat work and then eselect to the newest because some package liked that one better.
So, be careful what you wish for! I really suspect it is better to think in terms of keeping up with patches applied to a version of gcc that is well known to work properly with gnat. The only thing is to do them often enough.
There are precedents for this situation of packages that are patches of other source packages. There are several kernel patchsets out and around, like tuxonice, ck, hardened, and yes, even gentoo. All of these patchsets lag behind the official Linux sources, sometimes by a good way (though gentoo-sources does stay pretty close to the tip, others are more laggy). There was a series of patches called Suhosin that applied to PHP; the maintainers gave up after trying to patch every PHP version. Gentoo's own eudev is basically a patched version of, ahem, something which will go nameless.
So, I'll take a look at the gnat-gcc ebuild. *Maybe* I'll see things about it that would make think it could be merged into sys-devel/gcc, but I'm doubtful about that. The big thing is to get up-to-date Ada support into Gentoo.
I'm not sure I follow everything above.
But the one thing you keep mentioning is this Gnat ebud you intend to look into. You shouldn't need tgat. I've built GCC with ada support loads of times myself, you --enable-languages=ada,... The only thing that needs adding for a native compiler is grabbing a bootstrap compiler for Ada to use in the build. That ebud is quite large and uneccessary IMO.
Luke
But the one thing you keep mentioning is this Gnat ebud you intend to look into. You shouldn't need tgat. I've built GCC with ada support loads of times myself, you --enable-languages=ada,... The only thing that needs adding for a native compiler is grabbing a bootstrap compiler for Ada to use in the build. That ebud is quite large and uneccessary IMO.
Luke