Please find attached gnat.tar.gz containing: ---- gnat/ChangeLog gnat/gnat-3.14p.ebuild gnat/gnat-3.15p.ebuild gnat/files/digest-gnat-3.14p gnat/files/digest-gnat-3.15p ---- I suggest sys-devel/ as root for gnat: /sys-devel/gnat Please note that both packages most likely will break gcc builds if Ada is included as language. I'm in the process of making a patch for gcc-3.2.1 to allow compilation of gcc with Ada language support (only for gnat-3.14p - gnat-3.15p does not seem gcc-compliant for some reason).
Created attachment 6911 [details] The missing ebuild files from first post. Embarrassing, I forgot to attach the file on the first post... Well, here it is. Best regards Per
Bug 11204 Ada language support for gcc-3.2-r4 Already covers the modifications to the gcc ebuild for Gnat Ada. There is a patch for gcc 3.2.1 on 11204 as well.
Yes, I understand, but I think a seperate gnat package should be included in Gentoo for completeness: 1) Some Ada programmers prefere to work with validated Ada compilers, and as far as I know, gnat is validated, gcc with Ada support is not by itself validated. I believe gnat is a validated combination of gcc frontend, backend and libraries. 2) This gnat package may simplify the patch applied to the gcc-ebuild. I've made and posted the gcc-ebuild suggestion on http://bugs.gentoo.org/show_bug.cgi?id=13113 - But no comments so far. It seems to me that the Bug 11204 gcc-patch is *significant* - I do not know wether that ebuild-patch will be hard to maintain though... I believe my gcc-patch is somewhat more "clean", but I would like some comments :-)
The problem with Ada support in the gcc 3-branch is that it is buggy. It has problems with miscalculations when using floating point numbers and the timers can cause constraint errors. I would suggest that if you add support for ada in gcc 3 make sure it is still possible to install the gcc version (2.8.1) that comes with gnat 3.15p. From what I've heard ACT will continue to distribute new versions of gnat even though gcc has merged alot of the new code. They are currently working on fixing the problems with gcc 3, be patient or end up ruining a great language by installing a broken compiler. If you decide to install ada support in gcc 3, make sure you use 3.3 and not 3.2. There was a rather large patch sent in a couple of weeks back that fixed a ton of bugs and afaik it will not be backported to gcc 3.2 (as I guess 3.3 will be released soon). (It is still very buggy though).
Why do you install the binary distribution? It is intended to be used to bootstrap the source distribution and the standard is to install gnat's gcc as gnatgcc or adagcc so that it won't interfere with the system gcc. I'd say that this ebuild is unfinished.
Created attachment 11363 [details] Proper GNAT 3.15p ebuild This is a proper gnat 3.15p ebuild. dev-lang/gnat suggested.
I created a proper gnat 3.15p ebuild. It uses the binary for bootstrapping and building a proper version of the compiler. gcc is installed as adagcc and gcov as adagcov, it will not interfere with your existing gcc. I suggest putting it in dev-lang/gnat, why Karl wanted to place it in sys-devel/gnat is beyond me. As soon as this gets into portage I will submit some nice support ebuilds such as CORBA and OpenGL support.
Won't be able to fix this anytime soon, I'm afraid.
Created attachment 11448 [details] dev-ada/gnat-3.15p-r1 I updated it so that it installs support for FSU threads. This is necessary for proper Annex D support. The default is still to use native threads though. The ebuild mentions how to switch to FSU threads.
Oh, and I switched the name from adagcc/adagcov to gnatgcc and gnatgcov to make it a bit more clear what compiler it is. FreeBSD named it adagcc but I think I've seen autoconf search for gnatgcc, so I think gnatgcc is more official.
Created attachment 12129 [details] dev-ada/gnat-3.15p.ebuild Fixed some minor compilation bugs. Renamed to gnat-3.15p.ebuild, no point in having -r1 since it isn't in portage yet anyway.
Created attachment 12130 [details] dev-ada/gnat-3.14p.ebuild I also put together this 3.14p ebuild. To my knowledge there is only one reason to keep 3.14p around and that is if you intend to use rtlgnat (which is a gnat runtime for RTLinux), v0.1 only works with GNAT 3.14p. If these ebuilds are imported during my lifetime I will whip up an ebuild for a nice version of RTLinux (with preemption and stuff which isn't normally available in the free version) along with rtlgnat.
Created attachment 12674 [details] dev-ada/gnat-3.15p Some friends found some bugs...
Created attachment 12675 [details] dev-ada/gnat-3.14p Some friends found some bugs...
Hi guys. Glad to see such activity on ada! David, Per: thanks a lot for all your work. I'll try to get gnat in soon. Of course I will need a lot of help since realistically I am only starting on ada ;). Just to make sure I got it all right here is my understanding of situation: There are two "major" ada mplementations for x86/Linux, gnat and its branch in gcc. gnat is a validated "reference" implementation, while gcc-3.x includes experimental, lagging (and not properly working at present) offshot of gnat based around gcc-3. As such I would say my top priority would be to get gnat in and working. Then it would be nice to determine how many ada-related packages we have at the moment (I have two bugs assigned to me already, ##11290, 11292) and how many can we expect to come. I guess new category dev-ada will be in order (gnat itself goes into dev-lang btw), at least if the list I saw in #11204 is anywhere near real. The next step would be to decide whether to proceed with additional packages first or go for ada support in gcc and creating virtuals where appropriate. I think it might be better to get ada compilers done first (with all necessary eclasses), so that we won't need to adjust dependant ebuilds afterwards. Another issue: new category will require active maintainer. I would appreciate any possible help here, as I am already overseeing pretty much all "alternative" languages and that in addition to app-sci. David, I seems to remember you were volonteering to maintain ada and related stuff, lets work on it ;). We can model ada support in portage after what has been done for haskell. Not everything is done yet, but the situation is quite similar - alternative compilers, few packages that can be compiled by either of two (out of ~4 total, 3 compilers and translator). George
Hi, I'm working on adding ada-stuff to portage. I was told I could maintain it if I wanted so I've started working on ebuilds, though I heard I needed at least 10 ebuilds to warrant a dev-ada dir so I have yet not released anything. My work in progress can be downloaded here: http://rift.ath.cx/~avatar/gentoo-ada.tar.bz2 Some of the dirs don't have a ChangeLog yet =). So far the following packages works (for me): gnat-3.14p gnat-3.15p GtkAda-2.0.0 and xmlada-0.7.1 Florist does not work at all, I have contacted the author of that ebuild about it but he has not yet replied. I'm working on a couple of new ebuilds that are not in that archive yet.
Personally I think we should avoid ada in gcc at is more of an experimental version, the gcc folks don't seem to care much about stability in ada so I figured they would continue to keep it experimental even after gnat 5 is released. ACT recently opened their cvs to the public so it is possible to create a more stable release of gnat 5 (which is what they have merged parts of into gcc) although so far I've been unsuccessfull in compiling it (and it is still buggy).
David: Few quick remarks on ebuilds, I am downloading sources now, so more stuff may follow when I test them. -first the 3.14p: 1. Could you please attach the license file? 2. Is there any downside (other than less optimization) to having binary gnat installation in addition to the bootstrapped one? We might have gnat and gnat-bin packages. In addition to saving some time to some users (not very much in this case I would guess, but still) this might simplify the boostrapped ebuilds. The -bin package would have to be installed under /opt in order to play nicely with prelink and comply with FHS. 3. It is best to use ${P}, ${PN}, ${PV} as much as possible in ebuilds (perheaps only omitting HOMEPAGE) instead of clear-text. Quite often this simplifies updates and further processing. George
1. I just noticed it is called GMGPL (GNAT Modified GNU Public Licence) so the LICENSE="GNAT" should be changed. All software I've seen released under this license is always distributed with a standard GPL v2 doc for some reason. I have not yet found a copy of an actual GMGPL license file on the net. What ACT states is that GMGPL means the application is released under the GPL but you can still instantiate and use generics from their libraries without having to adopt to GPL yourself. (Similar to, but not exactly like, LGPL) 2. The biggest difference is that the binary release uses FSU threads by default which is a user-mode threading library which I _think_ is created by SCO ( ;) ) If you compile it you get native linux threads as the default. Linux threads are not advanced enough to support the entire Annex D (the Ada real-time specification), FSU does this. If you install the source ebuild you can switch to fsu by issuing --RTS=fsu. (There is also support coming for RTLinux real soon, there is a 0.1 release, but it only works with gnat 3.14p and it is messy,... so I need to convince someone (perhaps myself) to add an RTLinux/Free ebuild as well ;)... Personally I don't see any problems in providing a binary package as well. If you don't know the difference between kernel-mode or user-mode threads or why you would want Annex D I don't think you will care which version you install. 3. Yes, I know, I try to use them as much as possible, although I think the issue with the bootstrap compilers make it difficult to simply bump the revision of the gnat ebuilds. The gnat standard is that the compiler bootstraps with the binary of the previous version of the compiler =( (which made it hell to compile gcc 3.3-cvs with gnat (before I knew how broken it was) since I first had to compile gcc 3.2 with gnat 3.15 then gcc 3.3 with gcc 3.2 ;) Also note that I did not do all of the ebuilds in the tarball I posted a link to, some of them are from bugzilla and I've only done some quick cleaning (if there was a need for it).
Hi David. I have been testing gnat-3.14p. It seems to work ok in general, but I am getting a sandbox violation, which is a no-no. Some stray mkdir /usr/local/include tries to get through to the live system: if [ -d /usr/local/include ] ; then true ; else mkdir /usr/local/include ; chmod a+rx /usr/local/include ; fi ^[[31;01mACCESS DENIED^[[0m mkdir: /usr/local/include Even though this mkdir fails the error gets ignored by the Makefile. Should be easy to fix, although --includedir setting is ignored by ./configure. Simple sed should do the trick... In order to test for sandbox violations you need to have it enabled - add sandbox (and also userpriv and usersandbox for a good measure) to FEATURES in /etc/make.conf. Also good idea is to run ebuilds trough lintool (its a separate ebuild syntaxis control tool, that you can emerge). Its not actively supported at present, so some warnings should be ignored (its functionality will eventually be integrated into repoman), but it nontheless provides few usefull checks. Since I did few cosmetic modifications to ebuild I am attaching the modified version below. Please use it for further adjustments. George
Created attachment 13289 [details] cleaned-up gnat-3.14p.ebuild
Hi David > ------- Additional Comments From dholm@telia.com 2003-14-06 14:59 EST > ------- 1. I just noticed it is called GMGPL (GNAT Modified GNU Public > Licence) so the LICENSE="GNAT" should be changed. All software I've seen > released under this license is always distributed with a standard GPL v2 > doc for some reason. I have not yet found a copy of an actual GMGPL license > file on the net. What ACT states is that GMGPL means the application is I could not easily find it either, but I only spent few minuts on this, so I was hoping is it available off the web, just at not very apparent place. Since this is not really LGPL we need to include the license file into portage (it will go under licenses/). Perheaps I will need to email gnat authors asking for the text of license. Do you know what email would be the best to use? > (perhaps myself) to add an RTLinux/Free ebuild as well ;)... Personally I > don't see any problems in providing a binary package as well. If you don't > know the difference between kernel-mode or user-mode threads or why you > would want Annex D I don't think you will care which version you install. Will the presence of gnat-bin package change the way source-based one is bootstrapped? If yes, then perheaps we need to add gnat-bin first or at least simultaneously with (adjusted) gnat ebuild[s]. Otherwise we should be able to get these two ebuild done first and then proceed to other stuff.. Part 3 of your responce sound suggestive of the latter - that using external -bin package to bootstrap gnat does not make life easier. Is this really so? Also, I had to adjust SRC_URI for ${P}-scr.tar.gz in gnat-3.15p.ebuild. It was originally pointing to some strange server which I had problems accessing. I changed it to the one used pretty-much throughout: http://gd.tuwien.ac.at/languages/ada/gnat/3.15p/. It contains gnat-3.15p-src.tgz and works perfectly on me here. Will get to testing 3.15 now.. George
> Hi David > > I could not easily find it either, but I only spent few minuts on this, so I was hoping is it > available off the web, just at not very apparent place. Since this is not really LGPL we need > to include the license file into portage (it will go under licenses/). Perheaps I will need to > email gnat authors asking for the text of license. Do you know what email would be the best to > use? Hmm, maybe sales@gnat.com. I can post to comp.lang.ada and see if anyone there knows. > > Will the presence of gnat-bin package change the way source-based one is bootstrapped? If yes, > then perheaps we need to add gnat-bin first or at least simultaneously with (adjusted) gnat > ebuild[s]. Otherwise we should be able to get these two ebuild done first and then proceed to > other stuff.. Part 3 of your responce sound suggestive of the latter - that using external > -bin package to bootstrap gnat does not make life easier. Is this really so? During bootstrapping the bootstrap compiler is placed first in the path so I doubt that it will affect compilation of gnat. Using gnat-bin to bootstrap gnat could get messy though if you for instance had gnat-bin-3.15p installed and wanted to compile gnat-3.14p, so there is still a need for downloading a bootstrap compiler with the source. It is possible I guess to detect if you have gnat-bin installed and only download a bootstrap compiler if it suspects it can't bootstrap with that particular version of gnat. I'm going to investigate this sandbox violation you mentioned. Though I do not get this myself with gnat-3.15p, very odd =(. (I have sandbox, usersandbox, userpriv and ccache enabled) I will update the SRC_URIs to point to gd.tuwien.ac.at as well. I'll get back in a while with updated ebuilds. //David
Hmm, ok, the only violation is that it tries to create /usr/local/include, it doesn't try to install anything there. I'm working on tracking this down, seems they've hid by using a variable instead of explicitly using /usr/local, I wonder why it doesn't conform to --prefix =(. I've asked around regarding the license and there is no document describing GMGPL, this was the most informative of the answers from Preben Randhol <randhol+abuse@pvv.org>: The point is that you just modify the GPL as such: ---------------------------------------------------------------------------- -- <Your program name> -- -- Copyright (C) <year(s)> -- -- <Copyright holder(s)> -- -- License: Gnat Modified GNU Public License -- -- -- -- This program is free software; you can redistribute it and/or -- -- modify it under the terms of the GNU General Public License as -- -- published by the Free Software Foundation; either version 2 of the -- -- License, or (at your option) any later version. -- -- -- -- This program is distributed in the hope that it will be useful, -- -- but WITHOUT ANY WARRANTY; without even the implied warranty of -- -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -- -- General Public License for more details. -- -- -- -- You should have received a copy of the GNU General Public License -- -- along with this program; if not, write to the Free Software -- -- Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA -- -- 02111-1307, USA. -- -- -- -- 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. -- -- -- ---------------------------------------------------------------------------- The last paragraph is the one that seperates GMGPL from GPL. But you might also want to look at: ... either version 2 of the License, or (at your option) any later version. You can remove the ", or (at your option) any later version." if you don't feel comfortable with it. Linux has a similar license: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. Linus Torvalds Preben
Created attachment 13306 [details] dev-ada/gnat-3.14p Hopefully all bugs should have been cleaned out by now.
Created attachment 13307 [details] dev-ada/gnat-3.15p and the same modifications to 3.15p.
Created attachment 13308 [details] licenses/GMGPL And of course I forgot to change the LICENSE from GNAT to GMGPL in the last two gnat ebuilds =(. The ones located in the file at http://rift.ath.cx/~avatar/gentoo-ada.tar.bz2 are correct though. I'm not submitting new ebuilds unless you want me to :).
Created attachment 13320 [details] dev-ada/gnat-3.14p The symbolic links to the default runtime weren't properly created, fixed now (along with the LICENSE)
Created attachment 13324 [details] dev-ada/gnat-3.15p
Hi David. Thanks for an update. I have processed and committed the ebuilds, please test. Few comments: in src_install: 1. you do cp -r ada{lib,include} rts-native and then "old" locations get overwritten when rts-fsu gets installed. Isn't it safer to mv ada{lib,include} rts-native, like you do then with fsu version? (I left it your way for now). 2. make install-* was installing libgnarl.so and libgnat.so which appeared to be broken symlinks. Well, considering that ada{lib,include} get symlinked to proper library later they were becoming circular symlinks. Since I could not find anything proper I could point them at, I removed these symlinks (the "rm -f rts-fsu/adalib/{libgnarl.so,libgnat.so}" lines). BTW, along the way there were few (ignored) "not found" messages about some .so files (these two included). Should something be done about them? 3. The ln -s lines: 3.14p had them in src_install and 3.15p had them in pkg_postinst. 1. I moved them under src_install - they get "registered" in this way and consecuently removed upon unmerge.. 2. The were pointing into ${D}/... location, which is only temporary and gets cleaned. They should really have been dosym's, as they are in the committed version. Also, I am still a bit confused about licensing. Does GMGPL apply to the whole gnat or to the "standard library" only? Though the way GMGPL is worded it should not matter much.. George
1. Yes, it's an old and bad habit I have of using cp -R instead of mv =(. 2. They are the runtime libraries, as long as people don't want to link dynamically with the runtime they shouldn't be needed, unless there are some binary ada-apps floating around that are linked dynamically (I've never seen one). Strange that they didn't get compiled though. Something to look into for -r1 perhaps? ;) 3. Hmm, I never got dosym to work for me. I will check the ebuilds to see how you did them. Might've been that I initially messed up the meaning of ${D}, I thought it would point into /usr if I used instinto /usr, I later on figured out how it worked though but I guess I forgot to fix all the code. Well, the compiler itself is GPL-v2 and the library is GMGPL. Basically it's just a workaround they initally created so that they could release the compiler under the GPL without scaring off companies. It would not make sense to make the compiler GMGPL as nothing in the license applies to it, but most opensource apps apply GMGPL to all their code these days anyways. Probably because it's so difficult to find it :) and the statements in the various FAQs is that it is a Lesser LGPL ;).
Created attachment 13443 [details] eclass/ada.eclass
Created attachment 14133 [details] flag-o-matized eclass Hi David. First thanks for the eclass. I presume we should use this one, as tied to gnat, rather than the one from #11204. I started processing the ASIS ebuild and stubmbled upon gnat not liking some of my C[XX]FLAGS. Now, I usually emerge stuff with somewhat aggressive collection of flags for the sake of catching some common overoptimization problems. Apparently since gnat is based around quite old version of gcc, the backend does not know about some of the newer flags. Correspondingly they should be stripped via filter-flags (provided by flag-o-matic.eclass). I see you already strip some flags and correct some others in eclass. I added few more flags to be stripped and used flag-o-matic eclass and filter-flags functions instead of explicit bash constructs in order to "gentooise" the eclass. Please check if I did not break anything. Now, the naming of eclass: ada.eclass sounds quite broad, while in reality this eclass delas with gnat-based stuff mostly. If we are going to have more ada compilers at a later time (and not even just newer gcc branch, gentoo has ability to provide ebuilds for commercial apps nicely (users take care of necessary registration, etc, ebuilds just ease installation of the stuff and make sure it plays along well with the rest of the system)) I expect the need for more ada-related eclasses. What about naming this one gnat.eclass then? If at a later point we find it appropriate, we can have some common stuff provided by ada.eclass, which will in turn be inherited by gnat.eclass and some-other-compiler.eclass.. Please note, I named the modified eclass as gnat.eclass in order to avoid any confusion for now. The choice of the final name though is pretty much up to you. George
Hi David. I have been playing with gnat lately, and it seems to function fine. Just one thing - there is absolutely no documentation installed. This should be fixed (and fully warrants the -r1 revision). I saw gnat_rm and gnat_ug provided in the sources and some (looks like very basic) examples. Is there anything else? Also, I did few small touches to gnat.eclass, which is committed now. I am creating the dev-ada catgory. George
Created attachment 14440 [details] fixed gnat.eclass
I agree with you that the eclass should be called gnat and not ada. I also added -m3dnow to the strip-flags =). Probably more of them lurking in gcc, I didn't see this in gcc.eclass which I found odd since it has a function that modifies CFLAGS for gcc 2. Regarding the docs there is a separate 9mb compressed file containing all the docs. I will work it into an -r1 ebuild as soon as possible (it also contains info files etc). I have just removed all ada-stuff on my drive and I will start emerging the ebuilds that are already in portage asap (meaning after I've run my week old -DU world ;). Hopefully I will stumble upon the bugs you have mentioned in some of the ebuilds (adasockets for instance).
Hi, I suggest to and some fliter-flags in gnat.eclass : -msse2 -frerun-loop-opt filter-flags -falign-jumps=4 -falign-loops=4 Alexis
Created attachment 14904 [details] dev-ada/gnat-3.14p-r1 Here is the -r1 of gnat 3.14p as promised. Installs full documentation and examples along with some cleanups made to the ebuild. One tiny problem though. I fixed the SLOT, it was set to GNAT-3.14P and GNAT-3.15P because I initially intended to write a gcc-config like system which I have now postponed. Since you can't have both 3.14p and 3.15p installed I changed them back to "0" so now when you upgrade to -r1 the old version won't unmerge. Is there a simple solution to this problem?
Created attachment 14905 [details] dev-ada/gnat-3.15p-r1
Hi guys. Alexis: thanks for addition to filter-flags, added them to eclass. I am sure more additions are coming :)! David: Thanks for the update! It looks good, however there are few questions I would like to go through before commiting this one: 1. I see you install examples under /usr/share/${P}, while normally /usr/share/${PN} is used for the supplementary stuff. Was this a part of the gnat-config stuf you had in mind or why did you decide to use the versioned directory? BTW, as I can see many people install examples under docs, while other do it just under /usr/share/${PN}. I guess this is really a matter of taste, however this might be a good way out of the above question, considering that /usr/share/${P} only contains examples now :). 2. info files. In addition to gnat specific stuff I see gcc and gdb info files being installed. While gcc info files are "protected" with the new -config system by being installed under /usr/share/gcc-data/${CCHOST}/${MY_PV}/info, the gdb*.info files reside in standard location and will be overwritten. Do these contain anything different? Looks like they are for the same 5.3 version, as I have installed at the moment (separately). Also it seems kind of strange, that the ebuild installs gdb info files but not the gdb itself. If these are merely the bundled naitive gdb files we can just remove them I guess. What do you think? There is also a ps file for gdb. This might be a separate story if there is some gnat specific information. In this case it can safely go into gnat doc dir (and if gdb info files do contain gnat specific stuff they can be renamed into gnat-gdb for example..). Other than that the ebuild seems to be clean and ready to go.. >One tiny problem though. I fixed the SLOT, it was set to GNAT-3.14P and >GNAT-3.15P because I initially intended to write a gcc-config like system which >I have now postponed. Since you can't have both 3.14p and 3.15p installed I >changed them back to "0" so now when you upgrade to -r1 the old version won't >unmerge. Is there a simple solution to this problem? Changing the SLOT back to "0" in both version of gnat already in portage? I will test that after the ebuild is finalized by changing SLOT's in these ebuilds and emerging a new version. Note, if you want to test this yourself you might need to run "emerge regen" in order to upate portage cache, before you will see the cleanup effect. George
Yea, regarding placing gnat in dev-ada: the compilers/translators, i.e. the languages themselves are suposed to be placed in dev-lang and all the suport stuff goes into dev-langname category if there is anought to varrant new category.. Well, this is not really a strict policy, I would rather say this became so evolutionally without being strictly written down in some kind of regulation. There are few exceptions, most notably some lisp stuff lives in dev-lsip. However most of everythoing else follows this pattern. I guess we can do either way, but I think that more people would expect to find gnat under dev-lang.. George
1. Oops. I only checked the layout of /usr/share/doc where ${P} is used. I guess I just assumed /usr/share looked the same ;). It doesn't matter at all what you call the dir so ${PN} works just as well. 2. Big mistake on my part. I found a few other small things I could change. I will submit two new -r1s soon. Regarding dev-lang I agree that most users would look there for it.
Created attachment 14957 [details] dev-ada/gnat-3.14p-r1
Created attachment 14958 [details] dev-ada/gnat-3.15p-r1
I think I've fixed all the problems and I also took care of some other minor stuff I found afterwards. Now it will install the static libraries (libgnat/libgnarl) as well. Also, someone fucked up with the new gcc-3.2.3-r2 ebuild. Please check: http://bugs.gentoo.org/show_bug.cgi?id=25178 I hope I don't have to go through the entire no-ada-in-gcc argument again =). Bug #11290 should be ready for commit, could you please test it? It's the last missing piece from having the base GNAE system.
Ok, tested and committed, looking good! Please test (the commit). I think soon we can start moving stuff into stable. Although that gcc bug has to be fixed first + it would be nice to get some testing by more people.. George
Created attachment 15894 [details] Interfaces.C.To_Ada doesn't work I installed dev-lang/gnat-3.15p-r1. It seems it doesn't work for me. I compiled and ran test.adb and got result '' instead 'Hello' expected. Could you check? Maxim Reznik
Please direct any testing to the gnat-3.15p-r2 bugreport. At the moment there are no known bugs in -r2.
The latest issue seems to have been resolved in -r3. Reclosing the bug. George
