I couldn't find the new bug report alluded to in 521518, hence this bug report. #521518 Well, I just figured that gnatgcc also doesn't support C (even though 'gnatgcc -v' reports --enable-languages=c,ada) which explains why I was having such a hard time compiling even gcc-4.7.3. I don't yet understand how to bootstrap an ada compiler yet (I guess I'll look into the ebuilds as well as in the gnat and gnatbuild eclasses). There is definitely something wrong with the gnatgcc package. Brian from GHDL pointed out that my build could be failing because of a clash between adacore's binaries and the gnatgcc binaries. I was able to bootstrap gcc 4.8.2 after uninstalling gnatgcc. I don't understand why gnatgcc is missing standard C headers (or at the very least, why it's failing to build 4.7.3). I'll look into updating the gnat-gcc package, but maybe someone more knowledgeable on the subject can point me in the right direction in case I'm missing something. Ok, so I was able to compile gcc 4.8.2 with ada,c,c++ support using adacore's binaries. But adacore's won't work with 4.7.3 (and I'm guessing any version before that based on http://permalink.gmane.org/gmane.comp.gcc.help/43256 ). The issue being that the gcc project doesn't distribute binaries. I'm starting to understand why the gnat-gcc ebuild uses downloads gnatboot binaries… There's always: https://en.wikibooks.org/wiki/Ada_Programming/Installing#The_GNU_Ada_Project (linked from https://gcc.gnu.org/wiki/GNAT ) as a collection of links to downloads bootstrap binaries. From what I understand at this point, the first step in getting a newer version of gnat-gcc that can compile C++ and ada (which is needed to update the ghdl ebuild at least as far as I understand it at this point) is to build a binary (to be distributed) to build the gnat-gcc sources. May be my overlay could help. I have ebuilds for GNAT GPL till gnat-gpl-4.7.4.2013.ebuild Beside this I have next bootstraps: * gnatboot-4.3-amd64.tar.bz2 * gnatboot-4.3-i386.tar.bz2 * gnatboot-4.3-ppc.tar.bz2 * gnatboot-4.5-armv6j.tar.bz2 (I used qemu to build last two). Overlay URL is http://www.ada-ru.org/gentoo/overlay.xml Created attachment 403692 [details, diff] Draft to support USE="ada gnatboot" with sys-devel/gcc Using this patch against toolchain.eclass I've been able to build sys-devel/gcc versions 4.6.4, 4.7.4, 5.1.0 with c,c++,ada support on my amd64 box. The ideas are: *) USE=gnatboot when there's no Ada compiler installed. *) The binary images created with 'emerge --buildpkg sys-devel/gcc' are used as bootstrap compilers without any change, as long as that compiler is configured to "--enable-languages=c,c++,ada". So a gnatboot image revbump then boils down to: $ USE="ada" emerge --buildpkg =sys-devel/gcc-4.7.4 $ cd /usr/portage $ mv packages/sys-devel/gcc-4.7.4.tbz2 distfiles/gnatboot-4.7.4.tar.bz2 *) But still, the eclass can use George's gnatboot images as well. The additional changes to sys-devel/gcc-*.ebuilds go along these lines: --- gcc-4.7.4.ebuild +++ gcc-4.7.4.ebuild @@ -20,6 +20,13 @@ SSP_UCLIBC_STABLE="x86 amd64 ppc ppc64 arm" #end Hardened stuff +# gnatboot image filenames need to start with "gnatboot-*" +GNATBOOT_SRC_URI=" + amd64? ( http://dev.gentoo.org/~george/src/gnatboot-4.4-amd64.tar.bz2 ) + sparc? ( http://dev.gentoo.org/~george/src/gnatboot-4.4-sparc.tar.bz2 ) + x86? ( http://dev.gentoo.org/~george/src/gnatboot-4.4-i686.tar.bz2 ) +" + inherit eutils toolchain KEYWORDS="~alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 -amd64-fbsd -x86-fbsd" --- gcc-5.1.0.ebuild +++ gcc-5.1.0.ebuild @@ -20,6 +20,13 @@ SSP_UCLIBC_STABLE="x86 amd64 mips ppc ppc64 arm" #end Hardened stuff +# gnatboot image filenames need to start with "gnatboot-*" +GNATBOOT_SRC_URI=" + amd64? ( http://dev.gentoo.org/~haubi/distfiles/gnatboot-4.7.4-amd64.tar.bz2 ) + sparc? ( http://dev.gentoo.org/~george/src/gnatboot-4.4-sparc.tar.bz2 ) + x86? ( http://dev.gentoo.org/~george/src/gnatboot-4.4-i686.tar.bz2 ) +" + inherit toolchain #KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86" The 4.4 images will not work for 5.1.0 due to the missing C++ compiler, but I've uploaded a gnatboot-4.7.4-amd64.tar.bz2 image already, which should be useable by above toolchain.eclass patch. (In reply to Michael Haubenwallner from comment #7) > Created attachment 403692 [details, diff] [details, diff] > Draft to support USE="ada gnatboot" with sys-devel/gcc Is there still a reason for toolchain.eclass for "We do NOT want 'ADA support' in here!" ? the "# use ada" line first showed up here: https://sources.gentoo.org/sys-devel/gcc/gcc-3.3.3-r2.ebuild?r1=1.2&r2=1.3 i temporarily enabled it via bug 18052: https://sources.gentoo.org/sys-devel/gcc/gcc-3.3.3-r2.ebuild?r1=1.4&r2=1.5 but was quickly reverted via bug 23171: https://sources.gentoo.org/sys-devel/gcc/gcc-3.3.3-r2.ebuild?r1=1.5&r2=1.6 during the next revbump, the comment was changed to what you see today: https://sources.gentoo.org/sys-devel/gcc/gcc-3.3.3-r3.ebuild?revision=1.1 at any rate, bug 11204 documents troubles, as does follow up bug 25178. whether how much of that is still accurate i have no idea as i've never followed ada. (In reply to SpanKY from comment #9) > whether how much of that is still accurate i have no idea as i've never > followed ada. The only reason I've catched up here is that GCC upstream pushed me to also test some gcc patch with Ada: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00448.html As ada herd feels understaffed (George only), I didn't expect to get some GNAT compiler with c,ada & c++ enabled in time: As it turns out the more recent dev-lang/gnat-gcc-4.6.4 uses plain gcc tarballs already, translating the important bits from gnat-gcc & gnatbuild into gcc & toolchain was easy enough. However, I've dropped the need for a bootstrap-specific (size-optimized) c,c++,ada compiler image, but reuse an 'emerge --buildpkg' generated one instead. And for a more generic point of view: Requiring an Ada compiler to compile an Ada compiler is nothing different to requiring a C,C++ compiler to compiler a C,C++ compiler. The difference is that we have the C,C++ compiler at hand for ages: Probably the proposed 'gnatboot' USE-flag could be ada-independent - for when you lack/broke your C,C++ compiler... (In reply to Michael Haubenwallner from comment #10) mmm, you can rebuild gcc w/USE=cxx on/off and it builds fine, same as any of the other language flags in gcc. yes, you need a compiler to build a compiler (i.e. C), but it's not really the same as the others. gcc itself has a bootstrap phase. does that not work for ada ? i'm not keen on gcc depending on a prebuilt gcc. (In reply to SpanKY from comment #11) Yes, even bootstrapping the Ada compiler requires an Ada compiler - parts of the Ada compiler is written in Ada. OTOH, even bootstrapping the C compiler requires a C++ compiler now: When the currently selected compiler is gcc:4.7(-cxx), emerge gcc:4.8 gives: Makefile:7572: recipe for target 'configure-stage1-libcpp' failed make[2]: *** [configure-stage1-libcpp] Error 1 And libcpp/config.log tells: configure:4904: error: C++ compiler missing or inoperational Agreed, I don't like the need for a binary compiler image too. But it feels like the only fallback option for when the required bootstrap-compilers are not available. Actually I can think of moving IUSE="gnatboot" to something Ada-independent like IUSE="bootstrapimage" - or some separate gcc-bin package... (In reply to Michael Haubenwallner from comment #12) which is why newer versions of gcc don't let you turn off the C++ compiler. but to recover, all you do is build your existing gcc with USE=cxx enabled and then things continue to build fine. very few people try to run such a system though, so almost no one even noticed. ada has no such self bootstrap path, and it is turned off by default, and i can't see us ever turning it on by default. and if a user turned it off and wanted to turn it back on, the flow is not smooth like the other gcc languages. hence it is not the same as the others, so let's stop wasting time trying to equivocate. maintaining a gcc-bin package sounds like a complete nightmare. it exists only for ada, so trying to generalize it looks like a recipe for confusion. i think i would rather have the ada bootstrap be internalized. do you generally need the versions to match ? or can say a prebuilt gcc 4.6 ada be used to build a gcc 4.9 ada ? what about vice-versa ? can a gcc 4.9 ada be relied upon to build a gcc 4.6 ada ? (In reply to SpanKY from comment #13) IIRC, somewhere I've read that they try to keep bootstrap-able even with gcc-3.4, although I fail to find that link again. But inspired by http://en.wikibooks.org/wiki/Ada_Programming/Installing#GCC anything >=gcc-4.4 should be sufficient Ada-wise. Exactly, the idea of USE=gnatboot is to use the prebuilt c,c++,ada compiler for bootstrap only when there's no such compiler installed yet. Heck, it should be feasible to have just one version able to use a prebuilt one - if that one is <=gcc-4.7, even George's existing gnatboot-4.4 images would suffice. (In reply to Michael Haubenwallner from comment #14) if we can minimize the # of bootstrap tarballs then i'm fine with it in the toolchain.eclass. further, if it's pretty stable over time, and we can get the size down, i'd be ok with avoiding a bootstrap flag and having the build download it all the time. a spot check of gnatboot-4.4-amd64.tar.bz2 shows that, when using xz, it gets down to 12 MB. a glance in there doesn't look like there's anything we could really strip out (maybe libgomp?). but considering every gcc release since 4.7.0 has been over 80 MB, 12 MB (that is stable across versions) is fine ? (In reply to SpanKY from comment #15) For the bootstrap image versioning requirements - tested with any >=gcc-4.1 currently in tree on amd64 multilib profile here: * The bootstrap Ada compiler must not be newer than the just built Ada compiler, as the newer Ada parser fails with syntax used in the older ones. * George's gnatboot-4.1 is sufficient for up to gcc-4.5* (or see https://gcc.gnu.org/ml/gcc-help/2011-03/msg00387.html ) * George's gnatboot-4.3 is sufficient for up to gcc-4.7* (then c++) * Ada in gcc-4.7.1 is broken by itself, 4.7.0 and 4.7.2 are ok * gcc-4.4.7 binpkg (USE="cxx ada -multilib -nptl -openmp") is sufficient for up to gcc-5.1.0 (need to test with trunk), and comes at 13MB when created with "bzcat gcc-4.4.7.tbz2 | xz -9 --extreme > gnatboot-4.4.7-amd64.tar.xz" (In reply to Michael Haubenwallner from comment #16) let's start with gcc-4.4 binpkg then and drop support for older versions note: you'll need to update gcc-config too to support the new program names, or at least double check to make sure it works Created attachment 405534 [details, diff]
toolchain.eclass: support BOOTGCC_SRC_URI, needed for IUSE=ada
Renaming "gnatboot" to "bootgcc" to indicate ada-independent usage. Better names?
Created attachment 405536 [details, diff]
gcc-*.ebuild (latest per branch): utilize/set BOOTGCC_SRC_URI
Use bootgcc-4.4.7-amd64.tar.xz image. I'd prefer revbump for each gcc-branch.
For gcc-4.4.7, keep previously available (by gnatbuild.eclass) archs intact, so people with appropriate hardware can provide the gcc-4.4.7-arch.tar.xz image.
Created attachment 422740 [details, diff]
Change to toolchain.eclass for ada
This is the change that I have made locally. I tested building ada 4.9.3
I had to bootstrap it using the gnat-gcc ebuild and some handcrafting, but once I did the first it goes
I was able to build 5.3.0 from 4.9.3 without any problem.
I think this is the minimal changes that we need once ada is bootstrapped.
There are still some issues, with my approach
1) how to cleanly bootstrap. We need a gcc compiler with ada, c and c++.
2) as the newest ada compiler can raise problem on building old compiler, we need to raise warning/info in that case
3) how to manage conflict with other gnat release, like gnat-gpl or gnatpro
Comment on attachment 422740 [details, diff] Change to toolchain.eclass for ada >--- toolchain.eclass 2016-01-12 21:31:19.592079903 +0100 >+++ /usr/portage/eclass/toolchain.eclass 2015-12-31 06:31:02.000000000 +0100 >@@ -151,7 +151,7 @@ > # versions which we dropped. Since graphite was also experimental in > # the older versions, we don't want to bother supporting it. #448024 > tc_version_is_at_least 4.8 && IUSE+=" graphite" IUSE_DEF+=( sanitize ) >+ tc_version_is_at_least 4.9 && IUSE+=" cilk ada" >- tc_version_is_at_least 4.9 && IUSE+=" cilk" > tc_version_is_at_least 5.0 && IUSE+=" jit" > tc_version_is_at_least 6.0 && IUSE+=" pie +ssp" > fi >@@ -858,8 +858,8 @@ > is_f77 && GCC_LANG+=",f77" > is_f95 && GCC_LANG+=",f95" > >+ # We do want 'ADA support' here! >+ is_ada && GCC_LANG+=",ada" >- # We do NOT want 'ADA support' in here! >- # is_ada && GCC_LANG+=",ada" > > confgcc+=( --enable-languages=${GCC_LANG} ) > >@@ -1665,7 +1665,7 @@ > cd "${D}"${BINPATH} > # Ugh: we really need to auto-detect this list. > # It's constantly out of date. >+ for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo gnatbind; do >- for x in cpp gcc g++ c++ gcov g77 gcj gcjh gfortran gccgo ; do > # For some reason, g77 gets made instead of ${CTARGET}-g77... > # this should take care of that > if [[ -f ${x} ]] ; then sorry. Patch is reversed Ok, I am (kinda) back, will try to make another push to get Ada stuff in order. Here, I see, it was discussed how to bring Ada support directly into gcc. There are a few conceptual points I would like to raise first, before even talking about technical sides: 1. bootstrap and what it means in "daily life" Yes, building gnat or Ada-enabled gcc requires ada-enabled gcc. Which means that a) official gcc bootstraps and stages should include Ada support for everybody, while probably ~1% of users or les would benefit (even that is huge, but still, we are talking >10 MB added to all stages for everybody) b) if, at any point, ada support is dropped, e.g. gcc is recompiled without Ada even once, to bring it back one would have to essentially rebuild the entire system from grounds-up.. 2. We would normally need to plan to push Ada support on majority of ARCHes if it is considered an official part of gcc now.. 3. Perhaps no less important than 1: mutiple compatible but alternative gnat implementations. At the moment there are two widely used variants: a) gnat-gcc - essentially gcc with Ada support by FSF: uo-to-date backend, falling behind front-end b) gnat-gpl - the version by AdaCore, an official provider of gnat: this one is behind on a backend but provides most up-t--date front-end Also, there are some differences in licensing, its essentially the GPL vs LGPL issue.. Stll, both can complie (most of) the same code, follow the same starndard, so can usually be used as active alternatives. The Ada-build system now provides the possibility to build both and use them interchangingly. The entire infrastructure is in place to manage associated libraries without getting into ABI trouble (see e.g. gnat.eclass).. See also the Ada project page - I wrote up some docs about how it all holds together and is supposed to function.. So, conceptually, just pulling Ada support into the gcc directly may not be the best thing to even plan for.. Still, I would like to hear any opinions here. Also, I am planning anoverhaul of gnatbuild.eclass, as gcc backend has drifted wat too far away over last 10 years or so and later versions kind of stop functioning gradually. The plan is to bring gnatbuild.eclass more inline with modern toolchain. Some details are in #574548. I can make this bug depend on that one, but I am not sure if that makes sense.. (In reply to George Shapovalov from comment #23) As discussed in comment #15 and up, the idea for sys-devel/gcc is to _not_ rely on any pre-installed compiler any more, but download a pre-built binary gcc image (with C,C++,Ada support only) instead - like you do with dev-lang/gnat-gcc already. (In reply to Michael Haubenwallner from comment #25) > (In reply to George Shapovalov from comment #23) > As discussed in comment #15 and up, the idea for sys-devel/gcc is to _not_ > rely on any pre-installed compiler any more, but download a pre-built binary > gcc image (with C,C++,Ada support only) instead - like you do with > dev-lang/gnat-gcc already. So yes, that would alleviate p1., but it is relatively minor, comapred to p3.. (In reply to George Shapovalov from comment #26) As I'm not really used to Ada: Why doesn't blocking RDEPEND work for 3.? I would add another point on the issue to take into consideration: Whenever you switch between some ada version (with eselect or gcc-config) you need to rebuild some ada library (like xml2ada) |
As the summary says, bootstrapping GCC >= 4.8 requires a C++ compiler. As bootstrapping gnat also requires an ada compiler, it is currently not possible to build recent versions of GCC with ada support. Reproducible: Always Steps to Reproduce: 1. Create gcc/{source,build} directories 2. Download and extract gcc-4.8.2.tar.bz2 into gcc/source/ 3. From build, run CC=gnatgcc CPPFLAGS='-I/usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.3/include' CFLAGS='-I/usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.3/include' ../source/gcc-4.8.2/configure --enable-languages=c,c++,ada && make Actual Results: The build fails Expected Results: The build succeeds