The output goes: >>> emerge (1 of 1) dev-lang/gnat-3.41 to / >>> md5 src_uri ;-) gcc-core-3.4.1.tar.bz2 >>> md5 src_uri ;-) gcc-ada-3.4.1.tar.bz2 >>> Unpacking source... >>> Unpacking gcc-core-3.4.1.tar.bz2 to /var/tmp/portage/gnat-3.41/work >>> Unpacking gcc-ada-3.4.1.tar.bz2 to /var/tmp/portage/gnat-3.41/work >>> Source unpacked. creating cache ./config.cache checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking build system type... x86_64-unknown-linux-gnu checking for a BSD compatible install... /bin/install -c cc1: error: unrecognised debug output level "natpgn" *** The command '/bin/gcc -o conftest -O -gnatpgn conftest.c' failed. *** You must set the environment variable CC to a working compiler. !!! ERROR: dev-lang/gnat-3.41 failed. !!! Function src_compile, Line 78, Exitcode 1 !!! configure failed Setting CC=/usr/bin/gcc makes no difference. Reproducible: Always Steps to Reproduce: 1. Add the amd64 keywords to the gnat-3.41 ebuild 2. emerge gnat Portage 2.0.50-r11 (gcc34-2004.2, gcc-3.4.1, glibc-2.3.4.20040619-r1, 2.6.8-gent oo-r4) ================================================================= System uname: 2.6.8-gentoo-r4 x86_64 4 Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe -march=k8" CHOST="x86_64-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2 /share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/ config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -march=k8" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/dis tributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa amd64 apm arts avi berkdb bidi cdr crypt dvd dvdr encode esd faad fo omaticdb gdbm gif gnome gpm gtk gtk2 imlib java jpeg libg++ libwww matroska mikm od motif mozilla mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png pytho n quicktime readline sdl slang spell ssl tcpd tiff truetype wxwindows xml2 xmms xv zlib"
AMD64 is not supported and I don't have access to that architecture. GNAT requires an existing bootstrap compiler to compile. If you can provide me with an AMD64-binary of GNAT I might be able to port the ebuild.
Would (gnat-3.4 packaged as) a .deb help? If you need any testing, just ask!
Can you please point a location to a binary (preferably tar.gz) ada enabled gcc for amd64? I shortly looked for it before my trip, but didn't have much time to find anything usefull :( (saw mostly x86 binaries). That would be the best, I'll take it from there - I am on amd64 now. Otherwise we will have to bootstrap it off x86 or combine the deb you mentioned with gcc to get the result. David: I know it was decided to drop in-gcc ada some time ago, but the one in gcc-3.5 seems to be decent and is becoming almost official. So, my idea was to start the process while we are still on 3.4. Or do you have any better idea? PS. Sorry for being mostly silent lately, being busy graduating and looking for new position, but I should get more time now for a few month at least.. George
I haven't been able to find any tarballs, but gnat-3.4 is in ubuntus archive at http://archive.ubuntu.com/ubuntu/pool/universe/g/gcc-3.4/ And it declares the following dependencies: gcc-3.4-base, libc6 (>= 2.3.2.ds1-4), libgnat-3.4 (>= 3.4.1-3), gcc-3.4 (>= 3.4.2-2ubuntu1), gcc-3.4 (<< 3.4.3) Some of which are here: http://archive.ubuntu.com/ubuntu/pool/main/g/gcc-3.4/ or here: http://archive.ubuntu.com/ubuntu/pool/main/g/glibc/ I hope they are of some use!
Created attachment 42286 [details] a first shot at amd64 version A short update. I spent two evenings looking into gcc and gnat building. Made some progress, but didn't get successfull build yet. I am attaching my version of ebuild, in case somebody will want to give it a shot and see if I missed something (Tor ;)). The necessary amd64 binary I put up on dev.gentoo org, here: http://dev.gentoo.org/~george/gnat-3.4.2-amd64.tar.bz2 just put it into distfiles. This is a combination of a few debian packages to form a functional gcc/gnat. Unfortunately not fully functional yet. So far I am getting as far as this: mkdir -p ada/bldtools cp -p /var/tmp/portage/gnat-3.42/work/gcc-3.4.2/gcc/ada/sinfo.ads /var/tmp/portage/gnat-3.42/work/gcc-3.4.2/gcc/ada/nmake.adt /var/tmp/portage/gnat-3.42/work/gcc-3.4.2/gcc/ada/xnmake.adb ada/bldtools (cd ada/bldtools; gnatmake -q xnmake ; ./xnmake -b ../nmake.adb ) gcc -c -g -gnatpg -gnata -I- -I. -Iada -I/var/tmp/portage/gnat-3.42/work/gcc-3.4.2/gcc/ada /var/tmp/portage/gnat-3.42/work/gcc-3.4.2/gcc/ada/comperr.adb -o ada/comperr.o gcc -c -g -gnatpg -gnata -I- -I. -Iada -I/var/tmp/portage/gnat-3.42/work/gcc-3.4.2/gcc/ada /var/tmp/portage/gnat-3.42/work/gcc-3.4.2/gcc/ada/csets.adb -o ada/csets.o /bin/sh: line 1: 7881 Segmentation fault ./xnmake -b ../nmake.adb make[2]: *** [ada/nmake.adb] Error 139 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/gnat-3.42/work/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/var/tmp/portage/gnat-3.42/work/build/gcc' make: *** [bootstrap] Error 2 Segfault does not look too good :(. Also, for this ebuild you will have to copy libgnat-3.4.so.1 from that tar.bz2 into your /usr/lib. I haven't found the way so far to make gnatmake work otherwise :(. Also, looks like gnat on amd64 does not like -gnatpgn, at least the one by debian. Was it removed/deprecated in new gcc/gnat? (this is based on gcc-3.4). George
(I'm not entirely sure how to use unofficial ebuilds, but I think I'm doing it right) In order to digest the ebuild these are needed in /usr/portage/distfiles gnat-3.15p-i686-pc-redhat71-gnu-bin.tar.gz gnat-3.15p-powerpc-unknown-linux-gnu.tar.bz2 I'm attaching the std and err of the emerge.
Created attachment 42468 [details] Errors from emerge on 24:th of Octobre
Created attachment 42469 [details] Standard output from emerge on 24:th of Octobre
I checked out GCC from CVS on a Fedora Core 3 X86_64 box. I bootstrapped GCC 4.0.0 20050325 (prerelease) with full gnat/ada support using gnatgcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3) . I installed it to an alternate directory. (Not /usr). I copied it over to my gentoo amd64 box (a no multilib profile) and after a bit of mucking around was able to get the same bootstrap working on Gentoo. I had to symlink gnatgcc to gcc in the alternate bin directory, as some parts of the compile were using gcc rather than the CC or ADAC variable and were breaking as result. I put that alternate bin directory as the first one in executeable path in my build script. Since the gcc symlink is in the path first, the one in /usr/bin is not used. Now I need to make sure I can bootstrap on Gentoo amd64 using the gnatgcc I just bootstrapped on Gentoo amd64. I've not tried to make an ebuild yet for it.
Created attachment 54501 [details] gnatgcc (GCC) 4.0.0 20050325 (prerelease) bootstrap script for amd64
If anybody wants a binary snapshot of GNAT that runs on gentoo amd64, let me know what path you want it prefixed to, and I'll build one for you and send it to you.
Hi Dwight. Thanks a lot for your work. I'll look at the script and will see if I can go from that or I will need a binary as well. Unfortunately I am short on resources untill I start at new place (rl issues), but I'll try to get done at least with Ada :). George
The configure program compiles a C program as part of its tests; this uses the CFLAGS defined for the Ada compiler early in the ebuild file. This will fail on all architectures, whether there is a boostrap compiler or not. This should set ADAFLAGS instead, or nothing, since it uses -gnatpg -gnata by default, anyway. Therefore, proposed solution is to remove line 33, CFLAGS=.... I've reopened this on all architectures (#90685); suggest changing this bug to "gnat doesn't work on amd64" or some such.
Woohoo! 1. I finally got enough time to revisit the build (mostly due to the pressing need to develop some more analysis tools in near future for my data and I would absolutely hate to do them in C :)). 2. Got it actually working, so now we also have an amd64 port! Well, almost.. Based around the gcc-3.4.4, bootstrapped on ubuntu's binaries. Had to do some LD_LIBRARY_PATH tweaking locally. Along the way got that thing about -gnatpng fixed. As I said, this is based around gcc-3.4.4, so this is a new version. I cared to envelop amd64-specific changed into conditials, but testing is appreciated. The ebuild is in the tree but package-masked. David, this is probably for you to test and unmask (the new version), as I only have amd64 system running atm. However any extra test-reports are *greatly* appreciated and will shorten the time this beast stays masked.. There is one thing that is missing though and that is shared libs. The build would stop 90% of the time (and few times it actually finished, with principally the same code!) during the last command, that is make gnatlib-shared, complaining that it needs -fPIC.. I tried supplying this flag in many places, doing seds of a few hardwired flags (I left some of these attempts in, just commented out) but it just wouldn't pick it up :(. I am not sure whether this is specific to amd64 (-fPIC is acommon issue here) or is a feature of new gcc version (which likes to me more strict in every version), so I disabled the last make just in case. Any help is appreciated. David: as I remember you already dealt with shared libs, any pointers where I can force this flag? I'll leave the bug open for a while, in the hope of getting shared libs fixed.. George
Ok, shared libs have been resolved. It actually builds now and seems to work fine. So, please test the 3.44-r1 version (its p-masked for now, please unmask locally). I would really really like to unmask it soon... Additionally, I upgraded dev-ada/asis to (also) 3.44 version, so please give it some testing as well.. The asis-3.15 can be made to build with gnat-3.4x, but it does not really work then.. (so I restricted its dependency on appropriate gnat version). Oh, asis has a new website, corrected in new ebuild, and uses sourceforge for distribution. So, you see now why I would really really like to hear testing reports on gnat-3.44? (David: why the 3.4x series went with this versioning and not 3.4.x, like gcc uses?) George
I guess I'll keep this bug as a tracker for amd64 "porting". Gtkada works fine, no changes (well, aside adding proper keyword) are necessary.. George
xmlada works as well. Side note: the ebuild should really use econf with appropriate use_with or use_enable's.. George
Good news for x86 - I repackaged bootstrap compiler for gnat-3.44. Should now handle various gcc-3 flags well. This is in gnat-3.44-r2, also masked. As usual I would really really like some test reports.. Thomas (J. Moore): this is primarily for you, as you can guess I got tired of your complaints ;). David (Holm): haven't seen you for a while.. And as you can see the ada stuff needs some care. How is it going with ppc lately? Do you think you still have time to handle both? As for me, I am really sidetracking now - there is much stuff I should be doing for Scientific Gentoo, but there at least something is going on, so I took time to go over "my other projects" :). I guess I'll need to look into getting more people onboard helping with ada then. I am thinking to add a request to that page we have and even post something in GWN in a week or two (or sooner if I hear from you and this is what you want as well). What do you think? George
Ok, last outstanding issue with new gnat (3.44) has been resolved on amd64, asis ported (and some spotted problems fixed) and all relevant sources have propagated to mirrors. So, finally, gnat-3.44-r2 and asis-3.44 were unmasked. Please enjoy and report any problems.. Right now both have only ~amd64 in KEYWORDS, as I did not hear any test reports on x86 so far. It is also quite likely that it will not work in its present form on ppc and will require some modifications.. Another issue: Yesterday I had a chat with David Holm and, besides organizational questions, we brought up the necessity to slot gnat and dev-ada. I looked into the possibility of slotting gnat.eclass and I am glad to report that it is totally possible and is quite straightforward in fact. I'll post a first shot at the slotted eclass next. I was actually thinking about delaying unmasking gnat and asis untill we do slotting, but I realized, that this will probably take some work and time. Proper slotting involves muc more than just putting some strings into SLOT var - we need to make gnat and all the libs install into different location, according to SLOT, preferably putting most of this stuff into eclass. We will also need to produce a module for eselect (or a gnat-config script, but I think this is deprecated now), basically to follow what has been done for gcc or blas/lapack or similar.. The payoff of course is the possibility to have multiple versions (with different backends) to coexist and play nicely together. In fact just making it all work is a nice reason :), as without slotting we are just inviting many incompatibility problems between libs and it will be totally impossible to manage quite soon, when gcc-4.1 comes around (AFAICT we are skipping on 4.0 gentoo-wide). Ok, this is it for organizational stuff. Just one thing, did I mention that we need testing for gnat/asis-3.44 on x86? George
Created attachment 75132 [details] a first shot at slotted eclass As mentioned above, a first shot at slotting gnat.eclass. Seems to work with asis and gtkada.. However it is more complex than that - installation of gnat and all libs will have to be adjusted to install stuff into SLOT-aware locations + env vars will have to be set appropriately. Switching on active compiler should be done via eselect module (preferably) or gnat-config (deprecated, but falls in line with gcc). Also, what to do with libs that need a slot for themselves, like gtkada for example? George
ok; here's how I got on with gnat-3.4.4-r1 on x86 :) I run a hardened PaX system which makes things a little more interesting. initially bombed out becuase the bootstrap compiler didn't like '-march=pentium3', so I just did: CFLAGS="-O2 -pipe" emerge =dev-lang/gnat-3.44-r1 for now. Unfortunately this means -march=pentium3 is lost from stage2/3 as well I think. Main gcc manages CFLAGS separately for each stage; it might be a good idea to steal tricks from toolchain.eclass to do the same if possible. I'll report back later on -r1; it's building now (see below for PaX stuff I had to tweak) but I don't expect any other difficulties as it's primarily the same as the 3.4.3 ebuilds. I did give -r2 a quick go, but that fell over in a heap in configure. I'll look into that tomorrow. PaX --- You may not be too interested in this part, but I include it for completeness. I've done this on previous gnat versions. First up, bombs when trying to run the bootstap gnat1 - this is due to PaX, which kills anything trying to execute stuff on the stack; this includes trampolines unless the executable is marked so that the PaX kernel should emulate them. Added: if [[ -x /sbin/chpax ]]; then /sbin/chpax -E ${GNATBOOTINST}/gnat1 \ || die "Failed to enable trampolines for ${GNATBOOTINST}/gnat1" fi immediately prior to the './doinstall' in the x86 bootstrap installation in src_unpack(). I also patched gcc/ada/Make-lang.in so that gnat1 will have the appropriate markings when built (needed to continue from stage 1 to stage 2); I'll attach the patch presently; however all it does is add '-Wl,-z,execstack' to the $(CC) line for the "gnat1$(exeext):" target. Non-Ada gcc doesn't need this because the non-Ada compilers don't use trampolines themselves.
Created attachment 75154 [details, diff] Modify Make-lang.in to build gnat1 with the emulate trampolines flag set (PaX)
Just to confirm - 3.4.4-r1 built without error (I didn't run the tests).
Thanks Kevin for testing! Well, I guess I could unmask then (to testing) the 3.44-r1 on x86. However I am trying atm to converge to common processing for both amd64 and x86, that is to make the -r2 work on x86 as well (now I have a working 32bit chroot, so I can test on x86 as well). On an upside this should allow you to use all the more specific march flags and many other, as that revision bootstraps off ada enabled gcc-3.4.4, while -r1 is bootstrapping off gnat-3.15 which is based on gcc-2.8.. However strangely, even though the gcc binary is supposed to be pretty much identical to amd64, the build stops at make gnatlib_and_tools claiming it does not know this target. Comparing the produced Makefile (on x86 to amd64) it looks like it does not enable ada at all! All this using identical code in ebuild.. The same configure command, the same everything. I must say I am quite confused. Will try to look again tomorrow, but if it resists I guess I'll have to proceed with -r1.. Thanks for the PaX stuff. I'll try to incorporate it, but as I am running a "normal" system I will have to rely on your testing if you want it in ;). On my side I can definitely make sure it does not break things on normal systems, but that's pretty much it in terms of testing I can do.. George
-r1 is unmasked, and I got a fix for the -r2 too. Tested fine on x86 and amd64. George
asis-3.44: added ~x86 to KEYWORDS.
George; I can confirm that 3.44-r2 builds fine here (x86 hardened), no trouble with the bootstrap compiler since it's much more recent. The only change I made to the ebuild was for PaX; added: if [[ -x /sbin/chpax ]]; then find ${GCC_EXEC_BASE} -name gnat1 -exec /sbin/chpax -E \{\} \; \ || die "Failed to enable trampolines for gnat1 in ${GCC_EXEC_BASE}..." fi to src_unpack() after "unpack ${A}". This is harmless on non-hardened systems so there's no need for it to be conditional, apart from the check on availability of /sbin/chpax. I've changed from the full path spec for gnat1 to a 'find' approach - that way if you update to a different bootstrap compiler it'll get the PaX marking ok. All chpax does is modify two bytes in the ELF header that are normally unused. The hardened kernel looks at these two bytes to determine whether it needs to do anything special for PaX compatibility. The patch I supplied ealier for 3.44-r1 which sorted out PaX flag markings for the various stage compilers is not needed on -r2; the bootstrap compiler supports the GNU_STACK marking and -r2 uses the Gentoo native ld for linking which automatically sets the appropriate PaX markings. You could consider building the bootstrap compiler on Gentoo and supplying that rather than using the Ubuntu build; if you do then you won't need to do anything at all for PaX. Another thought is to avoid the bootstrap compiler if the host already has gnat installed, and use the host gnat instead (c.f. what main gcc does on bootstrap). I'll note here also that you'll see a "QA Notice" regarding executable stacks - this is all the same thing; I'll raise a bug later to handle that.
Thanks Kevin. So, are these changes all what is needed to support hardened in gnat? If yes, it is really nice, as that simplifies the build logic a lot.. (In reply to comment #27) > You could consider building the bootstrap compiler on Gentoo and supplying that > rather than using the Ubuntu build; if you do then you won't need to do > anything at all for PaX. I did consider this, however at the time I went with "why change when it works".. However right now I am working on splitting gnat into 3 compilers to follow upstream - gnatgcc (FSF) and gnatpro/gnatgpl (Ada Core) packages. See #111340 for details. There I used my locally built gnat for bootstrap (now, that you gave me a reason :)). Hopefully that avoids this issue for the new package. BTW, I just posted a new iteration of an eclass, ebuild and eselect module to that bug, so you can even test if you wish. It is amd64 only for a moment, as I need to issue a new bootstrap for x86 as well.. I am thinking to add support for gnatpro-3.15 and then add new eclass and packages to the tree (p-masked untill some test reports flow in of course..) > Another thought is to avoid the bootstrap compiler if > the host already has gnat installed, and use the host gnat instead (c.f. what > main gcc does on bootstrap). I thought about this too, but I do not see any advantages - if the provided bootstrap compiler is recent enough. The result is going to be the same as long as it builds, as it bootstraps in 3 stages, just like gcc does. And trying to rely on locally installed gnat is just harder to maintain.. > I'll note here also that you'll see a "QA Notice" regarding executable stacks Yes, I notice that. However, can we really do anything about them? IIRC executable stack is how gcc implements nested functions and these are absolutely necessary for Ada, unlike C they are not gnu extensions.. Well, I do not really know much about backend internals, so any info/resolution would be wellcome of course.. George
(In reply to comment #28) > > I'll note here also that you'll see a "QA Notice" regarding > > executable stacks > Yes, I notice that. However, can we really do anything about them? Not without patching the GNAT source code. There are only a handful of places that cause executable stack and I'm developing changes to rewrite them in such a way as to avoid executable stack. This would be useful for the compiler itself and for the gnat library, as it would allow the compiler to work on NX stack systems (even if the resulting binary cannot) and also stop the automatic marking for executable stack of anything that links to the gnat library. The only other way to do it is to rewrite the GCC backend to implement nested functions without trampolines - and I don't have the skills to do that :) My plan for this is to develop the changes and try it locally; when it's done I'll raise a bug and post the patches - however I suspect I'm the only hardened Gentoo user who uses GNAT :) I'm hoping upstream would accept such changes, if they're simple enough. BTW not all nested subprograms cause the compiler to generate trampolines (executable stack elements). It only occurs when the nested subprogram refers to stuff from the scope of the subprogram in which it is declared, so although the GNAT source has nested subprograms throughout, only a few actually cause trampolines. It is possible to implement Ada compilers without using executable stack, not least because in the Ada standard, subprogram access attributes (function pointers) can only be used in the scope of their declaration, unlike C function pointers which can be passed out of their declarative scope. However GNAT has an extension, "'Unrestricted_Access" which can be used the same way that C function pointers can be used, and this makes things more difficult. It also has implications for program correctness checks - it's possible although probably pathalogical to write code that can try to use such a function pointer out of scope, which should generate a Program_Error; I don't know whether GNAT actually does or not. In C of course behaviour in such situations is undefined - either way such code would be incorrect.
(In reply to comment #28) > So, are these changes all what is needed to support hardened in gnat? If yes, > it is really nice, as that simplifies the build logic a lot.. Meant to reply to this as well :) The chpax thing gets gnat to build and work in its standard form. However the hardened gcc includes a bunch of other changes; mostly to the default specs but also to incorporate the stack protector. The gcc-3 stack protector causes the GNAT build to fail, as it trips a limitation in the stack protector (bug #74457). For now, it would be useful to incorporate a version of the GCC_SPECS patch into the gnat compiler; most of the hardened stuff is about changing the default switches (building PIEs, setting BIND_NOW, RELRO) and this is done by changing the compiler 'specs' data. I'll attach a suitable patch.
Created attachment 76523 [details, diff] Add ability to set specs with GNAT_SPECS envvar Patch causes the compiler to process files listed in GNAT_SPECS as if they were specified with the '-specs' command line option.
Thanks Kevin! But I think we need to tidy up the bugs a bit - this one started on a particular compilation problem that has been long resolved. I'd like to close it, as it is quite confusing to look for PaX stuff under "gnat does not compile". Could you please create a new bug, posting there still relevant patch(es) and description(s) and naming it appropriately? I'll look into adding PaX and hardened support, but I'll certainly need your help on that ;). Plus, now that I committed the split gnat eclass and ebuilds, I think it is better to concentrate on the new code. This is a backend fix, as I see, so it will get incorporated into the eclass. Quite likely the eselect tool will have first to be upgraded to do wrappers and support multilib for real, like it is done by toolchain and eselect-compiler. Although the last one is still p-masked, so it may yet have some major changes, basically I am hesitant to start reworking eselect-gnat before eselect-compiler goes ~arch.. George
ok :) I've raised bug #119382 for hardened issues, so marking this resolved/fixed.
