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
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)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=799693623d76c89e8b04d2434d0dfece44bb49f9 commit 799693623d76c89e8b04d2434d0dfece44bb49f9 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-08-03 02:27:51 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-29 00:18:08 +0000 toolchain.eclass: Ada rework Look hard for an existing GNAT for use for bootstrapping without requiring users to run `gcc-config` / switch their system copy of GCC, which is both brittle in that it requires manual intervention, and also unclean. Started looking at this after https://public-inbox.gentoo.org/gentoo-dev/2a700166-f01a-4807-bd76-7b0cce72af0b@archeia.com/ although the approach is different. I did use it as a base although not much of it remains. We take the following approach: * Iterate over installed GCC slots (preferring ${SLOT}, then iterating from the latest version installed down to GCC 10) to find a copy of GNAT; * Create wrappers for gnat* to redirect calls when building GCC to our found bootstrap copy of GNAT; * Use an extracted spec file to redirect gnat1 calls to that bootstrap copy too, as the build system doesn't allow saying "just use this copy of gnat" (it always wants $(CC) to support it). The real nasty part here is that GCC's build system doesn't seem to have a way to point to 'ADACC' or similar (it looks like it did have 'ADAC' years ago). Remaining bits to be done: * Adapting/replacing/supplementing dev-lang/gnat-gpl with a version that can be installed in parallel to sys-devel/gcc:10 so it can be pulled in transparently for bootstrapping; * Build our own, or source some other copy (e.g. from Alire), of a newer bootstrap GNAT. https://github.com/alire-project/GNAT-FSF-builds is a likely candidate. I also hope that we can ultimately do the same for D. Bug: https://gcc.gnu.org/PR864 Bug: https://gcc.gnu.org/PR108909 Bug: https://bugs.gentoo.org/137268 Bug: https://bugs.gentoo.org/547358 Bug: https://bugs.gentoo.org/919667 Closes: https://bugs.gentoo.org/937774 Link: https://lists.fedorahosted.org/archives/list/epel-devel@lists.fedoraproject.org/thread/CVQ3JIOZI5ODYDZU2DZLA37JWSLMCIN7/ Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 143 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 141 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f210bb3d7324b1a6c1fe9d5e98cdfd57241d6499 commit f210bb3d7324b1a6c1fe9d5e98cdfd57241d6499 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-09-28 23:00:54 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-29 00:15:58 +0000 dev-lang/gnat-gpl: rename USE=bootstrap -> USE=system-bootstrap, invert meaning USE=bootstrap has/had a special meaning in <EAPI 5 and it also ends up stable-masked apparently too. It was dropped from use.desc in af748c0468c6ab3ce760de2bfd84f4cef1eb9bcf and dropped from sys-devel/gcc a while ago too (bug #440224). To facilitate automatically using gnat-gpl in sys-devel/gcc, do two things: * Rename USE=bootstrap -> USE=system-bootstrap * Make USE=system-bootstrap mean "I need a working Ada compiler to build this" (i.e. invert its meaning) to match dev-java/openjdk and dev-lang/rust. Bug: https://bugs.gentoo.org/137268 Bug: https://bugs.gentoo.org/440224 Bug: https://bugs.gentoo.org/547358 Bug: https://bugs.gentoo.org/919667 Signed-off-by: Sam James <sam@gentoo.org> dev-lang/gnat-gpl/gnat-gpl-2021-r5.ebuild | 12 ++++++------ dev-lang/gnat-gpl/metadata.xml | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-)
I think this is done, really (if it wasn't before, it is now with the above commits I just pushed). See bug 919667 for the gnat-gpl deprecation issue.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e6a69ea10ed74a0ce49e979bbc4bbce139949259 commit e6a69ea10ed74a0ce49e979bbc4bbce139949259 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-10-01 01:02:17 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-10-01 01:10:28 +0000 toolchain.eclass: support dev-lang/ada-bootstrap Bug: https://bugs.gentoo.org/547358 Bug: https://bugs.gentoo.org/919667 Bug: https://bugs.gentoo.org/940472 Closes: https://bugs.gentoo.org/940471 Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 42 +++++++++++++++++++++++++++++++++--------- 1 file changed, 33 insertions(+), 9 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2fecbe438a39dfc3b226ff2c474c297a0763998f commit 2fecbe438a39dfc3b226ff2c474c297a0763998f Author: Sam James <sam@gentoo.org> AuthorDate: 2024-09-30 20:01:59 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-10-01 01:10:27 +0000 dev-lang/ada-bootstrap: new package, add 0_p2021 Split dev-lang/gnat-gpl into dev-lang/ada-bootstrap. This ebuild was initially a clone of dev-lang/gnat-gpl-2021-r5 then had some cleanups done, toolchain.eclass use removed, and simplified what it configures/builds/installs. As I mentioned in 799693623d76c89e8b04d2434d0dfece44bb49f9, there were two jobs left -- this fixes the first one: splitting dev-lang/gnat-gpl into its own package which doesn't collide with sys-devel/gcc:10 and also does the least possible work, not with lots of USE, etc.) Some inspiration taken from sys-devel/bpf-toolchain. Considered using the *-toolchain name again but given the purpose of this is *not* just to avoid crossdev use but instead to bootstrap from a binary for Ada, it didn't feel appropriate. (Planned to do this anyway but the issue mentioned in 9732ef3475830dbe289fc80358613e90b612563c pushed me to get on with it now.) Later versions of ada-bootstrap will be our own binaries for both newer GCC as a base (although this is mostly a nice-to-have and to keep things building rather than it being essential, AFAIK) as well as more importantly musl and other arch support. For that future work, see https://bugs.gentoo.org/940471#c1 for a suggestion from Luke A. Guest. That will be tracked in bug #940472. Bug: https://bugs.gentoo.org/547358 Bug: https://bugs.gentoo.org/919667 Bug: https://bugs.gentoo.org/940472 Closes: https://bugs.gentoo.org/940471 Signed-off-by: Sam James <sam@gentoo.org> dev-lang/ada-bootstrap/Manifest | 5 + .../ada-bootstrap/ada-bootstrap-0_p2021.ebuild | 183 +++++++++++++++++++++ .../files/ada-bootstrap-0_p2021-gentoo.patch | 72 ++++++++ .../files/gcc-configure-texinfo.patch | 16 ++ dev-lang/ada-bootstrap/metadata.xml | 7 + 5 files changed, 283 insertions(+)
