Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
gnat 2005 (ada compiler) was released in September, but there's no ebuild yet. Reproducible: Always Steps to Reproduce: 1. 2. 3.
There's no "gnat 2005". http://www.ada-auth.org/amendment.html http://www.adaic.com/standards/ada05.html http://www.gnat.com/ada_2005.php
Ok; I was wrong - it does, although it isn't actually an implementation of 'Ada 2005' since that standard does not yet exist in anything other than draft form. https://libre2.adacore.com/ https://libre2.adacore.com/dynamic/download_page I'm not sure that the additional license clause "The GNAT GPL Edition is licensed solely for Free Software development" can be supported. I suppose one might have to develop an LGPL version of the gnat libraries if they're not LGPL, but GPL does not restrict commercial distribution of code generated by GCC.
Well, I think this licensing mode is rather similar to Qt licensing model. And well, if the libraries are GPL you're forced to license your code as GPL aswell, so I don't see any restriction in GNAT GPL edition only for Free Software development, since the GPL libs imply that. I'm no expert though, so I'm probably wrong.
I've looked in to this a bit, and in the GCC distribution, the run-time components and libraries all seem to have a variant of the 'libgcc exception' (I haven't looked at the gnat2005 distribution from AdaCore, only GCC): -- As a special exception, if other files instantiate generics from this -- -- unit, or you link this unit with other files to produce an executable, -- -- this unit does not by itself cause the resulting executable to be -- -- covered by the GNU General Public License. This exception does not -- -- however invalidate any other reasons why the executable file might be -- -- covered by the GNU Public License. -- I did a spot check on the Ada libraries (a-*.ad[sb]), Interfaces (i-*.ad[sb]) and System (s-*.ad[sb]) and this clause is on all of them (except those that are verbatim from the LRM, in which case the GPL is not relevant). This means that an application built with GCC and linked to the GNAT run-time libraries and/or including GNAT run-time components does not have to be licensed under the GPL. Perhaps the gnat2005 distribution from AdaCore includes a different implementation of some of this and is licensed differently.
(In reply to comment #4) > I've looked in to this a bit, and in the GCC distribution, the run-time > components and libraries all seem to have a variant of the 'libgcc exception' > (I haven't looked at the gnat2005 distribution from AdaCore, only GCC): > > -- As a special exception, if other files instantiate generics from this -- > -- unit, or you link this unit with other files to produce an executable, -- > -- this unit does not by itself cause the resulting executable to be -- > -- covered by the GNU General Public License. This exception does not -- > -- however invalidate any other reasons why the executable file might be -- > -- covered by the GNU Public License. -- > > I did a spot check on the Ada libraries (a-*.ad[sb]), Interfaces (i-*.ad[sb]) > and System (s-*.ad[sb]) and this clause is on all of them (except those that > are verbatim from the LRM, in which case the GPL is not relevant). > > This means that an application built with GCC and linked to the GNAT run-time > libraries and/or including GNAT run-time components does not have to be > licensed under the GPL. > > Perhaps the gnat2005 distribution from AdaCore includes a different > implementation of some of this and is licensed differently. > I have done some digging on this isue as well, and GCC GNAT and GNAT Pro 5.03 uses the same licence, while GNAT GPL 2005 has the above cited exception removed. According to AdaCore, this will only affect people distributing binaries compiled with GNAT GPL. Unlike Trolltech (QT) they do allow you to develop using GNAT GPL, do a final compile with GNAT Pro, and release as non-GPL. (https://libre2.adacore.com/dynamic/gnat_faq.html) As far as I can find out, that exception is the only difference between GNAT Pro 5.03 and GNAT GPL 2005, but as I don't have access to GNAT Pro 5.03 I can't say for sure. Timeing of releases differs though, GNAT Pro has so far, and most likely will continue to be, released more often and earlier than GNAT GPL. Interesting enough is that as I understand it anyone who purchases GNAT Pro 5.03 can legaly redistribute it, as it it's libraries is under the GMGPL (GNAT Modified GPL, i.e. GPL with above cited exception), and it's tools is under GPL (as they are derivates from GCC). Not sure about the bundled GPS (GNAT Programming Studio) 3.0 though. GNAT GPL 2005 comes with GPS 2.1, under GPL. Historically, when AdaCore released a GNAT Pro 3.xx version it was initialy only availible under GMGPL for paying customers, and later the same release, under the same licence, was made availible for download. This seems to have changed however, and replaced with a GPL-only release. Basicly GNAT Pro is the official AdaCore release, and "[GNAT Pro] is the only Ada 95 implementation to have been fully validated" (http://www.gnat.com/gnatpro_summary.php). 3.xx is based on GCC 2.8 backend, 5.xx is based on GCC 3.4 backend. GNAT GPL is a direct derivate of GNAT Pro 5.xx, that is GPL only and availible for download. GCC GNAT (>=3.3) is the FSF version. It's GNAT component is based on the canceled GNAT Pro 4.xx series (based on GCC 3.2 backend), that was quite broken, but GCC GNAT has been fixed and is (almost) usable in 3.4.x and even better in 4.0.x. GCC GNAT is availible on more platforms than GNAT Pro and GNAT GPL, but fully validated on none. In the spirit of Gentoo, users should be able to choose, and imho the current dev-lang/gnat package should be split in 3: dev-lang/gnatpro (including current 3.14 and 3.15 ebuilds, and, if a Gentoo developer has access to it, a 5.03 ebuild) dev-lang/gnatgpl (a GNAT GPL 2005 ebuild, with an ewarn that libraries is GPL-only) dev-lang/gccgnat (including current 3.4x ebuilds renamed as 3.4.x, as well as an 4.0.2 and future 4.1.x ebuilds) I'm no gentoo dev (only a user) but has been writing/modding ebuilds and would be willing to help testing (on x86 and amd64) anything a real dev creates. Regards - Jon Severinsson
Hi Jon. Thanks for this clarification! I agree, it would be usefull to split gnat into different packages, however we should plan this carefully: It should play nicely with SLOTting that we are considering to do. Splitting will provide some flexibility, however still there are gcc backend changes within all split compilers and we better deal with it. So I gather that we now have gnat developed by two different communities? gnatpro and gnatgpl by Ada core and gnatgcc by gcc people? As such, what are the projections for the gnatgcc? We are thinking about enabling ada support in gcc starting probably with gcc-4.1, effectively removing the need for the separate gnat package. So, I can see two possible layouts of this split: 1. We produce 3 separate packages now, gnatgcc is joined with gcc at a later point. We keep older version of gnatgcc for a while (probably couple of years, until gcc-4 is considered stable everywhere, possibly until gcc-3 is removed from the tree, which is much longer). 2. We do not rush with 3 packages now, in fact we don't bother wuth gnatpro at all, pointing interested users at what becomes of gnatgpl - the ebuilds should be almost identical anyway. Instead we sort things out, do SLOTting, et all in existing gnat. Meanwhile gcc-4.1 comes around and we enable ada support in it. At this point we issue gnat-5, which is now gnatgpl and possibly remove older gnatgpl versions. Thus in the end we have gcc with ada support and gnat for gnatgpl version.. SLOTting is necessary in both cases, however 2nd one is quite messy - we need to be more carefull with SLOTs, gives less flexibility, the only (disputable) upside is that is it kind of "easier" on user, having only one gnat in the tree. However confusion stemming from ada in gcc vs provided gnat will be enough.. So, in short I think the cleanest layout is to have tree SLOTted packages: gnatgpl and gnatpro, SLOTs 3.15, 5.x gnatgcc, SLOtted against appropriate gcc version, joining up with gcc in future.. However this will be for the long term Ada maintainer to deal with. Speaking of which: we need people. Right now I am sidetracking from my Scientific Gentoo duties and David Hold is bisy with ppc stuff and does not have good internet connection. We need at least one more developer, who would assume responsibility over Ada domain. Jon: I see majority of your bugzilla submissions deal with NX, but you clearly are interested in Ada, would you be willing to join up? As for gnatpro, we clearly will need an access to the package, however I think it may be possible to negotiate with Ada Core - we will need to explain them the way distribution works under Gentoo. The ebuilds will have proper fetch restrictions and will come with appropriate license, so customers will have to go to them in any case, we basically just need a source and some "local" licenses for testing.. We can look into it at a proper time, I guess after we get gnatgpl and SLOTs working.. George
(In reply to comment #6) > Hi Jon. Hi George > Thanks for this clarification! I agree, it would be usefull to split gnat > into different packages, however we should plan this carefully: > > It should play nicely with SLOTting that we are considering to do. Splitting > will provide some flexibility, however still there are gcc backend changes > within all split compilers and we better deal with it. I agree fully. > So I gather that we now have gnat developed by two different communities? > gnatpro and gnatgpl by Ada core and gnatgcc by gcc people? As such, what are > the projections for the gnatgcc? Yes, there are two different sets of gnat developers: AdaCore and FSF (GCC). I'm involved in neither, but as far as I can deduct GCC 3.3 and 3.4 was done without help from AdaCore, but with access to their in-progress GNAT Pro 4.xx sources (through anonymous cvs). Now AdaCore states on their libre website that they "contributes all its work on the GNAT compiler to the FSF under the auspices of the GCC project", but to what extent these code contributions actually is implemented in GCC 4.x I don't know. As far as I can deduct, AdaCore is the main developer, gcc is mainly keeping up and porting to otther architectures. However, GCC people are continuing to improve ada in GCC 4.x, so it won't end up "unmaintained" again as it was in GCC 3.0-3.2 (as noone ported gnat from the 2.x backend to the 3.x backend). > We are thinking about enabling ada support in gcc starting probably with > gcc-4.1, effectively removing the need for the separate gnat package. Interesting. I do see some problems if you introduce a gnat use-flagg and someone first enables it, and then wants to rebuild gcc with it enabled though... Another interesting point is that last I checked the java herd was thinking of doing the opposite with gcj, as people generaly don't want to upgrade their core C/C++ compiler as often as their speicial-purpose compilers (gcj/gnat). This is perhaps a worse problem for gcj, as it is in very hevy development, and gcj 4.0 is actualy way more stable than 3.4, while the oposite is true for the C/C++ compilers. However, in my opinion the same is true for gnat as well, if in a lesser degre, and I for one would actually prefer a separeate gccgnat package. It would have to be maintained better than at the moment though (with the latest version of gccgnat portage being 3.4.3, while gcc has 4.1.0beta in portage) > So, I can see two possible layouts of this split: > > 1. We produce 3 separate packages now, gnatgcc is joined with gcc at a later > point. We keep older version of gnatgcc for a while (probably couple of years, > until gcc-4 is considered stable everywhere, possibly until gcc-3 is removed > from the tree, which is much longer). Sounds resonable. > 2. We do not rush with 3 packages now, in fact we don't bother wuth gnatpro at > all, pointing interested users at what becomes of gnatgpl - the ebuilds should > be almost identical anyway. Instead we sort things out, do SLOTting, et all in > existing gnat. Meanwhile gcc-4.1 comes around and we enable ada support in it. > At this point we issue gnat-5, which is now gnatgpl and possibly remove older > gnatgpl versions. Thus in the end we have gcc with ada support and gnat for > gnatgpl version.. Sorry, you just confused me with this one. Do you intend to initially have GNAT Pro 3.xx, GNAT GPL 2005, gccgnat 3.4.x and gccgnat 4.0.x in one package (dev-lang/gnat)? And when you have added gnat-support to the gcc 4.1 package you add gnatpro 5.xx to excisting gnat package? So, at the end one package will include (in accending order): GCC GNAT 3.4.x GNAT Pro 3.14/3.15 GCC GNAT 4.0.x GNAT Pro 5.xx GNAT GPL 2005 You do see what a mess this will give anyone trying to upgrade within one product without installing another? That would require everyone to extensively use /etc/portage/package.mask, which I don't think is a very good idea. I think this would just be confusing to everyone! > SLOTting is necessary in both cases, however 2nd one is quite messy - we need > to be more carefull with SLOTs, gives less flexibility, the only (disputable) > upside is that is it kind of "easier" on user, having only one gnat in the > tree. However confusion stemming from ada in gcc vs provided gnat will be > enough.. Peronaly I think there will be more confusion having different products in the same package than having competing products in different packages, perhaps with a virtual/gnat for third party packages to depend on. That is quite common already, for exaple we have blackdown-jre, sun-jre, ibm-jre, compac-jre and sablevm all providing java runtimes, and virtual-jre for third party packages to depend on. Or do you sugest we merge all java runties into a single package as well? > So, in short I think the cleanest layout is to have tree SLOTted packages: > > gnatgpl and gnatpro, SLOTs 3.15, 5.x Note: There is currently only one version of gnatgpl: 2005, which is gnatpro 5.xx based, and thus gcc 3.4.x based. The next version of gnatgpl (lett us call it GNAT GPL 2006, though it is posible no new version will come untill 2007+) will also be based on GNAT Pro 5.xx / GCC 3.4.x, so no slotting will be neded then either. GNAT GPL will not have to be sloted untill AdaCore has released a GCC 4.x based GNAT Pro 6.xx and makes a GNAT GPL version of that one, which I peronally don't think will hapen in the next decade or so (considering the time they took going from the gcc 2.x backend to the gcc 3.x backend) > gnatgcc, SLOtted against appropriate gcc version, joining up with gcc in > future.. I would recomend: <package-version> slot gnatpro-3.xx 3 gnatpro-5.xx 5 gnatgpl-2005 5 (as it is based on gnatpro 5.xx) gnatgpl-2006 5 (when it is released) gccgnat-3.4.x 3.4 gccgnat-4.0.x 4.0 gccgnat-4.1.x 4.1 (unless gccgnat is merged into gcc at this point) > However this will be for the long term Ada maintainer to deal with. Speaking > of which: we need people. Right now I am sidetracking from my Scientific > Gentoo duties and David Hold is bisy with ppc stuff and does not have good > internet connection. We need at least one more developer, who would assume > responsibility over Ada domain. > Jon: I see majority of your bugzilla submissions deal with NX, but you clearly > are interested in Ada, would you be willing to join up? The NX submissions is becouse I'm involved with freenx upstream, my ada interest is becouse it is required for courses in school and I like to do my laborations from home. No way I will take responsibility of doing the initial cleanup / package spliting, but I could help out with maintaining it in the future. > As for gnatpro, we clearly will need an access to the package, however I think > it may be possible to negotiate with Ada Core - we will need to explain them > the way distribution works under Gentoo. The ebuilds will have proper fetch > restrictions and will come with appropriate license, so customers will have to > go to them in any case, we basically just need a source and some "local" > licenses for testing.. We can look into it at a proper time, I guess after we > get gnatgpl and SLOTs working.. I agree. > > George Regards - Jonno
(In reply to comment #7) > Yes, there are two different sets of gnat developers: AdaCore and FSF (GCC). [skipped] > However, GCC people are continuing to improve ada in GCC 4.x, so > it won't end up "unmaintained" again as it was in GCC 3.0-3.2 (as noone ported > gnat from the 2.x backend to the 3.x backend). This is good to know. It is exactly because of that stall during gcc-3.0 days that I was somewhat skeptical about gcc-bundled Ada, but now it seems it has picked up pace.. > > We are thinking about enabling ada support in gcc starting probably with > > gcc-4.1, effectively removing the need for the separate gnat package. > Interesting. I do see some problems if you introduce a gnat use-flagg and > someone first enables it, and then wants to rebuild gcc with it enabled I guess you meant "disables" above? > though... Another interesting point is that last I checked the java herd was > thinking of doing the opposite with gcj, as people generaly don't want to > upgrade their core C/C++ compiler as often as their speicial-purpose compilers [skipped] > and I for one would actually prefer a > separeate gccgnat package. Well, I have seen the requests for enabling in-gcc ada, but you make a good point about upgrade frequency. Although gcc is SLOTted and one can use gcc-config to select an "active" version, so this alleviates the problem somewhat. However I think the best is to hold a discussion on a gentoo-dev mailing list or/and elsewhere, where we would expect ada users in Gentoo to "gather". Anyway, first we need to make it all working.. > > > So, I can see two possible layouts of this split: > > 1. We produce 3 separate packages now, gnatgcc is joined with gcc at a [skip] > Sounds resonable. Yea, that was the "main" entry :). > > 2. We do not rush with 3 packages now, in fact we don't bother wuth gnatpro Sorry about this one - I was thinking of alternatives, but I agree, that would be quite messy and impossible to maintain in the long run. > I would recomend: > <package-version> slot > gnatpro-3.xx 3 > gnatpro-5.xx 5 > gnatgpl-2005 5 (as it is based on gnatpro 5.xx) > gnatgpl-2006 5 (when it is released) > gccgnat-3.4.x 3.4 > gccgnat-4.0.x 4.0 > gccgnat-4.1.x 4.1 (unless gccgnat is merged into gcc at this point) Right now we have in the tree some 3.14/3.15 versions. These would become gnatpro I gather? Then we have numerous 3.4x versions, these are gnatgcc AFAICS. We will need to produce ebuilds for gnatgpl then.. On the naming: I see you prefer to call the gcc version gccgnat, however I would expect a name of gnatgcc, especially considering that the produced binary (one of the) is called just that, plus this is what I remember it was referenced as sometimes. So, how insistant are you on the gccgnat name? > > Jon: I see majority of your bugzilla submissions deal with NX, but you clearly > > are interested in Ada, would you be willing to join up? > The NX submissions is becouse I'm involved with freenx upstream, my ada > interest is becouse it is required for courses in school and I like to do my > laborations from home. No way I will take responsibility of doing the initial > cleanup / package spliting, but I could help out with maintaining it in the > future. Well, that would be quite nice - I mean the long term maintainership. The split/slotting will have to be done around now, and I am afraid it falls back on me again :), although any help in that process will definitely be appreciated (but of course all the final testing and commits will be mine).. I have looked at the gnat.eclass and I think majority of hard stuff will happen there. It should be modelled after the toolchain eclasses. One thing I am not so sure about is how to deal with the choice of compilers when we split them. One way is to install them under regular names (I mean the binaries here, like gnatgcc/gnatmake) and use some tool, gnat-config (like with gcc's gcc-config) or a module to eselect to chose the "active" compiler. That would be the apparent way to go if we were dealing with different versions of the same package. Another way is to name binaries reflecting the package they are coming from. This follows the split philosophy, but may be a bit confusing. Now instead of simply calling gnatmake you would have to call gnatmake_pro or gnatmake_gpl or gnatmake_gcc (and I think here it is much better to put package specificator at the end vs., for example, pro_gnatmake, because this will allow to use tab completion to look up the proper name). In reality we might need to go with a combination of the two, as we will have split *and* slotted packages. Now, that is becoming messy use-wise - three variants of tool name spellings with potentially three version-selector tools/modules.. We may make the renaming of the installed binaries optional, but that has a good potential of becoming a maintenance nightmare. It may be well worth then to simply put them at different places and use single tool to select the active variant (option 1). Libraries/sources will have to be kept separate anyway.. Meanwhile, if you are serious about long-term ada maintainership in Gentoo we could start an "application" process and I could mentor you. This takes time, expect 2-3 month realistically (2 is more or less normall, but I will be mentoring another to be dev to take care of prolog stuff and I will be "off" for almost a month in February), so there is a hope splitting/slotting may be done by then :). (BTW, your NX ebuilds should be making use of use_with or use_enable ;) http://dev.gentoo.org/~plasmaroo/devmanual/ebuild-writing/functions/src_compile/configure/ but otherwise they are looking clean, I haven't tested them though). George
(In reply to comment #8) > > > We are thinking about enabling ada support in gcc starting probably with > > > gcc-4.1, effectively removing the need for the separate gnat package. > > Interesting. I do see some problems if you introduce a gnat use-flagg and > > someone first enables it, and then wants to rebuild gcc with it enabled > I guess you meant "disables" above? Ofcourse, silly mistake. > > though... Another interesting point is that last I checked the java herd was > > thinking of doing the opposite with gcj, as people generaly don't want to > > upgrade their core C/C++ compiler as often as their speicial-purpose compilers > [skipped] > > and I for one would actually prefer a separeate gccgnat package. > Well, I have seen the requests for enabling in-gcc ada, but you make a good > point about upgrade frequency. Although gcc is SLOTted and one can use > gcc-config to select an "active" version, so this alleviates the problem > somewhat. However I think the best is to hold a discussion on a gentoo-dev > mailing list or/and elsewhere, where we would expect ada users in Gentoo to > "gather". Anyway, first we need to make it all working.. Imho the problem with gcc-config is that is swiches C/C++/Java/Ada compilers all at once. Otherwise I agree with you. > > I would recomend: > > <package-version> slot > > gnatpro-3.xx 3 > > gnatpro-5.xx 5 > > gnatgpl-2005 5 (as it is based on gnatpro 5.xx) > > gnatgpl-2006 5 (when it is released) > > gccgnat-3.4.x 3.4 > > gccgnat-4.0.x 4.0 > > gccgnat-4.1.x 4.1 (unless gccgnat is merged into gcc at this point) > > Right now we have in the tree some 3.14/3.15 versions. These would become > gnatpro I gather? > Then we have numerous 3.4x versions, these are gnatgcc AFAICS. > We will need to produce ebuilds for gnatgpl then.. Yes, that seems correct. We would also have to make gnatgcc 4.0.x ebuilds > On the naming: I see you prefer to call the gcc version gccgnat, however I > would expect a name of gnatgcc, especially considering that the produced > binary (one of the) is called just that, plus this is what I remember it was > referenced as sometimes. So, how insistant are you on the gccgnat name? Not at all. My reasoniong is GCC's GNAT as opposed to AdaCore's GNAT (Pro/GPL). Also, the binary gnatgcc is pressent both in GCC's GNAT and AdaCore's GNAT. I can go either way though. > > > Jon: I see majority of your bugzilla submissions deal with NX, but you > > > clearly are interested in Ada, would you be willing to join up? > > The NX submissions is becouse I'm involved with freenx upstream, my ada > > interest is becouse it is required for courses in school and I like to do my > > laborations from home. No way I will take responsibility of doing the > > initial cleanup / package spliting, but I could help out with maintaining it > > in the future. > Well, that would be quite nice - I mean the long term maintainership. The > split/slotting will have to be done around now, and I am afraid it falls back > on me again :), although any help in that process will definitely be > appreciated (but of course all the final testing and commits will be mine).. > I have looked at the gnat.eclass and I think majority of hard stuff will > happen there. It should be modelled after the toolchain eclasses. One thing I > am not so sure about is how to deal with the choice of compilers when we split > them. > > One way is to install them under regular names (I mean the binaries here, like > gnatgcc/gnatmake) and use some tool, gnat-config (like with gcc's gcc-config) > or a module to eselect to chose the "active" compiler. That would be the > apparent way to go if we were dealing with different versions of the same > package. I would approach it the same way as java-config. That is one tool to swich between between any installed implementation (eg, using java-config I can choose between sun-jdk-1.5, sun-jdk-1.4 and blackdown-jdk-1.4, and with gnat-config I would be able to choose between gnatpro-3.15, gnatgcc-3.4 and gnatgcc-4.0) > Meanwhile, if you are serious about long-term ada maintainership in Gentoo we > could start an "application" process and I could mentor you. This takes time, > expect 2-3 month realistically (2 is more or less normall, but I will be > mentoring another to be dev to take care of prolog stuff and I will be "off" > for almost a month in February), so there is a hope splitting/slotting may be > done by then :). I don't realy know. Let me think about it. > (BTW, your NX ebuilds should be making use of use_with or use_enable ;) > but otherwise they are looking clean, I haven't tested them though). (Blame Stuart for that one, all my NX ebuild started as version bumps of his ones) > George Regards - Jonno
So, here is the plan. We create three new packages: gnatpro, gnatgpl and gnatgcc. We keep present gnat intact, until this new stuff id sorted out. New packages get sensible versioning: gnatpro keeps 3.14, 3.15 and 5.xx, following whatever versions upstream sends our way. Although we should probably loose 3.14, 3.15 is supposed to be all the same and better anyway.. gnatgpl: well, is this one the same as gnatpro, just released later and under a different license? What are the differences except that? Jon: could you give me any pointers please? I even wonder now whether we need a separate packages for -pro and -gpl, if they are just under different licenses we can handle that inside the same ebuild (adding them as needed when gpl version gets released for example).. gnatgcc: follows respective gcc version, so 3.44 becomes 3.4.4 for example.. This would allow to simply set SLOT to a major number (as in major.minor[.micro]) for gnatpro/gpl and major.minor for gnatgcc.. Quite simple to process in eclass and follows toolchain logic. Installation: Binaries/libs are installed similarly to gcc, this is adapted from toolchain.eclass: LIBPATH=${PREFIX}/lib/${PN}/${CTARGET}/${SLOT} LIBEXECPATH=${PREFIX}/libexec/${PN}/${CTARGET}/${SLOT} INCLUDEPATH=${LIBPATH}/include -- this one will probably be replaced/supplemented with ADA BINPATH=${PREFIX}/${CTARGET}/${PN}-bin/${SLOT} DATAPATH=${PREFIX}/share/${PN}-data/${CTARGET}/${SLOT} Then the selection tool will set and manage symlinks appropriately. Although I have not decided yet on gnat-config vs gnat module for eselect.. So, this is a rough draft of what can be done. I'll try to have a go at eclass now, but I would like to get a better idea of how gpl vs pro will be managed and versioned upstream.. George
(In reply to comment #10) > So, here is the plan. > > We create three new packages: gnatpro, gnatgpl and gnatgcc. We keep present > gnat intact, until this new stuff id sorted out. Great. > gnatpro keeps 3.14, 3.15 and 5.xx, following whatever versions upstream sends > our way. Although we should probably loose 3.14, 3.15 is supposed to be all > the same and better anyway.. Yes, 3.14 should probably be droped. > gnatgpl: well, is this one the same as gnatpro, just released later and under > a different license? What are the differences except that? Jon: could you give > me any pointers please? I even wonder now whether we need a separate packages > for -pro and -gpl, if they are just under different licenses we can handle > that inside the same ebuild (adding them as needed when gpl version gets > released for example).. I don't know, but we probably need separate packages. The licence stuff is actually in every ads file, (the License pragma), and the version of the bundled GPS differ. My quess is that they are close, but not 100% the same, so we'll need different ebuilds for them. Yet again, I have not seen gnatpro 5.03, so I can't say for sure. > gnatgcc: follows respective gcc version, so 3.44 becomes 3.4.4 for example.. > > This would allow to simply set SLOT to a major number (as in > major.minor[.micro]) for gnatpro/gpl and major.minor for gnatgcc.. Quite > simple to process in eclass and follows toolchain logic. Yes, sounds great. > Installation: > Binaries/libs are installed similarly to gcc, this is adapted from > toolchain.eclass: > > LIBPATH=${PREFIX}/lib/${PN}/${CTARGET}/${SLOT} > LIBEXECPATH=${PREFIX}/libexec/${PN}/${CTARGET}/${SLOT} > INCLUDEPATH=${LIBPATH}/include > -- this one will probably be replaced/supplemented with ADA > BINPATH=${PREFIX}/${CTARGET}/${PN}-bin/${SLOT} > DATAPATH=${PREFIX}/share/${PN}-data/${CTARGET}/${SLOT} Sounds ok. > Then the selection tool will set and manage symlinks appropriately. Although I > have not decided yet on gnat-config vs gnat module for eselect.. That depends, will eselect be out of ~arch by march, when we hope to be? If so I'd go for eselect (as we soner or later need to go eselect), but I'd prefer if we didn't have to be held up by it. > So, this is a rough draft of what can be done. I'll try to have a go at eclass > now, but I would like to get a better idea of how gpl vs pro will be managed > and versioned upstream.. Sounds like a great plan. As we won't bother with gnatpro 5.xx to start with, I don't think that will be such an imediate problem either. > George - Jonno
>> Then the selection tool will set and manage symlinks appropriately. Although I >> have not decided yet on gnat-config vs gnat module for eselect.. >That depends, will eselect be out of ~arch by march, when we hope to be? If so Just checked with ciaranm (he is one of eselect developers), it is expected to go stable on a month scale, so lets go with eselect then.. George
Happy New Year to everybody! And I have a "gift" in fact, yes, that's an eclass for building gnat* compilers :). Its ugly, its incomplete, but it works, at least to some extent. Clearly this is just a first shot, much more work is necessary, but it appeared to be easier than I was expecting.. The eclass is called gnatbuild.eclass, as this one is for building the compiler, not ada packages. THe building logic for packages seems quite different (and much simpler), so for now it is a separate eclass. If I find anything sensible to share between the two I might join them, but so far it looks like that will only complicate things.. Another thing, toolchain.eclass, as it is now, should *not* be inherited by other eclasses. It is supposed to be used directly with gcc and related ebuilds and it has some messy stuff that can misbehave. This is from a recent irc chat. I was told to copy some fragments over instead, which I did and in fact simplified logic a lot in many places, as we do not (so far) need all the stuff that is there. toolchain-funcs, multilib and versionator can and should be used by eclasses. Ok, on to the beef.. George
Created an attachment (id=75917) [edit] gnatbuild.eclass - the eclass for building gnat* compilers Borrows a lot of logic from toolchain (but simplifies many functions a lot). Right now it is only good for gnatgcc, as this is the one I built first. It installs stuff into ${CTARGET}-${PN}-${SLOT} versioned locations, so the split/slotting is done and it produces relevant env.d ans eselect entries. No eselect module so far though. The eselect-compiler is a nasty beast of itself - they even produce some wrappers to call some programs, so its not simply bash. I don't think we need to be as complex, but I need to go through eselect-compiler logic and adapt or reimplement the relevant parts.. This is unlikelt to happen within this coming week, as I have to catch up with some other stuff though. The eclass has some rudimentary multilib and crosscompilation support. I am not sure I added all the necessary ingredients, as I did not check the function yet, but it seems to install 32bit libs on amd64 and to produce amd64-* and x86-* entries for env and eselect.. It take 2 use flags as of now: multilib - supposed to control whether to enable multilib. It is deprecated now, instead the choice is made based on the active profile user has. However I kept the flag in for now, but I may remove it later, if I see that it can be avoided.. nls - if set installs provided locales. The code should check for LINGUAS var as well, however there are only two locales - de and fr (besides C=en), so this is lowest priority for now. Enjoy! George
Created an attachment (id=75918) [edit] gnatgcc-3.4.4.ebuild - the ebuild to go with the above eclass (should go in dev-lang probably) This will install gnatgcc compiler. The split and going in fresh allowed to use the upstream version of 3.4.4, instead of 3.44 as in gnat now. The ebuild is pretty basic, basically a lot of stuff was cut off, as it is now in eclass. Also, using tc-arch instead of ARCH simplified logic at some places (eclass). The eclass provides pkg_setup, src_unpack src_compile and src_install functions. Of these src_unpack will probably be universally extended - to apply relevant patches and set other package/version specific stuff. Normally one wants to call gnatbuild_src_unpack first and then do all the local magic. Similarly, both src_compile and src_install are sectioned (see the gnatbuild.eclass and the eclass howto in handbook), so that their parts can be called as needed supplemented with local stuff in between.. Straight emerge gnatgcc will fail now, since that will be calling all the functions, finishing up with pkg_postinst, which calls eselect gnat set ... and the eselect module is not produced yet. However this happens already after everything was installed, so you will get compiler on your system. But without the eselect module you will have to set all the symlinks and source relevant env.d and eselect entries by hand, if you want to try it in action.. This seems to be it for now. I am not going to do much on this for a week or so, I hope I'll have time play with it more afterwards :). George
Created an attachment (id=76484) [edit] gnatbuild.eclass a new version Iteration 2. This time it is functional and comes with eselect tool. Testing is wellcome! This is an eclass, the rest of files to be posted next.. George
Created an attachment (id=76485) [edit] gnatgcc-3.4.5.ebuild Right now only amd64, should work for x86 as well, I just need to prepare a bootstrap (this time I used local Gentoo-made installation instead of old ubuntu binaries - should fix some PaX related problems according to Kevin (#64373, comment 27)).
Created an attachment (id=76486) [edit] eselect-gnat-0.5.ebuild - an ebuild to install gnat.eselect module Quite trivial in fact, posted for completeness.
Created an attachment (id=76488) [edit] gnat.eselect The gnat.eselect module. What happens is gnat* packages install "spec" files under /etc/eselect/gnat and then this module uses these specs to create a 55gnat-$CTARGET-$PN-$SLOT file under env.d. Then it is simply a matter of env-update && . /etc/profile and you are set to use new gnat.. Some "ideology". There are two ways to handle multiple gnat installs: 1. Following toolchain logic, do some real spec magic + produce some wrappers that would call actual compilers. This is quite involved, I did not even get through all of the eselect-compiler stuff and it seems to not be complete yet actually.. However this way seems to deal better with all the "special" profiles, like hardened and crosscompilation (support for the latter is incomplete though AFAICT even in toolchain). By "deal better" I mean here "is necessary" really :), however since for now I just ignored these "targets" I opted for a much simpler way to deal with multiple gants/SLOTs: 2. Set some env vars (via regular way of getting some file listing them in /etc/env.d) and off you go.. This seems to work quite well for now. However, on multilib systems you will get a "more advanced" spec file, with sections for your native arch and other variants. I get an amd64 and x86 sections here. The difference is CTARGET and some extra CFLAGs for a multilib variant. I am not really sure what to do with these, as just adding them bluntly to env is not a good idea (they will influence not only gnat, but all the gcc compilers). The easiest way is to simply let user set them locally, on per compilation/project basis. After all realistically usage of Ada in this reality is mostly "special purpose" anyway.. Then, there are libs, like gtkada and others.. Should they be SLOTted? Well, I do not see a clean way to do that, as it is the same source and the SLOT really belongs to gnat.. I think a better approach would be to install multiple versions for each lib - one per installed gnat. This will require some logic in gnat.eclass, but should be doable. Plus multilib support may be automated as well.. Of course, simply letting user to eselect certain gnat and then emerge libs as needed is an option too, it is just you will be kind of "stuck" with one version of libs, as getting another one will require changing gnat and rebuilding the lib. Reasonable if you want to use one gnat as a base and use some other SLOTs/compilers sometimes, but not really usable otherwise. The upside is of course this approach does not require much work on lib side :). So, it is going to be the "starting" one, first lets bring gnat* compilers in, then I'll tackle with lib automation.. Questions/comments? George
I'd love to test/debug/fix these, but unfortunately I get a "403 Forbidden" when I try to download your bootstrap compiler...
Created an attachment (id=76493) [edit] gnatgcc-3.4.5.ebuild, now with x86 Ok, I actually got around to producing x86 bootstrap today, so here is a new ebuild with x86 support. Few minor changes - KEYWORDS and SRC_URI plus little clean-up. Sorry about the fetching - it appears I did not upload the bootstraps yet, they are up now, you can retry.. George
Created an attachment (id=76780) [edit] gnatbuild.eclass - new "version", now with gnat-gpl! New version - adjusted to build and install gnat-gpl-2005, and also to work with repackaged (yet again :)) bootstraps. The best thing: no changes to eselect module are necessary! You can just emerge gnat-gpl then eselect gnat set CTARGET-gnat-gpl-3.4 and off you go! Should be ready for testing. I am thinking to add support for gnat-pro-3.15p and then commit everything (p-masked of course until test reports flow in). George
Created an attachment (id=76781) [edit] gnat-gpl-2005.ebuild The first version of gnat-gpl-2005. Few words on naming: that '-' in the name appeared because of the way upstream named the source, it also makes the name more readable, even though I am not sure about aestetics :). Anyway, this was the easiest thing to do, rather than polluting the ebuild with name mangling.. Correspondingly I am considering adding a defis in the other package names, making them gnat-pro and gnat-gcc. Any thoughts on this? SLOTs: I remember the suggestion to SLOT gnat-gpl at 5, however I went with GCCBRANCH, as for gnatgcc for technical end logical reasons. Technically 5 seems very arbitrary (there is no '5' anywhere to be found in versioning of the source), plus this is the gcc backend that is important for binary compatibility. Also, we split packages for exactly this purpose - to have more freedom SLOTting and otherwise handling them. Comments? But please first see the code and make specific suggestions before saying that you want this to change ;). Fetching: AdaCore wants to be fancy with the sources apparently - they want everybody to register before getting the source. They even do not provide a static download link.. Technically, since the source is GPL, we should be able to just put it up in our space and let the mirrors ick it up, however it is better to check with them. I'll have to take this up with them I guess soon. Especially considering that there were some technical (packaging issues). See the following attachments.. George
Created an attachment (id=76784) [edit] prj-attr-pm.ads - a missing source For some reason the provided source was missing these two files. The only mention of the problem I was hitting because of that was going back to ada in gcc commit in 2004. Took some time to figure this out and hunt the files down.. Why the AdaCore source would miss them 2 years later? Anyway, please find them attached, both should go in FILESDIR (files/ under the gnat-gpl dir). George
Created an attachment (id=76785) [edit] prj-attr-pm.adb - another missing one Should go in FILESDIR. There is also Make-lang.in.patch file referenced in ebuilds. This is the patch to fix -fPIC issue for shared libs. This is the same file provided with >=gnat-3.44-r2. You can simply copy it over and rename (I removed version and ARCH part from its name, as it appears to be non-specific). George
Created an attachment (id=77129) [edit] email exchange w AdaCore - letter1 I contacted today AdaCore wrt the way gnat-gpl source is distributed by them and they were nice to respond pretty much immediately. I am attaching the exchange (Robert Dewar's replies with the quotes of my message) so that we have a track of this exchange. Short conclusion - it seems easiest for us to repackage the source (aside the obligatory login problem there were two files missing) and mirror it ourselves. Now, the name gnat-gpl-2005 seems rather restrictive - 2005 is really a version number of a standard, not a particular source version. So I am thinking about adding a version, most likely -3.4.5.1, possibly a date instead (but thy are nightmare to handle when a numbered release comes around, plus 3.4.5.1 is essentially GCCVER.x, which simplifies SLOT logic). Any suggestions/comments? The name will have to be changed as well - either we loose 2005 or rename it gnatgpl2005-3.4.5.1 for example.. In truth I do not like either of these naming schemes - having 2005 in a name is ugly, but it is bad for a version either, but we have to come up with something.. George
Created an attachment (id=77130) [edit] email exchange w AdaCore - letter2
> Now, the name gnat-gpl-2005 seems rather restrictive - 2005 is really a version > number of a standard, not a particular source version. So I am thinking about > adding a version, most likely -3.4.5.1, possibly a date instead (but thy are > nightmare to handle when a numbered release comes around, plus 3.4.5.1 is > essentially GCCVER.x, which simplifies SLOT logic). Any suggestions/comments? GCCVER.x makes a lot of sense; it's clear what it means. > The name will have to be changed as well - either we loose 2005 or rename it > gnatgpl2005-3.4.5.1 for example.. I think perhaps dropping the 2005 is sensible. I assume the langauage standard is selectable by compiler flag, as it is for ada83, C89, C99 etc. In which case gnat-gpl-3.4.5.1 would do nicely. Also, I think it would be courteous to AdaCode if the ebuild were to suggest people register with AdaCore, perhaps as a postinstall einfo. It might also be useful to inform people that the gnatgpl compiler can only be used to write GPL software as it might not occur to them that the license is different from the GCC license.
Created an attachment (id=77288) [edit] reply from AdaCore re their intended versioning scheme Or rather lack thereof. Attaching for completeness, to close this thread. In short they do not have any particular plans yet. Thus I think the most sensible thing is to go with GCCVER.gnatrelese scheme, which becomes 3.4.5.1 for the first ebuild that will go in shortly. Aside the technical simplification and ease to see what gcc backend version is used it has another "merit" - it is trivial to jump to the 200x.y schematic, but quite difficult to go the opposite direction, because 200x is going to be > than any major gcc version number. So, if upstream makes up their mind and there is enough desire on our side we just follow.. I'll do some cleanups and commit (p-masked) eclass, eselect tool and ebuilds soon.. Although looks like I have to play with eclass a bit more - gpc is overdue for version bump and, being another gcc frontend, has a lot of common logic. I'll try to make gnatbuild.eclass generic enough so that it can be inherited by gpc and possibly others. Although I am not sure it will be worth it (there is quite a bit of specific stuff in src_install for example). One other note. I just got another email from AdaCore - they acknowledged that the source they have up is missing two files, they are going to add them in the next version (whenever that is going to happen). Nothing new on versioning.. Kevin: Thanks for raising good points in your last post. I'll make sure I address them in the pkg_postinst message. George
Ok, the eselect-gnat, the gnatbuild.eclass and gnat-gcc and gnat-gpl ebuilds are in portage! Testing, testing, testing please! The gnat ebuilds are p-masked, so you'll need to add them to your package.unmask. The eselect module is not masked, it is ~x86 and ~amd64. The gnat-pro, of which we have 3.15p in the tree, is problematic. It does not build - even the one we have now, so I cannot refer to it for fixing. I tried to make it work, but looks like more work is necessary. It is quite low on my priority list, so I did not try really hard, I would rather like to leave it as an excersize for a future ada herd maintainer - I am going to announce an opening, but probably after I return from a vacation (end of Feb, will leave in two weeks). Few thoughts on the progress: 1. active compiler selection. Now the eselect module simply creates an env.d file setting PATH and ADA_... vars, so that this gets picked up in a usual way. This seems to work and is the easiest way to track it. However there is a potential problem: LIBEXECPATH contains cc1 and collect2 files, which are parts of a gcc backend and which are necessary for gnat function (otherwise we have to hard-depend on a particular gcc version and do nasty things during installation). This is Ok in itself, since they are isolated in $PN specific dirs and we only have one instance of gnat active at any moment. This should be Ok gcc-wise, since gcc is called via a (pretty involved) wrapper so it should not conflict (theoretically, we will see for real when we'll try gcc-4.x) between gnat and gcc compilers. However it may be an issue with other gcc frontends (there is gpc in portage and gdc might be added) which employ similar way of control. It really may be worth looking into producing a wrapper for gnat similar to the one in eselect-compiler.. 2. Libraries.... Well, it is going to be messy I am afraid. I see two immediate ways of dealing with libs: a) Have basic gnat.eclass and let user deal with them, as the see fit. Meaning, one will have to keep track of what lib was compiled with what gnat locally and recompile as necessary upon another eselect gnat set xxx.. b) Have every lib build multiple versions of itself, one per installed gnat. Have them install in gnat-PN specific locations under /usr/lib/ada/libname. Have gnat.eclass provide support for this and extend eselect-gnat to activate proper versions of the installed libs upon gnat selection, complaining if some lib is missing a particular build.. 2b is probably a good way to handle the situation, although quite involved to handle (at list to start it up). I am not sure it can be completely automated, as compilers and libs are installed separately (they *are* separate packages), so occasional remerge of a lib may be necessary, but looks like it may be sane enough.. In any case, asis will have to be done this way even if we do not implement this for the other packages. However in this case (2a in general, only asis handled specially) it makes sense to install asis along with gnat from the same (gnat-xxx) ebuild; which I do not like either, so I guess 2b will have to be done sooner rather than later.. Please test the committed ebuilds. I would like to unmask them before I leave for 3 weeks (so that we can deprecate that mess that is now gnat "proper", of course after we deal with libs).. George
Created an attachment (id=77374) [edit] gnat-pro-3.15p.ebuild - an attempt at making it work Well, it does not obsolete all the files I marked, but they are obsolete by commits that I mentioned in previous posts and I cannot obsolete them without attaching something.. gnat-3.15p-rX that we have now in portage does not work. Looks like the environment that is created for a bootstrap is "leaky" and it only worked on the system where it was tested because it had some working gnat (most likely gcc-2.8.1 based) installed.. The attached ebuild closes the leaks and actually goes through a lot of the process, however, weirdly, does not make gnatgcc, even though pretty much everything else is built (but not all of it installed). I have played with this only so much, as this is lower priority for me than making the split work in a nice way (now this is wrapper and libs, as I described), plus I need to task a newcomer developer on something :). So, I'll leave this version at that. If anybody is interested, please, by all means do try to fix it. Try to use as much of the gnatbuild.eclass as possible. The major functions in eclass are split into sections, so you shouldn't need too many conditionals inside eclass.. George
I unmerged gnat-3.4.5 first to make sure I had no gnat on the system, but had a few problems when trying to build gnat-gcc: 1) gnatbuild_src_compile and gnatbuild_src_install don't die properly when one of the pieces fail - this is due to the use of subshells. Changing: [ -z "$1" ] && ( gnatbuild_src_compile all; exit ) to if [[ -z "$1" ]]; then gnatbuild_src_compile all return $? fi and [ -z "$1" ] && ( gnatbuild_src_install all; exit ) to if [[ -z "$1" ]]; then gnatbuild_src_install all return $? fi in the eclass fixes that. 2) also in the eclass, there's a missing '\' on the end of the line: emake -j1 -C gcc gnatlib_and_tools || in gnatbuild_src_compile. 3) x86 build failed at configure; something wrong with the bootstrap compiler and environment but it's a bit late for me to debug now; I'll have a go tomorrow: updating cache ./config.cache creating ./config.status creating Makefile fatal error, run-time library not installed correctly cannot locate file system.ads gnatmake: *** make failed. 4) Lastly; a comment more than a problem for me - if the name "gnatboot-3.4-i686.tar.bz2" means that the bootstrap compiler is built for an i686 host, would it be better to provide an i386-host boostrap compiler?.
Hi Kevin. > 1) gnatbuild_src_compile and gnatbuild_src_install don't die Indeed. Fixed. Thanks for suggestion. > 2) also in the eclass, there's a missing '\' Well, bash does not seem to care about '\' after || or &&, but it may be worth to keep a backslash there for style consistency.. > 3) x86 build failed at configure; something wrong with the bootstrap compiler Hm, I cannot reproduce this. I tried unsetting active gnat first ("eselect gnat unset", I had both gnat-gcc and gnat-gpl here, no regular gnat installed), then unmerging both gnats, so that I have no trace of gnatmake or gnatgcc anywhere. Build proceeds as expected. So, I'll have to wait for a more detailed report.. > 4) Yes, that would be good. I'll see about it at some point, this is one of the low priority things. One thing that I noticed: the files installed under /etc/eselect/gnat are noot getting removed, possibly because of CONFIG_PROTECT. I guess they will have to be dealt with from pkg_postrm.. I'll add that function to eclass then.. George
hi I've just found this thread and I have some notes. 1) I like gnat-3.15p version for its license and asis support. For now it's only version to build non-gpl application with asis library. Keep this version in portage for now if possible, please. 2) I think gnat-pro-3.15p is wrong name. There were two version of gnat 3.15: a pro version named gnat-3.15a and public version named gnat-3.15p. Now AdaCore replace public version with GPL one. May be keep it gnat-3.15p (or gnat-pub-3.15p) till you get real GnatPro-5.x? 3) Libraries. I think some libraries won't compile under all gnat compilers. Now there are asis only for 3.15 and gpl, but none for gnat-gcc. New gnat-project and Ada 2005 features will disable building some future libraries on 3.15p. And so on. So we can require the same set of libraries for all installed gnat compilers. It would be nice to place libs in compiler depended directory and let user install different sets of libs for different compilers, but i dont know how to do it with emerge. 4) An intresting link http://ada.krischik.com/index.php/Articles/CompileGNATGPL -- Max
(In reply to comment #34) > So we can require the same set of libraries for all installed Ops, I meant "we can't require"
(In reply to comment #34) > 1) I like gnat-3.15p version for its license and asis support. > For now it's only version to build non-gpl application with asis library. > Keep this version in portage for now if possible, please. Then please take a look at comment #31 and be my guest to fix it ;). I would like to keep it in portage too, for this very reason, but first we need to fix it (as the ones under dev-lang/gnat do not seem to work..). In addition to what I described in that comment: I trued using gnat-gcc-3.4.5 as a bootstrap with some success. I had to substitute system.ads (IIRC, anyway you will get the complaint about extra or missing fields pretty much right away, so you will know which one) from the 3.4.5 to make it do anything at all, but then IIRC it went through bootstrap but then I abandoned that approach, when I could not make it do gnatlib_and_tools, etc. and went with the repackaged bootstrap of gcc-2.8.1.. I am mentioning this only because it seems to me that while both are failing, they managed to produce different parts somewhat differently, and I think at least gnatgcc was built during bootstrap in this way.. On the licensing: What about the gnat-gcc version? Its .ads files seem to have this clause: -- As a special exception, if other files instantiate generics from this -- -- unit, or you link this unit with other files to produce an executable, -- -- this unit does not by itself cause the resulting executable to be -- -- covered by the GNU General Public License. This exception does not -- -- however invalidate any other reasons why the executable file might be -- -- covered by the GNU Public License. -- which makes it GMGPL rather than straight GPL, so you should be able to link against it? > 2) I think gnat-pro-3.15p is wrong name. There were two version of gnat 3.15: > a pro version named gnat-3.15a and public version named gnat-3.15p. > Now AdaCore replace public version with GPL one. > May be keep it gnat-3.15p (or gnat-pub-3.15p) till you get real GnatPro-5.x? Thank you for pointing this out. I did not follow gnat closely in those time, but now I seem to recall something along these lines.. Then, since it is a public version and goes under GMGPL as well may be we can put it under gnat-gcc or rename both to gnat-pub? Although it becomes less clear - at least with gnat-gcc you should immediately guess which one you are dealing with.. > 3) Libraries. > I think some libraries won't compile under all gnat compilers. > Now there are asis only for 3.15 and gpl, but none for gnat-gcc. Please see dev-ada/asis-3.44. Builds fine with gnat-gcc and I think gnat-gpl (first one I definitely tested and I think I did gnat-gpl too). > New gnat-project and Ada 2005 features will disable building some future > libraries on 3.15p. Then these libs will have to depend on a specific gnat (or a combination thereof) rather than virtual/gnat.. > It would be nice to place libs in compiler depended directory and let > user install different sets of libs for different compilers, but i dont > know how to do it with emerge. Please see the comment #30, point 2 and let me know, whether you prefer 2a or 2b :). In fact there is another possibility: Makeup artificial versions for the libs that we are going to split - by appending gnat's SLOT to their original version for example, and adjust their dependencies correspondingly. However this is going to be a hell to maintain - too much duplication which even gnat.eclass is not going to help much. Plus some of these libs interdepend to some extent.. > 4) An intresting link > http://ada.krischik.com/index.php/Articles/CompileGNATGPL Yea, I think I saw it in some searches, but thanks for adding it here (so that we keep track of everything related). George
A few thought on this problem: (In reply to comment #32) > 3) x86 build failed at configure; something wrong with the bootstrap compiler > and environment but it's a bit late for me to debug now; I'll have a go > tomorrow: [skip] > fatal error, run-time library not installed correctly > cannot locate file system.ads This is totally "wrong", as in "should not happen". This just says that ADA_INCLUDE_PATH in the bootstrap environment is either not set or set to improper location. So this is likely a mismatch between the bootstrap and an eclass. Kevin: are you sure you got all the files Ok? The bootstrap and ebuild should match as the digest should have been checked (unless you regenerated it locally, which you shouldn't have). However do you by chance still have gnatbuild.eclass lying in your PORTDIR_OVERLAY? If yes, then this is the most likely cause - portage picks up your (older) gnatbuild.eclass in the overlay, which does not match the new bootstrap (and is probably broken in other ways too). If this is the case, please remove the gnatbuild.eclass from your overlay and retry.. I already thought about this and now it seems all the more important: should we perhaps extend the digest protection to cover eclasses in some way? (but this is a whole another discussion and not on this bug, as the trivial implementations will either miss stuff or produce quite a bit of duplication I am afraid). George
Kevin: Sorry, I did not realize you were not on CC of this bug, added you now. This is not optional any more, since you reported problems ;). Anyway, please take a look at my previous comment (#37). In short: I suspect you still have an old (and now obsolete) gnatbuild.eclass in your PORTDIR_OVERLAY. George
'sokay; I added myself to the ada alias a while back :) My portage directory is a CVS checkout; cvs diff shows the only difference between v1.2 of gnatbuild.eclass and the one I have is my addition of the pax flag twiddling. gnat-gcc-3.4.5.ebuild is identical to v1.1, and I have no eclasses in my overlay and no gnat-gcc. I've tried various things, mostly with the ADA_INCLUDE_PATH/ADA_OBJECTS_PATH variables thinking perhaps they were not getting passed through, but I see no reason why it should fail as the processing seems to be the same as for gnat-3.45 (which works fine). ... time passes ... I've made some progress - I tried swapping out the bootstrap compiler for the one in gnat-3.45, and fiddled the gnatbuild.eclass to set the environment up as gnat-3.45.ebuild does, and that works fine. It looks like the bootstrap compiler isn't honouring ADA_INCLUDE_PATH; I'll investigate some more.
(In reply to comment #39) > I've made some progress - I tried swapping out the bootstrap compiler for the > one in gnat-3.45, and fiddled the gnatbuild.eclass to set the environment up as > gnat-3.45.ebuild does, and that works fine. It looks like the bootstrap > compiler isn't honouring ADA_INCLUDE_PATH; I'll investigate some more. Well, it definitely honors it here.. I just rechecked (I don't know, for the 5th time?) the bootstrap and that I do not have any gnat installed in my chroot and it still comes through quite nicely.. Can you please check: 1. That you have the right bootstrap (digest should catch this, but just in case)? Its usr/lib/ should *not* contain immediate library files, instead a chain of other dirs, so it should be like usr/lib/gnatgcc/i686-pc-linux-gnu/3.4/ and then the libs. The gnatgcc should be the only entry under usr/lib.. 2. What ADA_INCLUDE_PATH (and ADA_OBJECTS_PATH, but that should be similar) are set to? Just uncomment that einfo in gnatbuild_src_compile right after the vars are set.. So, you say: > My portage directory is a CVS checkout; cvs diff shows the only difference > between v1.2 of gnatbuild.eclass and the one I have is my addition of the pax > flag twiddling. Can this change modify bash or gcc behavior in a way that would mask vars? Oh, btw, please submit a diff, so that I could test it and, potentially, incorporate.. Also (well, you can see I am now thinking of completely bizarre things), did you by chance change this line in eclass (the same section, setting environment): GNATLIB="${GNATBOOT}/lib/gnatgcc/${CTARGET}/${SLOT}" to GNATLIB="${GNATBOOT}/lib/${PN}/${CTARGET}/${SLOT}" I don't know, because it looks so much like the old gnat-gcc name? That could cause this behavior.. George
(In reply to comment #40) > (In reply to comment #39) > I just rechecked (I don't know, for the 5th time?) the bootstrap and that I do > not have any gnat installed in my chroot and it still comes through quite > nicely.. I've tried it in my ~x86 vanilla chroot, and it fails the same way there. Sometimes it dies silently; stops dead after saying 'creating Makefile', nothing more on the screen, nothing in the logs. I'm building a non-hardened kernel to see if that makes a difference. > Can you please check: > > 1. That you have the right bootstrap (digest should catch this, but just in > case)? Its usr/lib/ should *not* contain immediate library files, instead a > chain of other dirs, so it should be like > usr/lib/gnatgcc/i686-pc-linux-gnu/3.4/ and then the libs. The gnatgcc should be > the only entry under usr/lib.. That's what I have: .../work/usr/lib/gnatgcc/i686-pc-linux-gnu/3.4/ containing crt*.o, libgcc*, libgcov.a rts-native & install-tools directories, softlinks adainclude and adalib to rts-native/adainclude and rts-native/adalib (both of which have lots of stuff, including system.ads) > 2. What ADA_INCLUDE_PATH (and ADA_OBJECTS_PATH, but that should be similar) are > set to? * CC=/data/g2/tmp/portage/gnat-gcc-3.4.5/work/usr/bin/gnatgcc, ADA_INCLUDE_PATH=/data/g2/tmp/portage/gnat-gcc-3.4.5/work/usr/lib/gnatgcc/i686-pc-linux-gnu/3.4/adainclude the adainclude directory is a softlink to rts-native/adainclude; seems fine. ADA_OBJECTS_PATH is /data/g2/tmp/portage/gnat-gcc-3.4.5/work/usr/lib/gnatgcc/i686-pc-linux-gnu/3.4/adalib - again, this seems fine. > > My portage directory is a CVS checkout; cvs diff shows the only difference > > between v1.2 of gnatbuild.eclass and the one I have is my addition of the pax > > flag twiddling. > Can this change modify bash or gcc behavior in a way that would mask vars? No; also I've tried without the pax twiddling (that only makes a difference later on, not during configure) and get the same results. > Oh, btw, please submit a diff, so that I could test it and, potentially, > incorporate.. I've put together an eclass for PaX flag twiddling to abstract the use of chpax, paxctl etc; I'll commit that when I've tested it some more and post the much simpler change to the ebuild on bug #119382. > [GNATLIB changed?] I haven't changed the GNATLIB definition (exept perhaps while trying the other bootstrap compiler, but I put it back afterwards - well, refetched the eclass to be sure). (removing myself from CC as I get two copies)
I tried "ACCEPT_KEYWORDS=~x86 emerge -f gnat-gpl". It fails 1) patching stops: patching file gcc/expr.h patching file gcc/config/rs6000/rs6000.md Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 2 out of 2 hunks ignored -- saving rejects to file gcc/config/rs6000/rs6000.md.r patching file Makefile.in 2) Then compilation fails: ... >>> Source unpacked. creating cache ./config.cache checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for a BSD compatible install... /bin/install -c ld: crtbegin.o: No such file: No such file or directory *** The command '/var/tmp/portage/gnat-gpl-3.4.5.1/work/usr/bin/gnatgcc -o conft *** You must set the environment variable CC to a working compiler. !!! ERROR: dev-lang/gnat-gpl-3.4.5.1 failed. !!! Function gnatbuild_src_compile, Line 374, Exitcode 1 !!! configure failed !!! If you need support, post the topmost build error, NOT this status message. I tried #/var/tmp/portage/gnat-gpl-3.4.5.1/work/usr/bin/gnatgcc -v Using built-in specs. Configured with: /var/tmp/portage/gnatgcc-3.4.5/work/gcc-3.4.5/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gnatgcc-bin/3.4 --includedir=/usr/lib/gnatgcc/i686-pc-linux-gnu/3.4/include --libdir=/usr/lib/gnatgcc/i686-pc-linux-gnu/3.4 --libexecdir=/usr/libexec/gnatgcc/i686-pc-linux-gnu/3.4 --datadir=/usr/share/gnatgcc-data/i686-pc-linux-gnu/3.4 --mandir=/usr/share/gnatgcc-data/i686-pc-linux-gnu/3.4/man --infodir=/usr/share/gnatgcc-data/i686-pc-linux-gnu/3.4/info --program-prefix=gnat --enable-languages=c,ada --enable-libada --with-gcc --enable-threads=posix --enable-shared --with-system-zlib --disable-nls --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions Thread model: posix gcc version 3.4.5 I dont have /usr/lib/gnatgcc/i686-pc-linux-gnu/3.4, olny /var/tmp/portage/gnat-gpl-3.4.5.1/work/usr/lib/gnatgcc/i686-pc-linux-gnu/3.4. May be this is the cause?
(In reply to comment #31) > gnat-3.15p-rX that we have now in portage does not work. Looks like the > environment that is created for a bootstrap is "leaky" and it only worked on > the system where it was tested because it had some working gnat (most likely > gcc-2.8.1 based) installed.. I've just re-emerged successful gnat-3.15p and gnat-3.15p-r5 without any problem. But they are masked :-/ I tried to digest gnat-pro-3.15p.ebuild, but there is no gnatboot-3.15-i686.tar.bz2 at http://dev.gentoo.org/~george/src/ Why not to use gnat-3.15p-i686-pc-redhat71-gnu-bin.tar.gz by AdaCore?
(In reply to comment #42) > I tried "ACCEPT_KEYWORDS=~x86 emerge -f gnat-gpl". It fails > 1) patching stops: Th
