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 attachment 75917 [details] 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 attachment 75918 [details] 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 attachment 76484 [details] 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 attachment 76485 [details] 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 attachment 76486 [details] eselect-gnat-0.5.ebuild - an ebuild to install gnat.eselect module Quite trivial in fact, posted for completeness.
Created attachment 76488 [details] 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 attachment 76493 [details] 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 attachment 76780 [details] 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 attachment 76781 [details] 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 attachment 76784 [details] 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 attachment 76785 [details] 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 attachment 77129 [details] 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 attachment 77130 [details] 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 attachment 77288 [details] 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 attachment 77374 [details] 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: This is expected, this is how it works for now (upstream issue essentially). I thought about applying the patch and putting up the patched source already, so that nobody sees rejects, but that means we mirror the gcc source as well, for not very good reason (btw, IIRC similar patching with a few rejects happens during gnat-3.15p build, seems "regular" issue with AdaCore patches). > 2) Then compilation fails: > ... > >>> Source unpacked. [skip] > 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. Ugh, more variations in toolchain and binutils I guess. Looks like at least binutils are in a lot of flux lately, so everybody has some linking problems :(. > > I tried > #/var/tmp/portage/gnat-gpl-3.4.5.1/work/usr/bin/gnatgcc -v [skipped] > I dont have /usr/lib/gnatgcc/i686-pc-linux-gnu/3.4, olny And you shouldn't, while it is not installed yet. > /var/tmp/portage/gnat-gpl-3.4.5.1/work/usr/lib/gnatgcc/i686-pc-linux-gnu/3.4. This one is right. It is an issue of properly isolating the build from your installed stuff, that is setting environment properly. There were a few vars, which were unnecessary in my case and which I cut out of the "final" version, but apparently they are needed on your system. So, 1. Can you please find in the gnatbuild.eclass the line: #einfo "CC=${CC}, ADA_INCLUDE_PATH=${ADA_INCLUDE_PATH}" uncomment it and may be add ADA_OBJECTS_PATH there (so that it reads einfo "CC=${CC}, ADA_INCLUDE_PATH=${ADA_INCLUDE_PATH} ADA_OBJECTS_PATH=${ADA_OBJECTS_PATH}") and then post what it returns please? 2. Please: 2a) change local => export in definition of ADA_OBJECTS_PATH and ADA_INCLUDE_PATH Kevin: could you please try that too? I sometimes had problems of vars not passing through when I had them as local (normally preferable if you can) or simply defined, but adding export "fixed" this.. 2b) add export LDFLAGS="-L${GNATLIB}" right near above definitions. Basically, please change that environment settings block in gnatbuild_src_compile so that it looks like this: ... export CC="${GNATBOOT}/bin/gnatgcc" export ADA_OBJECTS_PATH="${GNATLIB}/adalib" export ADA_INCLUDE_PATH="${GNATLIB}/adainclude" export LDFLAGS="-L${GNATLIB}" # if [ "2.8.1" == ${GCCVER} ]; then # export BINUTILS_ROOT="${GNATBOOT}" # fi einfo "CC=${CC}, ADA_INCLUDE_PATH=${ADA_INCLUDE_PATH}, LDFLAGS=${LDFLAGS}" while [ "$1" ]; do ... Hopefully this will do something to these linking problems. Maxim: if passing LDFLAGS is not sufficient, you can try setting LD_LIBRARY_PATH as well: export LD_LIBRARY_PATH="${GNATLIB}" please let me know if either of these fixed the linking. I'll adjust the eclass accordingly. Oh, please also check that you do not have gnatbuild.eclass duplicated in your PORTDIR_OVERLAY or somewhere else, so that some older version is not picked up by portage.. If you do local modifications to the eclass, you may keep them in your overlay, but then you have to be carefull to merge all important changes or to track which one is being invoked (the overlay one takes the precedence). George
(In reply to comment #43) > I've just re-emerged successful gnat-3.15p and gnat-3.15p-r5 without any > problem. But they are masked :-/ Hm, where do you see them masked? package.mask only has entries for the work in progress on gnat-* and =dev-lang/gnat-3.44, which I'll simply remove from the tree (3.44 before -r2 are broken anyway, but I'll keep -r1 for a bit longer and 3.45 is the one that is getting stabilized. It should already be stable on x86). Or do you mean that it is in ~arch, that is in "testing profile"? That I am afraid it will have to stay for a while longer, even if we intend to keep it, as first we need to make sure all the known issues are resolved.. But it is good to hear, that it worked for you! Could you please build a binary package (either with quickpkg, if you still have it installed, or via emerge =dev-lang/gnat-3.45-r2 --buildpkg[only]) and put it up somewhere, so that I could grab it and make a bootstrap out of it? > 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? That is essentially the same one with the doconfig and doinstall steps run by me once and the result packaged up. I am simply saving these steps, since there is no sense in repeating them over for everybody (it is a modification of the same package and it is better to mirror that one ourselves anyway, since there is no saying when Red Hat is going to pull that one off from their mirrors..). I can put that gnatboot-3.15-i686.tar.bz2 up in the same place, if you would like to test it, but I would really prefer to use Gentoo-generated binary as a bootstrap (see Kevin's commens above for some reasons). So, could you please build the tbz2 package? I will try to use it and will post adjusted ebuild to this bug and will upload the bootstrap then.. Oh, btw, if you wish to try some diagnostics in real-time, you are wellcome to ping me on irc.freenode.net (not sure that one was enabled already again, if you have problems with it try chat.freenode.net, same irc protocol of course) in #gentoo.. My nick there is georges (I lost my original one of george some time ago unfortunately). George
(In reply to comment #45) > Or do you mean that it is in ~arch, that is in "testing profile"? That I > am afraid it will have to stay for a while longer, even if we intend to keep > it, as first we need to make sure all the known issues are resolved.. Gah, screw that, it *is* in stable now (KEYWORDS="x86 ppc"), while it should probably be demoted, until we clearly resolve all the issues, but I am waiting on the 3.45 stabilization.. George
ok; some good news and some bad news - changing 'local' to 'export' causes the bootstrap gnatgcc to pay attention to ADA_INCLUDE_PATH and ADA_OBJECTS_PATH (I thought I'd tried that before, but obviously not). However then it trips up on the specs file which it tries to read from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/specs which contains flags only present on Gentoo-patched compilers with hardened specs as their default: updating cache ./config.cache creating ./config.status creating Makefile gnatgcc -c xtreeprs.adb gnat1: error: unrecognized command line option "-fstack-protector" gnat1: error: unrecognized command line option "-fstack-protector-all" gnatmake: "xtreeprs.adb" compilation error On normal systems, the problem does not occur as the host specs don't try to switch on the stack protector by default. The bootstrap is getting its specs file from the wrong place: # /data/g2/tmp/portage/gnat-gcc-3.4.5/work/usr/bin/gnatgcc -v Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/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 whereas the ubuntu bootstrap used in gnat-3.45 gives: # /data/g2/tmp/portage/gnat-3.45/work/usr/bin/gcc -v Reading specs from /data/g2/tmp/portage/gnat-3.45/work/usr/bin/../lib/gcc/i486-linux-gnu/3.4.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,f77,pascal,objc,ada --prefix=/usr --libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug i486-linux-gnu Thread model: posix gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8) The bootstrap compiler should get its specs from ${GNATLIB}/specs, but I haven't found an easy way to do that. I tried adding "-specs=${GNATLIB}/specs" to CFLAGS, to the CC definition - no luck.
Thanks for testing! (In reply to comment #47) > ok; some good news and some bad news - changing 'local' to 'export' causes the > bootstrap gnatgcc to pay attention to ADA_INCLUDE_PATH and ADA_OBJECTS_PATH Good :). > However then it trips up on the specs file which it tries to read from > /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/specs which contains flags only present on > Gentoo-patched compilers with hardened specs as their default: [skip] > The bootstrap compiler should get its specs from ${GNATLIB}/specs, but I > haven't found an easy way to do that. I tried adding "-specs=${GNATLIB}/specs" > to CFLAGS, to the CC definition - no luck. Yea, I was afraid of that, but I could not find an easy way to deal with that either. The problem, from what I see, is that this -specs flag has to be passed specifically to gnatgcc, so it won't be picked up from CFLAGS. We can try to put some weird combination of -cflags -specs=, but I couldn't easily do that just now.. However I just produced some wrapper hack, and it seems to cause gnatgcc to read the right specs file (it reads the original one too, but then, it reads the specified one right after). The build comes through here, but this is not a good test, considering it worked before. Could you please fetch the new bootstrap? Its at the same place, file is now called gnatboot-3.4-i686-r1.tar.bz2 so, the link is http://dev.gentoo.org/~george/src/gnatboot-3.4-i686-r1.tar.bz2 Maxim: can you please try this too to see if this fixes it for you? George
Um, to avoid unnecessarily fetching 11MB, here is the detailed description of a wrapper. In GNATBOOT dir (that is $WORKDIR/usr/) in bin/: 1. mv gnatgcc gnatgcc_2wrap 2. create gnatgcc with this content (and make it executable of course): #! /bin/bash # wrapper to cause gnatgcc read appropriate specs BINDIR=$(dirname $0) ${BINDIR}/gnatgcc_2wrap -specs="${BINDIR}/../lib/gnatgcc/i686-pc-linux-gnu/3.4/specs" $@ However I wanted to do another post on licensing issues. Here is a reply by AdaCore person to some Debian discussion few month ago on which gnat they are going to support: http://coding.derkeiler.com/Archive/Ada/comp.lang.ada/2005-09/msg00655.html From it I grep that 1. gnat-gpl is pure GPL, which is fine for most of what we care about 2. gnat-gcc is still GMGPL, so fine for commercial stuff as well, as before (1. and 2. was my understanding anyway, just confirming this) 3. The change by AdaCore to pure gpl really just means restrictions on binary and support for the "hot new stuff", as gnat-gcc provides full Ada95 anyway and Ada2005 will get there in a due course, just not as soon.. So looks like,as far as Gentoo is concerned, this change does not mean much for us. The only question is what should we do with gnat-3.15p? Merge it with some other gnat-xxx package (as Maxim has pointed out, it is not a -pro version, but rather a -pub), create gnat-pub specifically for it, with the understanding that it will never be upgraded or keep it as is (just fixing) under dev-lang/gnat? I suspect people will be requesting to hold its removal for quite a while, as it is the only fully validated public compiler. However do many people actually care much about validation? As for the inability to build non-gpl stuff with gnat-gpl, Maxim: my understanding from all the above is that gnat-gcc is completely appropriate for that.. George
To clarify my previous post (after reading the whole thread): Ludovic Brenta is a Debian Ada maintainer, not an AdaCore person. However the rest of the points still holds. In particular: you can use gnat-gcc for everything that you used gant-3.15p for, it has GMGPL clause just like the 3.15 does.. Sorry about the confusion, I don't know all the people involved yet, as you can see :) George
Good news :) With the -r1 bootstrap, the change of 'local' to 'export' on ADA_INCLUDE_PATH and ADA_OBJECTS_PATH, and the pax marking fix (I've just posted to #119386, attachment id 77819), it built fine.
Excellent! New version of gnatbuild is in cvs. Now all vars are exported to force environment, plus it resolves that issue of gnat specs (for eselect) left behind. However I moved these specs from /etc/eselect/gnat into /usr/share/gnat/eselect to avoid them being not removed because of CONFIG_PROTECT. I also issued a new version of eselect-gnat to follow this change. Please don't forget to upgrade eselect-gnat when you build gnat-xxx again! I tried first to force removal of these specs in pkg_prerm (not postrm, like in libtool, because eselect-gnat can be unmerged together with gnat and I need it for this step - to run unset and get proper locations..), however these functions (pkg_pre/postrm) are called upon any unmerge, including updates, so that causes broken gnat installation if done this way.. As far as I ma concerned, gnat-gcc and gnat-gpl seem to be ready for unmasking (along with a corresponding eclass). I'll give it a few days and then, if nothing crops up, will remove p-mask entry (so that they get some more testing while I am away). Maxim: Could you please post your emerge info? I noticed that the gnat-3.15p that you sent me was built on a system with 2.4.1 kernel (why not the latest of the 2.4 series then?). I don't think the kernel version it that essential, but I suspect you might just as well have a really old version of binutils installed, or some such. This might also be the reason why you were able to build gnat-3.15p however :), which still means that it (gnat-3.15p) won't work for anybody else.. Can you update your tools and see if that solves the gnat-gcc/gpl build for you? George
(In reply to comment #52) > Excellent! > New version of gnatbuild is in cvs. Now all vars are exported to force > environment, plus it resolves that issue of gnat specs (for eselect) left > behind. However I moved these specs from /etc/eselect/gnat into > /usr/share/gnat/eselect to avoid them being not removed because of > CONFIG_PROTECT. I also issued a new version of eselect-gnat to follow this > change. Please don't forget to upgrade eselect-gnat when you build gnat-xxx > again! > > I tried first to force removal of these specs in pkg_prerm (not postrm, like in > libtool, because eselect-gnat can be unmerged together with gnat and I need it > for this step - to run unset and get proper locations..), however these > functions (pkg_pre/postrm) are called upon any unmerge, including updates, so > that causes broken gnat installation if done this way.. > > As far as I ma concerned, gnat-gcc and gnat-gpl seem to be ready for unmasking > (along with a corresponding eclass). I'll give it a few days and then, if > nothing crops up, will remove p-mask entry (so that they get some more testing > while I am away). > > Maxim: > Could you please post your emerge info? > I noticed that the gnat-3.15p that you sent me was built on a system with 2.4.1 Strange. How do you see that? I left 2.4 long time ago. I rebuilt system to gcc-3.4.4, but still have gcc-3.3.6 installed. Heh. > Can you update your tools and see if that solves the gnat-gcc/gpl build for > you? emerge -upD world contains nothing related with building tools. I'll try synch & emerge gnat this evening again. Portage 2.0.53 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14.2 i686) ================================================================= System uname: 2.6.14.2 i686 AMD Athlon(tm) Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-mcpu=i386 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=i386 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.linux.kiev.ua/pub/Linux/Gentoo/" LINGUAS="ru" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://gentoo.linux.kiev.ua/gentoo-portage" USE="x86 3dnow X acl alsa apm audiofile avi berkdb bitmap-fonts bzip2 cdr crypt curl emboss encode esd exif expat firebird fortran gd gdbm gif glut gpm gstreamer gtk gtk2 imlib ipv6 java jpeg junit lcms libg++ libwww mad makecheck mikmod mmx mng mozilla mp3 mpeg ncurses nls nptl ogg oggvorbis openal opengl oracle oss pam perl png python qemu-fast qt quicktime readline samba sdl slang softmmu spell ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis xml2 xmms xv zlib linguas_ru userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS
New eclass, bootstraps (wrapping gnatgcc) and ebuilds (-r1 for gnat-gcc and gnat-gpl to force upgrade) are in cvs. Should fix known issues. Maxim: I hope it fixes yours too, since looks like it might be related to specs in your case.. The new eclass produces a wrapper similar to the one I included in bootstraps, so now the installed gnatgcc should pick up a proper specs file too. Please test and report any breakage. Dont' forget to upgrade eselect-gnat if you didn't yet (0.6 is the matching version atm)! George
(In reply to comment #54) > New eclass, bootstraps (wrapping gnatgcc) and ebuilds (-r1 for gnat-gcc and > gnat-gpl to force upgrade) are in cvs. Should fix known issues. Maxim: I hope > it fixes yours too, since looks like it might be related to specs in your > case.. > [skipped] > > Dont' forget to upgrade eselect-gnat if you didn't yet (0.6 is the matching > version atm)! > > George > Hi ! Thanks for your work, it's really good to put ADA'05 in portage. I have succesfully emerged gnat-gcc, gnat-gpl and eselect-gnat. I read this thread because I tried to emerge gtkada and gps-bin and I was having trouble (errors during compilationof gtkada). I'm really sorry (and I feeling like a real lamer) but I don't know how to use the new gnat-gcc and gnat-gpl. I have unmerged gnat-3.45 and now, how can I compile some ada code ? Again I'm really sorry for this noob question.
(In reply to comment #55) > Hi ! Thanks for your work, it's really good to put ADA'05 in portage. I have > succesfully emerged gnat-gcc, gnat-gpl and eselect-gnat. Thanks for a report! > because I tried to emerge gtkada and gps-bin and I was having trouble (errors > during compilationof gtkada). Well, they are "coming", some of the libs were working, but some may need tuning, and I will be putting them on a "new rails" soon. Please submit bug reports as usual (one package per bug please) for the stuff that does not compile. > I'm really sorry (and I feeling like a real lamer) but I don't know how to use > the new gnat-gcc and gnat-gpl. I have unmerged gnat-3.45 and now, how can I > compile some ada code ? Um, like you usually do? gnatmake some_ada_prog.adb ... Please take a closer look at eselect. There are man pages, plus simply running "eselect gnat" will show you options. For example eselect gnat list - will list installed gnat copilers and "eselect gnat set ..." will set the selected one. However this is run automatically after emerge, so your eselect gnat show should show an active profile. However you may want to run env-update (as root) after emerge and source /etc/profile in the shell in which you are going to use gnat. This has to be done if you want to use gnat right after emerge, or it is done automatically during the next boot.. George
(In reply to comment #54) > New eclass, bootstraps (wrapping gnatgcc) and ebuilds (-r1 for gnat-gcc and > gnat-gpl to force upgrade) are in cvs. Should fix known issues. Maxim: I hope > it fixes yours too, since looks like it might be related to specs in your > case.. > It doesnt' help. I think it's because I don't have gcc-3.4.5 installed. Bootstrap gcc is not capable to compile .c files. I tried ln -s /usr/lib/gcc/i686-pc-linux-gnu/3.4.4 /usr/lib/gcc/i686-pc-linux-gnu/3.4.5 It helps a little, compilation goes futher, but then breaks /var/tmp/portage/gnat-gpl-3.4.5.1-r1/work/usr/bin/gnatgcc -c -mcpu=i386 -O2 -pipe -DHAVE_CONFIG_H -I. -I/var/tmp/portage/gnat-gpl-3.4.5.1-r1/work/gcc-3.4.5/intl /var/tmp/portage/gnat-gpl-3.4.5.1-r1/work/gcc-3.4.5/intl/bindtextdom.c @OUTPUT_OPTION@ gnatgcc_2wrap: @OUTPUT_OPTION@: No such file or directory and /var/tmp/portage/gnat-gpl-3.4.5.1-r1/work/gcc-3.4.5/intl/bindtextdom.c:23:20: stddef.h: No such file or directory
(In reply to comment #57) > It doesnt' help. I think it's because I don't have gcc-3.4.5 installed. Hm, interesting. I unmerged gcc-3.4.5 in my 32bit chroot (did not want to risk my main system :)) and now I am hitting this too. Which means that the environment, created in src_compile of eclass is still leaky. Which is pretty major (majority of users are on gcc-3.4.5 already and will not hit this, but that will become a problem when everybody migrates to 4.x..), which means gnat cannot be unmasked just yet.. Unfortunately I do not have any time left for fiddling with this before I leave in a few days, so I'll be able to do anything only at the end of February. Besides, I am not sure where to look at this point.. Kevin: I guess I'll hand it over to you for these few weeks, meaning that you are wellcome to commit fixes if you feel like it ;). Toolchain people: any suggestions on what else should be passed to gcc to make it look for objects, such as crtbegin/end.o and other stuff in a proper directory? LDFLAGS are passed (although they seem to be ignored), -L${D}${LIBDIR} gets through to ld (accordingly to the output), but that does not help.. I guess I will have to look more closely at that wrapper produced by eselect-compiler, but, as I said, I will only be able to do this in about a month.. > Bootstrap gcc is not capable to compile .c files. From what I can see this is not that - it can actually compile, the problems start at a later stage, when collect2 is called and it tries to call ld.. George
I'll try to have a look. I noticed that the ubuntu bootstrap had relative paths builtin (relative to the location of the compiler driver) which meant they all work when you move the compiler to a different directory. Our compilers, and also the new bootstrap compiler, have absolute paths which are what is causing trouble. I wanted to look at how Debian build it - but their download server was offline or broken when I looked a day or so ago. If we can get the bootstrap compiler to build with relative paths, that would be ideal as it would simplify the build process (we wouldn't need to set ADA_INCLUDE_PATH, no need to fiddle the specs etc for example).
I managed to install gnat-gpl after emerging gcc-3.4.5. I think bootstrap compiler is wrong configured: /gnatgcc -v Configured with: ... --bindir=/usr/i686-pc-linux-gnu/gnatgcc-bin/3.4 ... but it's installed in usr/bin/. It searches for crtbegin.o relative this /usr/i686-pc-linux-gnu/gnatgcc-bin/3.4: gnatgcc -print-search-dirs libraries: /var/tmp/portage/gnat-gpl-3.4.5.1-r1/work/usr/bin /../../../ lib/gnatgcc/i686-pc-linux-gnu/3.4/gcc/i686-pc-linux-gnu/3.4.5/ So if it would be in .../work/usr/i686-pc-linux-gnu/gnatgcc-bin/3.4 as pointed by --binddir then it found crdbegin.o and others stuff. I propose to configure bootstrap with -bindir=/usr/bin and pack i686-pc-linux-gnu/3.4.5/include/ in tar.bz2 The other way is to compile .c with system gcc and .ad[sb] with bootstrap gnat compiler.
(In reply to comment #56) > (In reply to comment #55) > [Skipped] > > I'm really sorry (and I feeling like a real lamer) but I don't know how to use > > the new gnat-gcc and gnat-gpl. I have unmerged gnat-3.45 and now, how can I > > compile some ada code ? > Um, like you usually do? gnatmake some_ada_prog.adb ... > > Please take a closer look at eselect. There are man pages, plus simply running > "eselect gnat" will show you options. For example eselect gnat list - will list > installed gnat copilers and "eselect gnat set ..." will set the selected one. > However this is run automatically after emerge, so your eselect gnat show > should show an active profile. > However you may want to run env-update (as root) after emerge and source > /etc/profile in the shell in which you are going to use gnat. This has to be > done if you want to use gnat right after emerge, or it is done automatically > during the next boot.. > Okay, eselect doesn't seem to work fine for me (I tried also env-update && source /etc/profile). The manpath and infopath are updated but eselect doesn't change the binpath (and I suspect the libexecpath too). I add the gnat-gpl binpath manually and when I compile some ada code, I got this : $gnatmake test.adb gnatgcc -c test.adb gnatgcc_2wrap: installation problem, cannot exec `gnat1': Aucun fichier ou r
(In reply to comment #56) > (In reply to comment #55) > [Skipped] > > I'm really sorry (and I feeling like a real lamer) but I don't know how to use > > the new gnat-gcc and gnat-gpl. I have unmerged gnat-3.45 and now, how can I > > compile some ada code ? > Um, like you usually do? gnatmake some_ada_prog.adb ... > > Please take a closer look at eselect. There are man pages, plus simply running > "eselect gnat" will show you options. For example eselect gnat list - will list > installed gnat copilers and "eselect gnat set ..." will set the selected one. > However this is run automatically after emerge, so your eselect gnat show > should show an active profile. > However you may want to run env-update (as root) after emerge and source > /etc/profile in the shell in which you are going to use gnat. This has to be > done if you want to use gnat right after emerge, or it is done automatically > during the next boot.. > Okay, eselect doesn't seem to work fine for me (I tried also env-update && source /etc/profile). The manpath and infopath are updated but eselect doesn't change the binpath (and I suspect the libexecpath too). I add the gnat-gpl binpath manually and when I compile some ada code, I got this : $gnatmake test.adb gnatgcc -c test.adb gnatgcc_2wrap: installation problem, cannot exec `gnat1': Aucun fichier ou répertoire de ce type gnatmake: "test.adb" compilation error I have gnat1 : it is in the libexecpath (/usr/libexec/gnat-gpl/i686-pc-linux-gnu/3.4). Maybe eselect doesn't change the libexecpath too... PS : I unmerged then re-emerged gnat-gcc, gnat-gpl and eselect-gnat without any problem.
(In reply to comment #59) > If we can get the bootstrap compiler to build with relative paths, that would > be ideal as it would simplify the build process (we wouldn't need to set > ADA_INCLUDE_PATH, no need to fiddle the specs etc for example). It would, but how do you make it use relative paths. configure just complains on me: Configuring in intl creating cache ./config.cache checking for non-GNU ld... x86_64-pc-linux-gnu-ld checking if the linker (x86_64-pc-linux-gnu-ld) is GNU ld... yes checking how to run the C preprocessor... configure: error: expected an absolute directory name for --prefix: .. make: *** [configure-libiberty] Error 1 make: *** Waiting for unfinished jobs.... /var/tmp/portage/gnat-gcc-3.4.5-r1/work/usr/bin/gnatgcc -E and I cannot find anything relevant in google :(. Any hints are wellcome.. BTW, it looks like the problems we are now left with are on the linker side already, so it is even more about (system's) ld magic I am afraid, rather than bootstrap compiler.. George
(In reply to comment #62) > (In reply to comment #59) > > If we can get the bootstrap compiler to build with relative paths, that would > > be ideal as it would simplify the build process (we wouldn't need to set > > ADA_INCLUDE_PATH, no need to fiddle the specs etc for example). > > It would, but how do you make it use relative paths. Sorry, no idea - I'd hoped to be able to work out how ubuntu build theirs, but can't find the relevant scripts or whatever.
(In reply to comment #63) > > It would, but how do you make it use relative paths. > > Sorry, no idea - I'd hoped to be able to work out how ubuntu build theirs, but > can't find the relevant scripts or whatever. Ok, I kind of did it. I, well, its not the way to do such things, but out of curiosity I tried :), so, I basically just took bvi ("binary vi", its in portage btw) and edited all the strings in "major" files that seemed relevant (like /usr/lib/...) to point to relative locations.. Its a total hack but it somewhat works. At least it does not complain about not finding crtbegin/end.o and such stuff, and otherwise seems contained. The drawback is that I apparently stripped too much off the bootstrap compiler originally and now it complains about not finding some .h files.. I readded some of these but few are still missing: make[1]: Entering directory `/var/tmp/portage/gnat-gcc-3.4.5-r2/work/build/libiberty' if [ x"-fpic" != x ] && [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir if [ x"-fpic" != x ]; then \ /var/tmp/portage/gnat-gcc-3.4.5-r2/work/usr/bin/gnatgcc -c -DHAVE_CONFIG_H -O2 -march=athlon-xp -pipe -ftracer -fomit-frame-pointer -I. -I/var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/../include -W -Wall -Wtraditional -pedantic -fpic /var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/regex.c -o pic/regex.o; \ else true; fi In file included from /var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/regex.c:187: /var/tmp/portage/gnat-gcc-3.4.5-r2/work/usr/bin/../include/limits.h:11:23: syslimits.h: No such file or directory etc.. Anyway, the new bootstrap is up, in case anybody wants to play with it. Its -r2 and it is located at: http://dev.gentoo.org/~george/src/gnatboot-3.4-i686-r2.tar.bz2 In addition to modified binaries it has usr/include added from existing gnat-gcc and gnatgcc wrapper "extended" to pass -I flag.. Will try to look into that again soon.. Maxim: thanks for a suggestion. This is another thing to try, although I am not sure which will be simpler. The thing is, gcc seems to ignore --bindir setting and insists on installing files into weirdly modified location, so moving stuff around is still necessary (toolchain.eclass moves them too btw ;)), as well as making sure it looks for the libs in a proper place.. George
Ok, made some progress with the "normal" bootstrap (i.e. not handpatched with path substitutions :)). Passing these additional vars seems to close the loopholes in the environment: # additional vars from gnuada export LD_RUN_PATH="${LIBPATH}" export LIBRARY_PATH="${GNATLIB}" export LD_LIBRARY_PATH="${GNATLIB}" Now it picks up all the right compilers and linker sees the objects. Adding an include dir that was previously stripped (that contained stddef.h and similar stuff) and adding -I... to the wrapper resolves the header issue for the C files. However now I am hitting this during bootstrap (only the relevant lines from the tail): checking for sys/time.h... no if [ x"-fpic" != x ]; then \ /var/tmp/portage/gnat-gcc-3.4.5-r2/work/usr/bin/gnatgcc -c -DHAVE_CONFIG_H -O2 -march=athlon-xp -pipe -ftracer -fomit-frame-pointer -I. -I/var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/../include -W -Wall -Wtraditional -pedantic -fpic /var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/cplus-dem.c -o pic/cplus-dem.o; \ else true; fi checking for sys/mman.h... /var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/cplus-dem.c:55: error: conflicting types for 'malloc' /var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/cplus-dem.c:55: error: conflicting types for 'malloc' /var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/cplus-dem.c: In function `code_for_qualifier': /var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/cplus-dem.c:630: warning: implicit declaration of function `abort' /var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/cplus-dem.c: In function `squangle_mop_up': /var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/cplus-dem.c:1154: warning: implicit declaration of function `free' /var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/cplus-dem.c: In function `demangle_qualified': /var/tmp/portage/gnat-gcc-3.4.5-r2/work/gcc-3.4.5/libiberty/cplus-dem.c:3310: warning: implicit declaration of function `atoi' no make[1]: *** [cplus-dem.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/gnat-gcc-3.4.5-r2/work/build/libiberty' make: *** [all-libiberty] Error 2 make: *** Waiting for unfinished jobs.... which may be a conflict with the new glibc version :( (malloc in particular). Or so it seems, these two lines slightly above are suspicious: checking for limits.h... no checking for stddef.h... no It might be I am not setting all the vars yet. However if this is a glibc issue I am afraid I'll have to mandate a gcc dependency - namely add a matching major gcc version to RDEPEND and a check to pkg_setup to make sure it is activated for the gnat build duration.. While not ideal this may be a reasonable workaround.. George
Some more time playing with the issue and few more vars thrown in to close the environment, and still I am getting complaints about malloc incompatibility. On a bright side. I am afraid I will have to add a DEPEND on a matching branch of gcc-3.4 to gnat ebuilds to resolve this issue. On the bright side, gnat-gcc-4.1.0 does not seem to insist on having gcc-4.1 installed, so that DEPEND may be actually made >=gcc-4.1 :). Looks like this should resolve the build issue on the systems where it is at present failing. Are there any objections to such course of action? This is not the best resolution of course, but the easiest one and, in fact, the only seemingly working one atm.. If I don't hear objections I'll do this change to the ebuilds in the tree and consider unmasking them soon after.. The gnat-gcc-4.1.0. It seems to go through most of bootstrap, required just few minor tweaks to ebuild and one temporary to eclass, which I'll revert when I'll have a gcc-4.1.0 based bootstrap. However it is failing on multilib for me now: Adding multilib support to Makefile in /var/tmp/portage/gnat-gcc-4.1.0/work/gcc-4.1.0/libmudflap multidirs=32 with_multisubdir= Running configure in multilib subdirs 32 pwd: /var/tmp/portage/gnat-gcc-4.1.0/work/build/x86_64-pc-linux-gnu/libmudflap Running configure in multilib subdir 32 pwd: /var/tmp/portage/gnat-gcc-4.1.0/work/build/x86_64-pc-linux-gnu mkdir 32 configure: creating cache ./config.cache checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... x86_64-pc-linux-gnu checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for --enable-version-specific-runtime-libs... no checking whether to enable maintainer-specific portions of Makefiles... no checking for x86_64-pc-linux-gnu-gcc... /var/tmp/portage/gnat-gcc-4.1.0/work/build/./gcc/xgcc -B/var/tmp/portage/gnat-gcc-4.1.0/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -m32 checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[2]: *** [configure-target-libmudflap] Error 1 make[2]: Leaving directory `/var/tmp/portage/gnat-gcc-4.1.0/work/build' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/portage/gnat-gcc-4.1.0/work/build' make: *** [bootstrap] Error 2 This is on amd64 of course. Since I presume x86 should not have this issue there is a hope it will work in my 32bit chroot. Then I''ll add it to the tree as ~x86. George
Lots of changes.. 1. The gnatbuild.eclass has been significantly improved. It now picks up some relevant patches from gcc, handles multilib better, fixes occasional sandbox violations, plus all actually builds on a system lacking gcc>=3.4! To accommodate these changes gnat-gcc-3.4.5-r has been issued. Another significant change in ebuild is that it uses i386 bootstrap on x86, so all subarches should be happy. 2. I am pleased to announce the availability of gnat-gcc-4.1.0! Based on the same updated eclass, needed really small number of adaptations.. It could be built off gnatboot-3.4, but rebuilding it off generated 4.1 package produced different binaries, so I made it build off this new bootstrap.. 3. Some misc fixes, which I don't remember now.. Please standby for the eselect-gnat upgrade, as it seems to have problems sometimes, although it may work for you.. The new version of eclass and ebuilds are in the tree, masked. As this update seems to fix all known to me issues I am going to unmask them after eselect-gnat is updated, hopefully within a week. George
Few minor modifications to eclass. Added new gnat-gpl revision, so this version of compiler works as well. Also, gcc-3.4.6 just got released, so I issued a matching gnat-gcc version. Basically an ebuild rename, however tge gcc folks now apparently made gcc use builtin specs instead of reading them from somewhere (what was already the case for 4.1.0). So this version brings you a cleaner gnat-gcc install without that ugly wrapper (just as gnat-gcc-4.1.0 does too). eselect-gnat seems to work btw, but it probably does not clean-up thoroughly, so it can start complaining when seeing extra files. However the gnat compilers are ready for testing.. George
Status update: The compilers seems to work fine - I got a few test reports and all were successful. However you *may* have some issues if you have traces of older attempts still around somewhere and you *will* have problems if you try to have both legacy (dev-lang/gnat) and new (gnat-xxx) compilers installed together, so if you appear to have problems, please just clean gnat-everything and start anew. To guard against the second case I added blockers to eclass and ebuilds.. I added virtual/gnat, 3.4 and 4.1 versions. First lists both gnat-gcc and gnat-gpl, second, naturally, only gnat-gcc. Everything that attempts to use gnat compilers from now on should depend on this virtual, unless it needs some features that are only present in some specific version (e.g. gnat-gpl).. Libs. After meditating on the variants of support mentioned in thig bug at different places I settled on the following way of handling them: 1. Every lib will produce multiple variants during the build - one per installed gnat compiler 2. The active variant will be selected by eselect-gnat (which will have to be updated to support the libs as well). 3. eselect-gnat will produce a warning if some lib does not have a variant for one of the installed compilers or if it has extra (possible, if compilers were merged/unmerged after the lib was built) and will suggest remerging the lib.. 4. gnat.eclass will be modified to hold the bulk of this functionality (ebuild related part of course). Right now it only checks and cleans CFLAGS and defines only pkg_setup, so it even seems some backwards compatibility is possible (which allows to now mask legacy gnat immediately upon unmasking new compilers, so that libs can be upgraded gradually).. George
Another update. 1. gnat compilers seem to work fine, no complaints received in last few weeks or even a month and finally they were unmasked a week ago.. 2. I produced an initial implementation of new libs framework! Seems to work and produce desired result (as described in previous post). For it to work you need a) to unmask >=app-admin/eselect-gnat-0.7 and dev-ada/ b) download the attached (next post) new version of gnat.eclass c) unmask new "enabled" versions of ada libs and emerge them. Only the booch_components are "enabled" at the moment (this is a first shot at this whole thing), so this basically means - add =dev-ada/booch_components-20051222 (yes, new version is out BTW) to your /etc/portage/package.unmask (just as for the new version of eselect-gnat). New gnat.eclass should of course go into your portage overlay, unless you want it overwritten on a next sync. Please test and report success/failure. The eclass and new eselect module have some comments at the top for those interested in how it all works. Suggestions/optimizations are wellcome! George
Created attachment 85982 [details] new gnat.eclass - to accomodate new gnat compilers Also obsoleted eselect-gnat files, as the newer and better stuff is in the tree for quite some time. Please test (the new gnat.eclass). I would like to polish the new libs framework on one or two libs first. Updating the rest of them will then be easy.. George
A notice on ASIS: I actually first tried to adapt gnat.eclas while working on asis, but that did not play too well. In too many cases I found that I wanted to inherit the gnatbuild.eclass or at least utilize some of its settings. Which in fact makes sense, as asis is really a part of a compiler, an extra and pluggable, but still.. So in short I came to the conclusion that asis will have to be dealt with in a special way. It would have to depend on gnatbuild.eclass, does not need may (or even any) of the gnat.eclass functionality and install into the gnat locations. This can become quite messy (esp. in the part of idenifying the right SLOT, etc.) or at least require a lot of duplicated code if I am to keep it a separate package it is now. Instead I am thinking of building it as a part of gnat compiler itself, made optional by addition of a (local) asis USE flag.. Any thoughts/objections? George
re. ASIS If you maintain two packages, sharing the gnatbuild.eclass you'll end up with things like: if [[ ${PN} == "gnat" ]] If this only happens for a few lines then it can sense - however if there are significant differences it won't be nice. In that case it might be better to split common code out into a gnatbuild-funcs.eclass (as an "elib" type of thing), with the gnat-specific stuff in gnatbuild.eclass as a proper eclass used by the gnat-* compiler ebuilds. Personally I think building ASIS as a USE option to gnat-* would be a good idea, if the ASIS build depends on the gnat compiler source tree.
I have installed dev-lang/gnat-gcc-4.1.0 on April 14 without any problem. Since then it has properly compiled more than 20 different little exercise programs (about 100-200 lines of code each). I have seen that the PATH environment variable of the 'root' user is not modified to include '/usr/i686-pc-linux-gnu/gnat-gcc-bin/4.1'. Is it intended to work this way? While we are here... Please forgive me for the next newbie question. Since I want to test it, can you please explain where exactly your gnat.eclass should be copied to? I have PORTDIR_OVERLAY=/usr/local/portage in /etc/make.conf, but I am not sure whether I should create a 'eclass' sub-directory (that is /usr/local/portage/eclass) or simply I should copy your gnat.eclass directly to /usr/local/portage. I am asking this because a 'eclass' sub-directory exists in /usr/portage, so I think the same structure should work.
Hi Fabio Thanks for testing! (In reply to comment #74) > I have installed dev-lang/gnat-gcc-4.1.0 on April 14 without any problem. > > I have seen that the PATH environment variable of the 'root' user is not > modified to include '/usr/i686-pc-linux-gnu/gnat-gcc-bin/4.1'. Is it intended > to work this way? The gnat-xxx compilers have been unmasked since when you installed them and you may want to at least regenerate the env files (look into gnatbuild.eclass - create_eselect_conf function, if you do not want to rebuild them, otherwise you can just emerge again..). I added ROOTPATH not so long ago, so this issue has been resolved: > Since I want to test it, can you please explain where exactly your >gnat.eclass > should be copied to? I have PORTDIR_OVERLAY=/usr/local/portage in > /etc/make.conf, but I am not sure whether I should create a 'eclass' > sub-directory (that is /usr/local/portage/eclass) Yes, the PORTDIR_OVERLAY is simply an alternative root for portage tree and everything found there is collated with the "main" tree (in fact with later portage you can have multiple overlays, although I don't remember whether this is true for the already-in-~arch versions or only the latest "pre-alpha's"). Thus you simply need to recreate the structure for the necessary parts of the tree. Such as all eclasses would go under eclass dir and all additional ebuilds uder normal category/pkgname location (all that under PORTDIR_OVERLAY of course). Thanks again for testing! I am really waiting for at least some reports on how the new gnat.eclass works now to feel reasonably confident to put it in the tree.. George
Hi George. (In reply to comment #75) > Hi Fabio > > Thanks for testing! No problem. As I wrote in private to you a few weeks ago I would be happy to contribute some way. Anyway I haven't yet had enough time for reading the developer manual as you suggested, so I can only report problems without providing solutions. I hope to find some time in the next days to make sense of Gentoo Portage System with all that it is related to it in order to provide some concrete help. > The gnat-xxx compilers have been unmasked since when you installed them and you > may want to at least regenerate the env files (look into gnatbuild.eclass - > create_eselect_conf function, if you do not want to rebuild them, otherwise you > can just emerge again..). I added ROOTPATH not so long ago, so this issue has > been resolved: I had to edit the /etc/env.d/55gnat* file for adding the ROOTPATH variable, because a rebuild didn't resolve that issue. > Yes, the PORTDIR_OVERLAY is simply an alternative root for portage tree and > everything found there is collated with the "main" tree (in fact with later > portage you can have multiple overlays, although I don't remember whether this > is true for the already-in-~arch versions or only the latest "pre-alpha's"). > Thus you simply need to recreate the structure for the necessary parts of the > tree. Such as all eclasses would go under eclass dir and all additional ebuilds > uder normal category/pkgname location (all that under PORTDIR_OVERLAY of > course). Thanks, done. Then I installed dev-ada/boochs_component without problems, but I haven't yet had enough time to check if the library is properly working. > Thanks again for testing! I am really waiting for at least some reports on how > the new gnat.eclass works now to feel reasonably confident to put it in the > tree.. > > George I have to report a problem. While rebuilding gnat-gcc-4.1 I have noticed that notwithstanding /etc/make.conf enables FEATURES="maketest" the ACATS tests are not executed. They should be started by "make check" after compiling and before installing. Regards. fabio de francesco
George, i'm not sure if you received my bug report that I sent by email, so I dublicate it here: Great job! :-) I've tried emerge booch_components with gnat-gcc & gnat-gpl. It worked fine and installed two bunch of .ali & .so files. But it set bad permissions for files: ls -l /usr/include/ada/booch_components/bc.ads -rw-r----- 1 root root 2884 Май 4 13:31 /usr/include/ada/booch_components/bc.ads So ordinar user cant read them. I fixed perms and then compiled and ran bc tests successfuly (on both gnats).
(In reply to comment #76) > > can just emerge again..). I added ROOTPATH not so long ago, so this issue has > > been resolved: > > I had to edit the /etc/env.d/55gnat* file for adding the ROOTPATH variable, > because a rebuild didn't resolve that issue. Yea, sorry, I just rechecked what was going on - apparently I "solved" it in gnatbuild.eclass (may be eevn at that time it was relevant there actually), but it should have been done in eselect-gnat module :). Corrected this now, however this is in the 0.8 version (of eselect-gnat) which is not yet comitted. Will do so shortly, but first I want to see if I need to bring any other changes in (so that I do not create too many different versions). > I have to report a problem. While rebuilding gnat-gcc-4.1 I have noticed that > notwithstanding /etc/make.conf enables FEATURES="maketest" the ACATS tests are > not executed. They should be started by "make check" after compiling and before > installing. Yea, I did not get to the tests yet. First I wanted to make it all working :). However please do submit a new bug, requesting tests to be added, so that I do not forget about them.. (In reply to comment #77) > George, i'm not sure if you received my bug report that I sent by email, so I > dublicate it here: Yes, I did see it, just did not have time to react yet. Thanks for testing! > But it set bad permissions for files: > ls -l /usr/include/ada/booch_components/bc.ads > > -rw-r----- 1 root root 2884 Май 4 13:31 > /usr/include/ada/booch_components/bc.ads Strange - I had this problem, but only with docs and this was fixed in the committed ebuild. But for the good measure I will make a similar fix to the installed specs as well - here is the diff to ebuild that you may try before it is committed: @@ -40,7 +40,8 @@ src_install () { dodir "${AdalibSpecsDir}/${PN}" cd ${S} - cp *.ad? ${D}/${AdalibSpecsDir}/${PN} + insinto "${AdalibSpecsDir}/${PN}" + doins *.ad? #set up environment echo "ADA_OBJECTS_PATH=%DL%" > ${LibEnv} George
Ok, gnat-eselect-0.8 is out (also adding ROOTPATH), new bug is submitted and these permission fixes are in :). I finally added new gnat.eclass to the tree and unmasked booch_components-2005... I also redid xmlada, the 1.0-r1 is in, containing multiple fixes btw (upstream apparently disabled shared libs for unclear reason, but in any case they user a *really* weird versioning - libxmlada_..-0.8.1.so. Not only the version is not where it should, they marked it 0.8.1 for no apparent reason (while the lib is 1.0 according to themselves..). I suspect they simply forgot about anything-shared ever since they disabled them (what looks like at 0.8.1)). In any case, at this point I would really like to request help - first testing of course :), but also moving libs to the new eclass. Hereby I would like to officially issue a call for a long-term Ada maintainer in portage. I will mentor you if you are not a dev yet, but the first step would be making sense of gnatbuild and gnat.eclass'es ;). I really need to take some time to write up lib handling and porting in more details. I guess I'll need to organize an "Ada project", may be even as a subproject of lang-misc or some such, so that there is an official and coherent place for all this info.. But in any case here are the porting basics: 1. inherit gnat - in addition to all other inherits. Old gnat.eclass was simply stripping flags and I had to add DEPEND=">=app-admin/eselect-gnat-0.8" to new eclass, which is still conflicting with the (old-style) libs marked stable, so I had to strip it from these ebuilds for now.. 2. If something is getting compiled, it should be compiled for every gnat present. This is taken care of by gnat.eclass in gnat_src_compile. It calls (back?) lib_compile and lib_install functions which look pretty similar to normal src_compile and src_install. One major difference is that lib_install should install *only* gent-profile specific stuff (basically just what was built). Normally it gets called from within src_install, wrapped into the code that installs specs and docs (these clearly only need to be installed once).. See booch_components-20051222 and xmlada-1.0-r1 ebuilds for the examples. 3. A few vars are defined in gnat.eclass that should help you placing stuff in the right places. ${SL} - analog of $S, this is where sources are copied for a particular build (by the activated gnat) ${DL} - analog of $D, this is where profile-specific stuff should be installed ${AdalibSpecsDir}/${PN} - where specs (*.ad?) should normally go ${LibEnv} - file where configuration is created. It uses %DL% to denote the location where built libs/binaries are put, which gets expanded to the right location by eclass (thus creating an env file for every gnat profile). You may create subdirs such as lib/, bin/ as necessary under it (if it makes sense) while installing sutff. Then, apparently, ADA_OBJECTS_PATH and PATH should point to corresponding subdirs of %DL%.. Otherwise it is pretty similar to normal ebuild writing.. George
Oh, one more thing: eselect gnat update should be called from pkg_postinst to regenerate that gnat env file that collates all the settings for the active profile. (It simply calls set with the name of the active profile). George
Hi George, (In reply to comment #79) > Ok, gnat-eselect-0.8 is out (also adding ROOTPATH), new bug is submitted and > these permission fixes are in :). > > I finally added new gnat.eclass to the tree and unmasked > booch_components-2005... I also redid xmlada, the 1.0-r1 is in, ... > [cut] > ... In any case, at this point I would really like to request help - first testing > of course :) I have just installed xmlada and everything seemed to go well but I have found a problem while listing /usr/lib/ada/i686-pc-linux-gnu-gnat-gcc-*/xmlada/. In every directory there are four libxmlada_*.so symbolic links pointing to libraries that don't exist. It seems that shared libraries have got the wrong name, while the static ones are ok. The following is taken from the output of 'ls' command: -rw-r--r-- 1 root root 126758 May 15 19:22 libxmlada_dom.a lrwxrwxrwx 1 root root 20 May 15 19:22 libxmlada_dom.so -> libxmlada_dom.so.1.0 -rwxr-xr-x 1 root root 89412 May 15 19:22 libxmlada_dom_inst.so.1.0 -rw-r--r-- 1 root root 24594 May 15 19:22 libxmlada_input_sources.a lrwxrwxrwx 1 root root 30 May 15 19:22 libxmlada_input_sources.so -> libxmlada_input_sources.so.1.0 -rwxr-xr-x 1 root root 20044 May 15 19:22 libxmlada_input_sources_inst.so.1.0 -rw-r--r-- 1 root root 304206 May 15 19:22 libxmlada_sax.a lrwxrwxrwx 1 root root 20 May 15 19:22 libxmlada_sax.so -> libxmlada_sax.so.1.0 -rwxr-xr-x 1 root root 241736 May 15 19:22 libxmlada_sax_inst.so.1.0 -rw-r--r-- 1 root root 1713338 May 15 19:22 libxmlada_unicode.a lrwxrwxrwx 1 root root 24 May 15 19:22 libxmlada_unicode.so -> libxmlada_unicode.so.1.0 -rwxr-xr-x 1 root root 1030768 May 15 19:22 libxmlada_unicode_inst.so.1.0 What do you think has happened? > but also moving libs to the new eclass. Hereby I would like to > officially issue a call for a long-term Ada maintainer in portage. I will > mentor you if you are not a dev yet, but the first step would be making sense > of gnatbuild and gnat.eclass'es ;). I would like to be of some help when I will have done with reading the developer manual and the other stuff you suggested. Anyway I hope you will soon find someone else that is already skilled in Gentoo development. Anyway I have already done a first reading of the files you mention (gnat and gnatbuild.eclass'es). They seem to be quite easy to understand (I still need a quick re-read of Bash manual) except the fact that they refer to some external variable that I don't yet know where to find it defined (like $D or $WORKDIR). I think I have begun from the wrong place and instead I should first read the above mentioned developer manual. > I really need to take some time to write up lib handling and porting in more > details. I guess I'll need to organize an "Ada project", may be even as a > subproject of lang-misc or some such, so that there is an official and coherent > place for all this info.. This would be a very good idea. > But in any case here are the porting basics: > > [cut] > > George Regards. fabio
(In reply to comment #81) > I have just installed xmlada and everything seemed to go well but I have found > a problem while listing /usr/lib/ada/i686-pc-linux-gnu-gnat-gcc-*/xmlada/. In > every directory there are four libxmlada_*.so symbolic links pointing to > libraries that don't exist. It seems that shared libraries have got the wrong > name, while the static ones are ok. The following is taken from the output of > 'ls' command: > > -rw-r--r-- 1 root root 126758 May 15 19:22 libxmlada_dom.a > lrwxrwxrwx 1 root root 20 May 15 19:22 libxmlada_dom.so -> > libxmlada_dom.so.1.0 [skipped] > What do you think has happened? Sorry, missed it. That Makefile.in that comes with the package is really weird. When I figured this one out I basically went "W(ho)TF is writing Makefiles like that?" Are those %_inst=% things throughout serving any purpose but to make it all quite messy? Anyway, it is this line in Makefile.in: ifeq (${BUILD_SHARED}, TRUE) cd ${PREFIX}/lib; ${LN} libxmlada_${@:%_inst=%}-${MAJOR}.${MINOR}.so libxmlada_${@:%_inst=%}.so endif You can see that the ebuild seds it to put ${MAJOR}.${MINOR} where they should be (that is *after* .so), but that _inst stuff is getting screwed. For a quick fix you can change the sed in ebuild (line 45) to: -e "s:libxmlada_\${@\:%_inst=%}-\${MAJOR}.\${MINOR}.so:libxmlada_\${@}.so.${MAJOR}.${MINOR}:" \ (notice missing \:%_inst=% in the replacement). This will fix the symlinks, but the .so.1.0's still have that _inst in their name, which is ugly. I'll try to figure out how to make it cleaner and than update the ebuild.. > variable that I don't yet know where to find it defined (like $D or $WORKDIR). These are portage vars, kind of "intrinsic" - portage will recognize and substitute them. You can read about their values here (this is Ebuild HOWTO): http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 scroll down a bit, its under the "Variables" heading (Of course you can also read portage code ;). I used to do this in earlier times, when we did not have the handbook yet :)). George
Fixed. Actually that Makefile.in was outright broken - couple of lines before that where the .so's were compiled there was a typo.. I issued a revbump (its at 1.0-r2 now) with an updated sed, since this affects the result.. George
Hi George. I am sorry for reporting further bad news without being able to provide solutions. Still problems with xmlada library. Not sure whether I have to open a new bug or report it here. Anyway, the following is the error message I got while compiling xmlada-1.0-r2: ### start message ### # Build the libraries themselves cd unicode/obj; ar cr libxmlada_unicode.a *.o ar: *.o: No such file or directory make: *** [unicode_inst] Error 1 !!! ERROR: dev-ada/xmlada-1.0-r2 failed. Call stack: ebuild.sh, line 1527: Called dyn_compile ebuild.sh, line 931: Called src_compile ebuild.sh, line 1240: Called gnat_src_compile gnat.eclass, line 196: Called lib_install 'i686-pc-linux-gnu-gnat-gcc-3.4' xmlada-1.0-r2.ebuild, line 64: Called die ### end message ### Don't know why the unicode/obj directory has got no '*.o' file to be put in libxmlada_unicode.a. If you prefer I can open a new bug report or leaving it here. Thanks. fabio
(In reply to comment #84) > If you prefer I can open a new bug report or leaving it here. Yes, please. This bug is becoming rather lengthy and it is better to keep it more "conceptual", although I am already thinking about closing it as soon as I get through asis (right now I am working on gtkada, its quite messy too unfortunately) - the original issue (the compilers themselves) is resolved already. You may mark new bug as blocking this one. Oh, BTW, I've been in contact with AdaCore developers and apparently xmlada and gtkada (as well as all other stuff on libre2.adacore.com) is pure GPL now (it used to be GMGPL).. George
Ok. I will file a new bug report within tomorrow (my laptop battery is rapidly discharging). I agree with you in leaving this bug more "conceptual". As far as the libraries distribution licences are concerned I hope they mean LGPL. GPL licence would imply real problems. fabio
I emerged xmlada-1.0-r2 successful, but I got in /etc/env.d/55gnat-i686-pc-linux-gnu-gnat-gpl-3.4 ADA_INCLUDE_PATH=...:/usr/lib/ada/adainclude/xmlada instead of /usr/include/ada/xmlada So compiler can't find sources when I compile some tests.
GtkAda done, 2.4.0-r1 in the tree and is the one that should work with split compilers. The ebuild does *not* install gpr files (they weren't installed by previous verisions as I can see either) since that would be pointless with all the paths specified in them, however if having them is desirable, please say so, I'll try to adapt them.. Now I am going to take at asis, most likely I'll make it a part of gnat as I mentioned earlier, but I'll see.. George
(In reply to comment #87) > I emerged xmlada-1.0-r2 successful, but I got in > /etc/env.d/55gnat-i686-pc-linux-gnu-gnat-gpl-3.4 > ADA_INCLUDE_PATH=...:/usr/lib/ada/adainclude/xmlada Yup, my omission (apparently just copied old setting over :(). Fixed in cvs. Thanks for spotting this! George
Created attachment 87502 [details] adasockets-1.8.4.7.ebuild I'm trying to do adasockets ebuild and found that It's strange, but ADA_INCLUDE_PATH in lib_compile is double of usual: /usr/lib/gnat-gcc/i686-pc-linux-gnu/4.1/adainclude:/usr/include/ada/adasockets:/usr/include/ada/booch_components:/usr/lib/ada/adainclude/xmlada:/usr/lib/gnat-gpl/i686-pc-linux-gnu/3.4/adainclude:/usr/include/ada/adasockets:/usr/include/ada/booch_components:/usr/lib/ada/adainclude/xmlada And I dont know how to deal with libadasocket.so library if there is more then one gnat... It's imposible to install two or more of them in /usr/lib because of they have the same name. Any ideas?
(In reply to comment #90) > I'm trying to do adasockets ebuild and found that > It's strange, but ADA_INCLUDE_PATH in lib_compile is double of usual: > /usr/lib/gnat-gcc/i686-pc-linux-gnu/4.1/adainclude:/usr/include/ada/adasockets:/usr/include/ada/booch_components:/usr/lib/ada/adainclude/xmlada:/usr/lib/gnat-gpl/i686-pc-linux-gnu/3.4/adainclude:/usr/include/ada/adasockets:/usr/include/ada/booch_components:/usr/lib/ada/adainclude/xmlada There was this problem at one point - I was adjusting gnat.eclass and eselect-gnat pretty often, while working on xmlada and gtkada. Its back to normal in the latest committed versions. Please sync (to pick up new eclass) and update eselect-gnat (it should be 0.8-r1).. > And I dont know how to deal with libadasocket.so library if there is more then > one gnat... It's imposible to install two or more of them in /usr/lib because > of they have the same name. Any ideas? This should be fine during build, as all the relevant env vars are exported and should be picked up by gnat properly. However there is not mechanism in place yet to let ld know which one to select at run-time. I was not sure how best to deal with it when I was starting on eclass, so I postponed this untill I can get a better grip on how it all looks like. I think now, with three libs being built it has stabilized enough to revisit the question, so let's decide on something :). In general there are three ways to deal with shared libs: 1. Set LD_LIBRARY_PATH, can be done the same way as all the other vars, so adding this is the easiest I guess. The downside is that using this var is considered bad practice, especially on a system-wide level (security considerations and can easily be broken by careless setting of this var by local admin). 2. Add entry to /etc/ld.so.conf and regenerate ld.so.cache. Second is done automatically as ldconfig is run upon successfull emerge and its invocation is also part of env-update, which we require to run upon gnat profile change anyway.. 3. Provide symlinks into one of the system dirs -/usr/lib for example. Rerunning ldconfig here is necessary as well, and this is covered in the same way as in 2. Al of these should be done by eselect-gnat and not the package itself apparently. So, we need to decide which of approaches to choose and then I will add the relevant code to gnat.eselect.. As 1. is considered bad and no package in portage visibly uses this aproach lets leave it for now and consider the other two.. Both 2. and 3. seem to be similarly doable, so this is rather a question of which one feels "cleaner". As far as I can tell both approaches are used by packages. Look at /etc/ld.so.conf shown numerous entries such as: /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/native_threads/ or /emul/linux/x86/usr/lib So it seems that many packages just install their specific entries there via providing LDPATH to their env.d entries. Thus I think we can shoot for either of these approaches (with 2. looking easier to implement, actually as easy as 1.) or even their combination: I can make gnat.eclass search ${DL} for *.so* files and move them to ${AdalibLibTop}/${gnat-profile} (note, no $PN} at the end), so that only one entry will have to be added. Of course this will require more modifications to gnat.eclass and gnat.eselect than either of the two approaches.. So, right now I am thinking about just adding LDPATH entries (i.e. going with plain variant 2.) unless there are any objections.. George
Some comments on shared libs: Neither of the proposed resolutions of course does not resolve the situation completely. What we have here is three versions of binary incompatible libs having identical names and versions (as these reflect the *library* version and not the gnat with which they were compiled). As far as I can tell (and I had a little chat today with lu_zero on #gentoo-dev) this cannot be resolved via "standard" means, short of slapping our own *additional* versions onto the .so files. (in this regard the strange way in which AdaCore adds version numbers to their libs - that is *before* the .so, may come in handy, although that still will be contrary to what anybody will be expecting (that is normally one expects the numbers *after* the so to represent the *library* versions)..) So, it yet *may* be possible to produce the "full" solution, but at the very least it will require coming up with some numbering scheme reflecting gnat profiles and then extending versions of Ada libs. This may get quite nasty in terms of code.. Instead I am going to go on with a rather simple but "half-solution", either #2 or a "mixed" approach as I mentioned in the previous post. This will allow to have a consistent situation where it will be possible to compile and run binaries. However the limitation is that the binaries will have to be run under the same gnat profile as they were compiled.. This will be more annoying to those who switch back and forth frequently, but I expect that most people would primarily use one gnat profile and only occasionally switch to some other. Plus, to run a binary created with inactive gnat it is not strictly necessary to switch profiles - on can specify LD_LIBRARY_PATH in the command line, while launching the binary (yet another reason not to go with approach 1 from previous post). George
Hi George, There is a problem with gnat-gpl. After installing it sets the active compiler to be itself. I saw that with running "eselect gnat list". At first, anyway, the $PATH wasn't affected by that new setting. Then, after "source /etc/profile", the $PATH was modified too. A simple re-run of "eselect gnat set", followed by ". /etc/profile" switched back to the wanted compiler (that was gnat-gcc-4.1). Regards. fabio
Hi George. As far as it is concerned with the problems of managing different binaries and libraries built with different active and inactive compilers don't you think you are providing 'too much' freedom to the users? As you already know I haven't got any experience with all that. Anyway I begin to think that managing all that flexibility could become so heavy that it may be not worth the hard work... I think the majority of us (the users) just need a reasonably recent version of only one Ada compiler that we can use for compiling only one instance of a reasonably recent version of all the Ada development libraries (gtkada, xmlada and so on...). With the very same compiler version we'll compile our own binaries and third party ones too. Everything that can't be compiled with that recent compiler would simply be labeled as "not yet supported". Thanks for everything. fabio
(In reply to comment #94) > As far as it is concerned with the problems of managing different binaries and > libraries built with different active and inactive compilers don't you think > you are providing 'too much' freedom to the users? Well, this is why I will not do any major modifications at this point any more to the gnat.eclass and eselect-gnat. So, this is how it stands now. I've added the code processing LD_PATH to eselect-gnat and provided LD_PATHs in ebuilds, only in gnat-xxx at the moment though. There is one way to make the compiled binaries pick up shared libs *always* - that is by setting LD_RUN_PATH, then its value gets compiled into the produced programs. This should work fine and I even experimented with it a bit. However, with the way gnat.eselect works now, LD_RUN+PATH is effectively set in environment, which means that these paths are compiled into *every* binary produced on that system. This is not very efficient, as every app now will have to search for needed .so files first in these paths, only then going through ld.so.cashe entries. It is possible to separate this var, but that would require wrappers and some involved modifications to eselect-gnat package. As was pointed out, this will seemingly only benefit a few people, while the rest of users come at disadvantage, so I decided to drop this approach. Instead I will just add LD_PATH to the ebuilds, as per variant 2. Now, to run the produced binary you need to activate the gnat-profile it was compiled under, or set LD_LIBRARY_PATH at runtime, or set LD_RUN_PATH in gnat build environment. Some extra work, but I do not expect many people to actually need this often, only those frequently switching active gnat profiles.. With this I consider design phase over. Now I just need to wrap it all up in some descriptory text and create a Gentoo Ada homepage or something :). George
(In reply to comment #93) > There is a problem with gnat-gpl. After installing it sets the active compiler > to be itself. Well, that was actually the intended effect, but yea, this is contrary to what gcc is doing. So, what would be the common expectation? Should I keep it at "activate a newly installed gnat" or change it to gcc-like "keep the present profile active"? George
Hi George. (In reply to comment #96) > > [skip a few lines] > > So, what would be the common expectation? Should I keep it at > "activate a newly installed gnat" or change it to gcc-like "keep the present > profile active"? > > George I would prefer to change it to gcc-like behaviour. I think that this way is more consistent with which a Gentoo user would expect. No one else has yet expressed his thought on this subject. Obviously the final decision is up to you. fabio
Hi George. I have just re-read this long thread in search of comments about ASIS. I found that you wrote you are currently working on its inclusion. Before that note I also read another one from Kevin F.Quinn that stated "Personally I think building ASIS as a USE option to gnat-* would be a good idea, if the ASIS build depends on the gnat compiler source tree.". As far as I know, ASIS build does depends on the gnat compiler source tree. If I understand well you agreed with Kevin, didn't you? Anyway I think that the above-mentioned solution would be the right one. Furthermore I think that the GLADE (the Annex E gnat implementation) install should work the same way because this too is strictly linked to the compiler it is built with. What do you think about these issues? Are you already working in this direction? Greetings. fabio
(In reply to comment #98) > I found that you wrote you are currently working on its inclusion. Before that > note I also read another one from Kevin F.Quinn that stated "Personally I [skip] > I understand well you agreed with Kevin, didn't you? Anyway I think that the > above-mentioned solution would be the right one. Yes, that's right. At some point I set to work on its ebuild, but realised that it would borrow heavily from gnatbuild.eclass and pretty much none from gnat.eclass (plus the SLOT logic will have to follow that of gnat). This is when we had that discussion. So, yea, it is going to be done as a part of gnat most likely. > Furthermore I think that the GLADE (the Annex E gnat implementation) install > should work the same way because this too is strictly linked to the compiler it > is built with. What do you think about these issues? Are you already working in > this direction? Thanks for this comment. I have not used GLADE, so I did not know. I wonder, if somebody familiar with GLADE would want to take a shot at it though? ;) At the very least please submit a bug describing any details you may provide on this. You may mark it as blocking this one, so that we can track it easily. As for "working in this direction" - yes, I was going to start on ASIS quite some time ago, but first I wanted to finish up with gnat.eclass and that required a few libs to be ported, and gtkada turned out to be quite involved one.. But now it seems all the major stuff is done, so I should start looking at ASIS "any time now" :). Although there were a few changes to toolchain.eclass since I forked gnatbuild.eclass off it, so I'll probably have to backport the ones that make sense first.. George
(In reply to comment #99) > [skip a few lines] > Thanks for this comment. I have not used GLADE, so I did not know. I wonder, if > somebody familiar with GLADE would want to take a shot at it though? ;) > At the very least please submit a bug describing any details you may provide on > this. You may mark it as blocking this one, so that we can track it easily. > > George > Hi George. Unfortunatelly at the moment I am able to help you by only submitting the bug you talked about. Like you I also haven't yet used GLADE (as I already told you I am still studying the Ada language basis), however I think I know what it is and how to install it. The manual install of the GLADE component is a trivial task that can be performed in a very few steps. In the bug I am going to open I will describe these steps and furthermore I will provide you with a couple of link. The README and INSTALL files in the CVS tree can be easily browsed for making up an idea of what GLADE exactly is and how to install it. I have found a bit strange that among Ada libraries we have one called "Garlic", because it is only a subdirectory of the whole GLADE package... Is it a feature that can be separatelly installed and used without need of the other parts of GLADE? Greetings. fabio
Hi George. As you have pointed out a couple of times this bug is becoming a bit too long. I agree with you. It is also difficult to read it and to follow threads of discussion. What do you think about starting a new one specifically devoted to the general reorganization of Ada support in Gentoo and other more "conceptual" (as you defined those) discussion? This new bug would lasts until the completion of the reorganization of compilers, compiler's libraries and other important basilar tools (the ones you are working on in order to be successfully compiled by the new gnat-gcc and gnat-gpl). While we are here... I can't update to both xmlada-1.0-r4 and booch_components-20051222-r1 in any of my two Gentoo boxes. The emerge tool shows messages about "Digest verification failed" because "Filesize does not match recorded size". "emerge --sync" after a few days didn't fix it so I had to run "ebuild <package> digest" and now I am here to inform you that so you can fix it. Thanks. fabio PS.: Please, forgive me for my poor English... I have noted an error in my latest message: "basilar" had to be "basic". I am sure I have already made many more mistakes in this thread.
Hi George (third time today). :) As far as the GPL edition of GNAT is concerned, that should be the one that is provided by Ada Core Technology, I am not sure to understand how you are doing. I see that you are providing a "gnat-gpl-3.4.5-rx" that doesn't match, at least in the name you give to it, with the ACT "gnat-gpl-2006". Maybe I am missing something already discussed in this thread (as I wrote it has become a bit difficult to follow, at least for me). May you please explain what it is behind your decision? Thanks for all the work you are bringing forward. fabio
(In reply to comment #102) > I see that you are providing a "gnat-gpl-3.4.5-rx" that doesn't match, at least > in the name you give to it, with the ACT "gnat-gpl-2006". Maybe I am missing > something already discussed in this thread (as I wrote it has become a bit Yes actually :). > difficult to follow, at least for me). May you please explain what it is behind your decision? Sure, please see comments #23,26,28,29 ;). (Just had to run a quick textual search for gnat-gpl myself to get them :)). George
(In reply to comment #101) > While we are here... I can't update to both xmlada-1.0-r4 and > booch_components-20051222-r1 in any of my two Gentoo boxes. The emerge tool > shows messages about "Digest verification failed" because "Filesize does not > match recorded size". Hm, this is strange. I just regenerated digests and compared to the ones in the tree and they match.. I thought this might be related to portage update (there was a transient problem with hashes), but this is a size it complains about. Can you please: 1. resync 2. Delete relevant sources from DISTFILES (so that they are refetched) 3. If this still happens post a tail of complaint - it should show what files it complains about specifically.. Oh, and it is the cases exactly like this, when you should open a new bug, instead of growing this one yet longer ;). So, 4. if you still experience this, please open a new bug.. George
Hi George. As far as gnat-gpl versioning names are concerned I have just re-read the messages from this thread that you kindly listed for me in order to understand the subject. If I have well understood, you wrote that ACT use of "2005" in calling the compiler as "gnat-gpl-2005" simply makes a reference to the Ada Standard it comply with. With that assumption you then chose to name it gnat-gpl-3.4.5, willing to refer to the GCC back-end compiler release (gcc-3.4.5). Is it correct? Please notice that ACT has afterwards released a gnat-gpl-2006, the one I was talking about in my previous messages, that happens to use gcc-3.4.6 as a back-end compiler. It means that "2006" cannot anymore refer to any "Ada 2006 Standard". I think it simply means that this is a newer release, a "2006" version that supersides the old "2005" one. Anyway there doesn't exist any "Ada 2006 Standard". I suppose that ACT might release further new gnat-gpl versions without the need to be backed by a new GCC release. I mean they may in future introduce new features and bug fixes in a new release and call it "gnat-gpl-2006-r1" without any need to change the GCC release it uses. To summarize: 1) There is a new gnat-gpl that is backed by gcc-3.4.6. As soon you have time for that, would you please include that new compiler in the Gentoo's tree? 2) Are you still sure that nameing releases of gnat-gpl by referring to the GCC back-end compiler is the best choice? I think that the other way Gentoo users may better understand which ACT gpl edition they are going to install by matching its name with the one they may have read from the libre.adacore.com site or other ACT official channels. They are still providing the users with the possibility to choose which version (2005 or 2006) to download. Thanks. fabio
(In reply to comment #105) > If I have well understood, you wrote that ACT use of "2005" in calling the > compiler as "gnat-gpl-2005" simply makes a reference to the Ada Standard it > comply with. With that assumption you then chose to name it gnat-gpl-3.4.5, > willing to refer to the GCC back-end compiler release (gcc-3.4.5). Is it > correct? No, that was one of the (early) interpretations. It has been clarified in my interaction with AdaCore (hm, it seems it is not in the attached letters, must be in some others), however please see below. > 1) There is a new gnat-gpl that is backed by gcc-3.4.6. As soon you have time > for that, would you please include that new compiler in the Gentoo's tree? Done :). It is versioned 3.4.6.1 for now, but lets decide on this.. > 2) Are you still sure that nameing releases of gnat-gpl by referring to the GCC > back-end compiler is the best choice? > > I think that the other way Gentoo users may better understand which ACT gpl > edition they are going to install by matching its name with the one they may > have read from the libre.adacore.com site or other ACT official channels. Yes, this is a good consideration. However the real issue was that ACT did not provide me with a naming scheme they are going to follow. Accordingly to Robert Dewar (with whom I corresponded) they did not even have such scheme decided upon. Here is the excerpt from the email (that would be reply #3, not attached to this bug): --------------------- >Normally we are trying to stick as close as possible to what upstream >provides. However in this case in gnat-gpl-2005 the 2005 part seems related >to the language standard rather than a particular release number. You >mentioned that the package name will change with a new release. Could you >please elaborate on the expected naming/versioning scheme? I would like to >follow it if possible with our ebuilds. > > not yet decided >Right now we are debating whether to go with a gnat-gpl-2005 name, followed >by, possibly 2006.1, 2006.2.. or to go with a backend gcc versions adding a >specific gnat release number, thus making it 3.4.5.1 for this release, >3.4.5.2 for another gcc-3.4.5 based and so on.. > > if the sources are not identical, it would be good for your name to distinguish itself somehow --------------------------------------------------- Thus the gnat-gpl-2006 was quite expected (by me at least) but it does not provide any additional information. If ACT issues a new version within this year what is it going to be called? (even if they decide to stick to once per year releases they might need to issue a quick fix for some critical issue, so this cannot be relied upon) Will it even be compatible with portage rules or will we have to mangle it anyway? At least they promiced not to silently update the source under the same name :). Another, less important issue, is SLOT logic. Right now it is trivial, as it is common with gnat-gcc. However changing PV is not a big deal - just some conditionals in the eclass. Still, it is little bit less to maintain if we don't have to remember about it :). But I just thought of a way that combines both schemes, avoiding SLOT labor and providing easy tracking for the users. What about such scheme (following the eclass' variables): GCCVER.ACTver That is 3.4.5.1 becomes 3.4.5.2005 and 3.4.6.1 becomes 3.4.6.2006? ;) The change is trivial, does not require any updates to the eclass and will be viewed by portage as upgrade (so, no confucion to users either). The best thing - that 200x part can widely follow whatever ACT comes up with, as SLOT logic does not care about that last number - only about two most major numbers.. George
(In reply to comment #106) > But I just thought of a way that combines both schemes, avoiding SLOT labor and > providing easy tracking for the users. What about such scheme (following the > eclass' variables): > GCCVER.ACTver > > That is 3.4.5.1 becomes 3.4.5.2005 and 3.4.6.1 becomes 3.4.6.2006? ;) I think this makes very good sense; I thought the same thing myself when Fabio posted.
(In reply to comment #107) > (In reply to comment #106) > > But I just thought of a way that combines both schemes, avoiding SLOT labor and > > providing easy tracking for the users. What about such scheme (following the > > eclass' variables): > > GCCVER.ACTver > > > > That is 3.4.5.1 becomes 3.4.5.2005 and 3.4.6.1 becomes 3.4.6.2006? ;) > > I think this makes very good sense; I thought the same thing myself when Fabio > posted. Hi George and Kevin. These days I have been thinking about this issue and I am not sure I can agree with your proposals. I am sorry. However, please, let me explain what I think and forgive me when I often repeat my thoughts in order to be understood notwithstanding my poor English. As a principle I prefer using the very same name that upstream provides. In this case we had a gnat-gpl-2005 and now we have a gnat-gpl-2006 and I don't see any problem in using these names in Gentoo too. George has reported that, notwithstanding ACT hasn't yet decided on a consistent naming convention, they promised "not to silently update the source under the same name". This means that if they will release a gnat-gpl-2006 update this same year they will be anyway forced to using different names that distinguish two or more next gnat-gpl-2006. I mean that whatever names they will assign to future releases I don't see any problem in following their "de-facto" naming convention. Furthermore, they have released a new gnat-gpl-2006 that differs from the previous one not only on the gcc back end. Many more important changes have been included and so the back end upgrade seems to me to only be a minor improvement among others. As a user I would be much more interested in how many new features from the "Ada 2005 Standard" have already been included than what GCC is behind that. They could and probably will release some new gnat-gpl-2006 and 2007 editions in order to better comply with Ada Standard revisions even without updating the back end to gcc-4.x or they may choose to fix bugs. How will they christen those new releases? We don't know, anyway I think we won't have any problem whatever they will choose. Both gnat-gpl-2006.A or gnat-gpl-2006.1 or any other name they may choose we can report it to Gentoo as it is, provided they won't break the promise they made to George. To summarize I like the simple gnat-gpl-2006.x or alternatively I would prefer gnat-gpl-2006.x-3.4.6 to gnat-gpl-3.4.6.2006, also because we could incur in problems that relate with the ascending order for names and above all for the minor importance of the gcc release in the whole name. Anyway every decision is up to George. fabio
FWIW gnat-gpl-2006.x-3.4.6 is a no-go as it doesn't meet portage version number requirements - effectively it would make '3.4.6' the version number and '2006.x' part of the package name. There is a little more flexibility in the last part of the version number; for example if upstream release a second time in the same year they may go for 2006a which we can support directly as 3.4.6.2006a - we can't do that if 2006a is first. I disagree the gcc version is of minor importance; after all the gcc part is doing optimisation and code generation; gnat is the front end. It's especially important to understand whether this is a 3.x series or 4.x series, for example. It affects what switches you can give to the compiler; affects what optimisation you might choose and so on.
Also, the possibility to adapt to future ACT' issued versions strongly depends on the adopted versioning scheme. If it will be 2006.1, all is nice, but if they come up with some 2006A1, 2006-a, 2006_1 or some such we will have to change that anyway, as portage has rather strict rules on how ebuilds can be versioned, even though they cover >90% of situation. Probably even more like >99%, but still I have been beaten by strange versioning - erlang is one such case.. Therefore I am rather hesitant of changing versioning, short of adopting that proposal above (3.4.6.2006), before I see another version of gnat-gpl. Remember: it is easy to change *from* present scheme - almost anything will look like an update, but it will be more difficult to change back to comething similar again.. George
BTW When one unmerges a gnat compiler libraries installed in /usr/lib/ada/<compiler-name> are not deleted. Is it expected behavior? How to clear them?
(In reply to comment #111) > BTW When one unmerges a gnat compiler libraries installed in > /usr/lib/ada/<compiler-name> are not deleted. Is it expected behavior? How to > clear them? /usr/lib/ada doesn't contain any Ada compiler library. That directory only contains Ada user's libraries like gtkada (a port of GTK+ for Ada) and others. Ada compilers libraries from gnat-gcc and gnat-gpl are respectively located in subdirectories of /usr/lib/gnat-gcc and /usr/lib/gnat-gpl. fabio fabio
(from comment #112) > ... gtkada (a port of GTK+ for Ada) and others. (should be) > ... gtkada (Ada bindings to gtk+) and others.
Ok, long time, no comments.. First of all, I have changed gnatbuild.eclass to run "eselect gnat set" only when upgrading within the same compiler/SLOT. If new SLOTted version is installed, the formerly active one remains "intact". This required some extra logic (as compared to just running "eselect gnat set" every time), therefore the former behavior was the first thing implemented, but now it is done. ASIS: I finally got to it and added asis-3.4.6 and asis-3.4.6.2006 to the tree. This requires some explanation. The original idea was to add an "asis" use flag to the gnat-xxx compilers. Unfortunately, while trying this route gnat-gpl was universally triggering "internal compiler error". I tried setting/unsetting different env vars, changing sources, etc. but in every case the only thing that was avoiding this error was using the already-installed gnat (incidentally gnat was failing while compiling the file with the same name as it was reporting the error in, - quite confusing! Took some time to figure out, that it was actually a run-time error). So, I gave in and implemented ASIS as a separate package. There are a few things to keep in mind in connection to this: 1. ASIS has to be built with the matching compiler and this is really a 1:1 correspondence here. One cannot use a single ASIS source and then do the dance of gnat.eclass, like with the other libs. This means, that under dev-ada/asis there are multiple versions of asis which are to be used with exactly matching gnat-xxx compiler. This is an unfortunate effect but, as I indicated above, I could not make a newly built gnat (still under ${D}) to compile asis, however the one in the live system worked without problems. If anybody wants to try to move the code from the asis ebuild(s) to eclass and make it work (setting LDPATH, CC, ADA_XX_PATH, etc. to the proper locations) please be my guest and, if it works, please post the diffs here ;). Otherwise it will have to stay as it is now. 2. Versioning: I versioned asis ebuilds after the corresponding gnat versions. Thus, asis for gnat-gcc-3.4.6 became asis-3.4.6 and asis for gnat-gpl-3.4.6.2006 became asis-3.4.6.2006. In fact, there are only two of them now, so that list covers them all, but I hope to also add asis-4.1.1. This looked like the most apparent and straightforward versioning scheme, but if there are any ideas to improve it I would like to hear them. 3. ASIS SLOTs: SLOTs partially followed gnat-xxx convention - that is to use GNATBRANCH or the first two numbers of the matching gcc version. However here we do not have "issued by FSF vs ACT" info in the package name, so that got added to SLOT. Thus asis-3.4.6 has SLOT="FSF-3.4" and asis-3.4.6.2006 has SLOT="ACT-3.4". Therefore they can coexist in parallel. 4. ASIS files are installed at the corresponding gnat locations, so no extra configuration is necessary. Ebuilds check that the right gnat is activated and if not, complain and die. Circumventing this is possible via "hand installation" with "ebuild asis-x.x.x unpack setup compile install qmerge", but this is inadvisable, as the end result won't work and, in fact, this will likely not even compile (it does not for one combination, I did not even test the other). But as long as users go the "supposed" route (i.e. use only emerge command) everything should be consistent (well, otherwise a lot of stuff will break, and not only with Ada :)). 5. Nonetheless this means that if you simply "emerge asis", portage will try to emerge the latest version (asis-3.4.6.2006 at the moment) and this will fail if you have another gnat active. Therefore, to get the right version installed a somewhat more cumbersome syntax has to be used, namely: emerge =dev-ada/asis-x.y.z[.v] i.e. explicitly specifying the required version. Again, sorry about this, but this seems to be the easiest way out. Oh, last, but not least. The gnat-gpl-3.4.{5,6}.1 packages got renamed gnat-gpl-3.4.{5,6}.{2005,2006} respectively, as discussed above. This is exactly the same code as before, however I needed to force this upgrade in order to accommodate new ASIS ebuilds (and this was coming at the time of asis addition anyway, as a result of our discussion above). Now, with all these issues resolved and ASIS in the tree I am going to close this bug after I add asis-4.1.1. All further conceptual discussion should happen in the new (topical) bugs blocking #137268 (the tracker). George
(In reply to comment #114) > ASIS: > [...] > 2. Versioning: > I versioned asis ebuilds after the corresponding gnat versions. Thus, asis for > gnat-gcc-3.4.6 became asis-3.4.6 and asis for gnat-gpl-3.4.6.2006 became > asis-3.4.6.2006. In fact, there are only two of them now, so that list covers > them all, but I hope to also add asis-4.1.1. This looked like the most > apparent and straightforward versioning scheme, but if there are any ideas to > improve it I would like to hear them. What about asis-gpl and asis-gcc (and, eventually, asis-pro) to make clearer which version of gnat they belong to? I'm also questioning the wiseness of nameing them after the gnat version, as the README of ASIS explicitly say that there might be multiple distinct versions of ASIS for the same compiler version. I don't have a better sugestion right now, so I'd suppose versioning them after the compiler, with an added ".1" for posible later versions for the same compiler would do. > 3. ASIS SLOTs: > SLOTs partially followed gnat-xxx convention - that is to use GNATBRANCH or > the first two numbers of the matching gcc version. However here we do not have > "issued by FSF vs ACT" info in the package name, so that got added to SLOT. > Thus asis-3.4.6 has SLOT="FSF-3.4" and asis-3.4.6.2006 has SLOT="ACT-3.4". > Therefore they can coexist in parallel. If you made a separate asis package for each separate gnat package this would be a non-issue. > 5. Nonetheless this means that if you simply "emerge asis", portage will try > to emerge the latest version (asis-3.4.6.2006 at the moment) and this will > fail if you have another gnat active. Therefore, to get the right version > installed a somewhat more cumbersome syntax has to be used, namely: > emerge =dev-ada/asis-x.y.z[.v] > i.e. explicitly specifying the required version. > Again, sorry about this, but this seems to be the easiest way out. This would be (mostly) solved if you made asis-gpl and asis-gcc different packages.
(In reply to comment #115) > What about asis-gpl and asis-gcc (and, eventually, asis-pro) to make clearer > which version of gnat they belong to? Well, that would be the possibility as well. I just did not want to multiply the packages unnecessarily, but in this case it may be warranted, as it mirrors the gnat-xxx layout. On the other hand this is not that different, as at least gnat-gcc has two different SLOTs and this will be the case for gnat-gpl too, whenever ACT issues a gcc-4.x based version. I basically want to get some consensus here, I can change it to asis-gcc and asis-gpl if this is expected by more people. > I'm also questioning the wiseness of nameing them after the gnat version, as > the README of ASIS explicitly say that there might be multiple distinct > versions of ASIS for the same compiler version. Well, theoretically yes, realistically I am yet to see multiple ASISes fr the same gnat. At least ACT seems to be "devoted" to issuing updates of everything at once every once in a while. As for gnuada's asis (the one I used for asis-3.4.6) - there are only 3 versions as of now and the future development is not very clear. There is one marked "4.0.0" and I wonder if I will be able to use it for gnat-gcc-4.1.1. All of them can be bent to some extent to build with a slightly different gnat version (although I doubt that one can cross the change in major number). However the end story is that in order for asis to function properly it has to closely interact with gnat, and the easiest way to endure this is to force that 1:1 correspondece in used version and also by installing asis "extensions" along with the gnat components. While it should be possible to e.g. use different gnat files provided in asis distribution (for example the asis-3.4.6 is really a 3.4.4 version from gnuada which had gnat-3.4.0 and -3.4.4 subdirs which, in fact, only differed in a version string) for the same version of asis/gnat, this would require introducing a lot more complexity and confusion (we will need to decide how we will select the (sub-)version used, whether we want to allow multiple asis'es for the same gnat, etc) for a very little benefit. To rephrase. ASIS really seems to be en extension of gnat, thus I think versioning it after the corresponding gnat is the most rational thing to do. The end result is user has the same interface (tied to the major gnat version anyway) and the same tools, all of which depend strongly on the installed gnat and, as long as it builds, not as much on asis source used (which, from what I've seen, differ very little within minor version changes).. > > 3. ASIS SLOTs: [skipped] > If you made a separate asis package for each separate gnat package this would > be a non-issue. SLOTs will still be there, like for gnat itself, we will just let go the ACT- or FSF- part. > > 5. Nonetheless this means that if you simply "emerge asis", portage will [skipped] > This would be (mostly) solved if you made asis-gpl and asis-gcc different > packages. Only for 3.4.6.2006 vs 3.4.6, will not change this for e.g. 3.4.6 vs 4.1.1, exactly like we have it for gnat. To summarize: I am Ok with either keeping asis versions as they are or splitting asis into asis-gcc and asis-gpl (but that won't differ that much for SLOTting in the end). I would like to hear more opinions on this matter - what people tend to like more. George
(In reply to comment #116) > > To summarize: > I am Ok with either keeping asis versions as they are or splitting asis into > asis-gcc and asis-gpl (but that won't differ that much for SLOTting in the > end). I would like to hear more opinions on this matter - what people tend to > like more. > > George > I'm about to leave for a two weeks vacation, so just a brief reply without providing any reasoning: I'd prefer to see splitted versions as asis-gcc and asis-gpl. fabio
asis has been split and corresponding versions have been issued for all compilers that are in the tree. In fact this happened a few month ago already, so that I just removed legacy dev-ada/asis. Next on the list is removing the rest of masked old style packages and then final mask and removal of old style gnats. George
So, I skimmed this bug, and as far as I can tell, it should be resolved. The ebuilds are in the tree now. Am I wrong?
Well, let toolchain know if you need us again...
(In reply to comment #120) > So, I skimmed this bug, and as far as I can tell, it should be resolved. The > ebuilds are in the tree now. Am I wrong? Well, yea, I can't remember now why I still kept this one open. Looking at the mentioned issues it is resolved, so I'll close it now. George
