Created attachment 444064 [details, diff] Patch toolchain.eclass to add Ada support I'm trying to get a clean up of all the Ada stuff in Gentoo, I don't really care if the old stuff gets removed as it's ancient and a complete mess, IMO. There is absolutely no need for a separate compiler build just for Ada, i.e. the gnatgcc stuff. Ada should be part of the toolchain.eclass just like the other compilers. Here's the first part in rectifying this, adding Ada into the toolchain.eclass. I have tested x86 and amd64 to bootstrap the system compiler for v4.9.3 and then used the subsequent compiler to build the next version, which was 5.1.0. All subsequent versions should be buildable by the previously installed compiler and if need be, be able to build the previous version with a later one. It's a cleaner solution to the mess that we have now.
The patch looks safe enough to go in because everything is shielded by `in_iuse ada` but I don't know ada's build well enough to say if we have all the pieces. Maybe others in toolchain can comment. I do have a few questions: 1. Are you sure about this line? It says that this will work with all versions of gcc in the tree except 2.95.3-r10. Did you test? + tc_version_is_at_least 3 && IUSE+=" ada doc gcj awt hardened multilib objc" 2. I assume that ada is built with ada and so we're testing if we have an ada compiler with the following line, correct? +if [[ ! -f `which gnatbind 2>&1|tee /dev/null` ]]; then
1) I've asked around if later versions would compile earlier versions, I can only find references to the installation saying it must be x or later for y version. So, can only say that it should work. I've not tested it. I know there are issues with certain versions compiling a later version, so for example, 4.9.x won't compile 6.x, but 4.9.3 will compile 5.1.0 and 5.x will compile 6.x. 2) gnatbind is one of the tools installed by the --enable-languages=ada, so testing for that binary is checking to see if there was already a GCC built with Ada enabled, therefore, don't use the bootstrap.
Ok, so I got a reply to a question about 1) on https://groups.google.com/forum/#!topic/comp.lang.ada/iFKBsDVZZns but it seems to be a question of whether the C compiler would work. I would need to build it to see.
I just tried building the following for x86 using the 5.1.0 compiler: 3.4.6-r2 4.4.7 4.5.4 4.6.4 4.7.4 4.8.5 All failed. I set the system compiler to 4.9.3, trying them again: 3.4.6-r2 4.4.7 4.5.4 4.7.4 All failed again, but 4.8.5 compiled and installed fine. I don't think it would be a problem setting the min version for the 4.9.3 bootstrap to 4.8.5, but given that Ada 2012 support didn't become decent/stable until the 4.9.x series, I think it's best to stick to that as a minimum version for now. Trust me on this, anyone using Ada will want a newer compiler anyway as there have been a lot of internal compiler errors in previous versions, so it's always better to have a more up to date compiler. Luke.
Created attachment 444066 [details, diff] Add Ada to toolchain.eclass v4 Added ARM bootstrap.
Also, I've added the ada use flag to 4.9 minimum as I know it's a good version that will build itself without problems.
(In reply to Luke A. Guest from comment #5) > Created attachment 444066 [details, diff] [details, diff] > Add Ada to toolchain.eclass v4 > > Added ARM bootstrap. Since you've already tested for version 4.9, the following, modulo comments, if [[ ! -f `which gnatbind 2>&1|tee /dev/null` ]]; then tc_version_is_at_least 3 && GNAT_BOOTSTRAP_VERSION="4.9" GNAT_STRAP_DIR="${WORKDIR}/gnat_strap" fi would be better written as if in_iuse ada && [[ ! -f `which gnatbind 2>&1|tee /dev/null` ]]; then GNAT_BOOTSTRAP_VERSION="4.9" GNAT_STRAP_DIR="${WORKDIR}/gnat_strap" fi
Well, really that line could be: if [[ ! -f `which gnatbind 2>&1|tee /dev/null` ]]; then # First time build, so need to bootstrap this. # A newer version of GNAT should build an older version, just not vice-versa. 4.9 can definitely build 5.1.0. tc_version_is_at_least 4.9 && GNAT_BOOTSTRAP_VERSION="4.9" GNAT_STRAP_DIR="${WORKDIR}/gnat_strap" fi Because in the future further bootstraps will be required to handle later releases. But I'm happy to just take out the test for now.
Created attachment 444082 [details, diff] Add Ada to toolchain.eclass v5
(In reply to Luke A. Guest from comment #9) > Created attachment 444082 [details, diff] [details, diff] > Add Ada to toolchain.eclass v5 you dropped the "in_iuse ada &&" that i added to that if statement. i'm a bit worried about poluting the environment by setting GNAT_BOOTSTRAP_VERSION and GNAT_STRAP_DIR if we don't have ada in IUSE.
(In reply to Anthony Basile from comment #10) > (In reply to Luke A. Guest from comment #9) > > Created attachment 444082 [details, diff] [details, diff] [details, diff] > > Add Ada to toolchain.eclass v5 > > you dropped the "in_iuse ada &&" that i added to that if statement. i'm a > bit worried about poluting the environment by setting GNAT_BOOTSTRAP_VERSION > and GNAT_STRAP_DIR if we don't have ada in IUSE. I actually didn't notice it. Fixed.
Created attachment 444146 [details, diff] Add Ada to toolchain.eclass v6
(In reply to Luke A. Guest from comment #12) > Created attachment 444146 [details, diff] [details, diff] > Add Ada to toolchain.eclass v6 okay, following gentoo policy, i have to email that to the gentoo-dev@ email list for review by the community and then i'll commit.
(In reply to Anthony Basile from comment #13) > (In reply to Luke A. Guest from comment #12) > > Created attachment 444146 [details, diff] [details, diff] [details, diff] > > Add Ada to toolchain.eclass v6 > > okay, following gentoo policy, i have to email that to the gentoo-dev@ email > list for review by the community and then i'll commit. Okay, thanks for taking the time to look at it.
(In reply to Luke A. Guest from comment #14) > (In reply to Anthony Basile from comment #13) > > (In reply to Luke A. Guest from comment #12) > > > Created attachment 444146 [details, diff] [details, diff] [details, diff] [details, diff] > > > Add Ada to toolchain.eclass v6 > > > > okay, following gentoo policy, i have to email that to the gentoo-dev@ email > > list for review by the community and then i'll commit. > > Okay, thanks for taking the time to look at it. actually before I email the list, I should bounce this bug off of Steve (nerdboy) since he's maintaining dev-lang/gnat-gcc. we need to coordinate with him. @steve, what do you think about bringing gnat into toolchain and building ada via `USE=ada emerge gcc` ?
(In reply to Anthony Basile from comment #15) > (In reply to Luke A. Guest from comment #14) > > (In reply to Anthony Basile from comment #13) > > > (In reply to Luke A. Guest from comment #12) > > > > Created attachment 444146 [details, diff] [details, diff] [details, diff] [details, diff] [details, diff] > > > > Add Ada to toolchain.eclass v6 > > > > > > okay, following gentoo policy, i have to email that to the gentoo-dev@ email > > > list for review by the community and then i'll commit. > > > > Okay, thanks for taking the time to look at it. > > actually before I email the list, I should bounce this bug off of Steve > (nerdboy) since he's maintaining dev-lang/gnat-gcc. we need to coordinate > with him. > > @steve, what do you think about bringing gnat into toolchain and building > ada via `USE=ada emerge gcc` ? That's fine, he's been aware of this from the outset. It's his gnatstrap's I'm using.
Created attachment 444148 [details, diff] Add Ada to toolchain.eclass v7 Enhancement from "specing" on #Ada to change `which gnatbind 2>&1|tee /dev/null` into $(command -v gnatbind)
'[[ ! -f $(command -v gnatbind) ]]' should not be in global scope. I suggest to replace it with '! type -P gnatbind > /dev/null'. '[ ! -d ${GNAT_STRAP_DIR} ]' should be '[[ ! -d ${GNAT_STRAP_DIR} ]]'. Only stdout (without stderr) of pushd / popd should be sent to /dev/null. GNAT_EXTRA_BINS should be marked as local variable (and maybe lowercased).
This is definitely cleaner than a separate package/eselect tool, but will need to integrate with gcc-config to set the proper adalib/adainclude paths. I'm still working on the application side (ie, an updated gnat eclass) which needs to match the compiler side config. I have a draft spec in the overlay: https://github.com/sarnold/portage-overlay/blob/master/eclass/gnat-r1.eclass # Gentoo GNAT/Ada policy draft (install locations, etc) # # Gnat package installs are no longer profile dependent; only the active GNAT # profile is currently supported, so packages will depend on the latest SLOT. # There is now only one set of install paths and directory locations # that more-or-less follows the GNU & Debian Ada policies for shared libraries: # https://people.debian.org/~lbrenta/debian-ada-policy.html # # Source files SHALL reside in directory $AdalibSpecsDir/<package-name> # - merge all source files (specs and bodies) into one directory if possible # - provide all required source files, and only source files # The *.ali files SHALL reside in $AdalibLibTop/<package-name> # - *.ali files SHALL have read-only permissions for all users (mode 0444) # Each library SHALL provide a library project file named <library>.gpr # - project files SHALL reside in a configured project search path as # shown by gnatls -v # - Current project path is /usr/share/gpr # - Goal project path is $AdalibSpecsDir (parent of library source dirs) # Shared/static libraries and binaries SHALL reside in the standard locations # The library project file SHALL have: # - a Source_Dirs attribute containing at least /usr/share/ada/adainclude/<library> # - a Library_ALI_Dir equal to /usr/$libdir/ada/adalib/<library> # - a Library_Name attribute equal to the library name of the shared library # - a Library_Kind attribute equal to ‘dynamic’ # - a Library_Dir attribute equal to /usr/$libdir # - an Externally_Built attribute equal to ‘true’ # - a Linker_Options section for any library dependencies # *note: $libdir and linker options should be declared External # Example: # library project <library> is # for Library_Name use "<library>"; # for Library_Dir use "/usr/lib"; # for Library_Kind use "dynamic"; # for Source_Dirs use ("/usr/share/ada/adainclude/<library>"); # for Library_ALI_Dir use "/usr/lib/ada/adalib/<library>"; # for Externally_Built use "true"; # package Linker is # for Linker_Options use ("-lindirectdependency"); # end Linker; # end <library>; # # See ncurses gpr files for real examples
(In reply to Steve Arnold from comment #19) > This is definitely cleaner than a separate package/eselect tool, but will > need to integrate with gcc-config to set the proper adalib/adainclude paths. > I'm still working on the application side (ie, an updated gnat eclass) which > needs to match the compiler side config. I have a draft spec in the overlay: Is it premature to commit this change to the eclass? It would seem to me that the change go gcc-config to set proper paths and the change to the eclass should go in simultaneously.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #18) > '[[ ! -f $(command -v gnatbind) ]]' should not be in global scope. > I suggest to replace it with '! type -P gnatbind > /dev/null'. > > '[ ! -d ${GNAT_STRAP_DIR} ]' should be '[[ ! -d ${GNAT_STRAP_DIR} ]]'. > > Only stdout (without stderr) of pushd / popd should be sent to /dev/null. > > GNAT_EXTRA_BINS should be marked as local variable (and maybe lowercased). I'll do this tomorrow.
(In reply to Anthony Basile from comment #20) > (In reply to Steve Arnold from comment #19) > > This is definitely cleaner than a separate package/eselect tool, but will > > need to integrate with gcc-config to set the proper adalib/adainclude paths. > > I'm still working on the application side (ie, an updated gnat eclass) which > > needs to match the compiler side config. I have a draft spec in the overlay: > > Is it premature to commit this change to the eclass? It would seem to me > that the change go gcc-config to set proper paths and the change to the > eclass should go in simultaneously. Have to agree on this. I will talk to Steve about it.
Due to requirement of invariance of metadata, SRC_URI cannot be dependent on existence of gnatbind or another file. So the following can be done: In global scope: if in_iuse ada; then GNAT_BOOTSTRAP_VERSION="4.9" fi ... if in_iuse ada; then GCC_SRC_URI+=" amd64? ( https://dev.gentoo.org/~nerdboy/files/gnatboot-${GNAT_BOOTSTRAP_VERSION}-amd64.tar.xz ) ... fi In toolchain_src_unpack(): # Unpack the Ada bootstrap if bootstrapping is necessary. if in_iuse ada && ! type -P gnatbind > /dev/null; then mkdir -p "${WORKDIR}/gnat_bootstrap" || die pushd "${WORKDIR}/gnat_bootstrap" > /dev/null || die case $(tc-arch) in ... esac popd > /dev/null || die fi In toolchain_src_configure(): if in_iuse ada && [[ -d ${WORKDIR}/gnat_bootstrap ]]; then export GNATBOOT="${WORKDIR}/gnat_bootstrap/usr" Other questions: Does setting CC and CXX cause that gnatgcc and gnatg++ (instead of tools selected by gcc-config) are used for building of all C / C++ parts of GCC (at least during first phase of building of GCC)?
Created attachment 444250 [details, diff] Add Ada to toolchain.eclass v8 Various changed made. Please go over it and make sure I haven't made any mistakes. (In reply to Arfrever Frehtes Taifersar Arahesis from comment #23) > Other questions: > > Does setting CC and CXX cause that gnatgcc and gnatg++ (instead of tools > selected by gcc-config) are used for building of all C / C++ parts of GCC > (at least during first phase of building of GCC)? Yes, because if we don't use them, the build won't find the Ada compiler. It must use the driver from the bootstrap or it won't work at all. But again, this is only for the first build, every time after that the script will use the system compiler.
`man 5 ebuild`: "Note that the EXTRA_ECONF is for users only, not for ebuild writers. If you wish to pass more options to configure, just pass the extra arguments to econf." So change 'EXTRA_ECONF+=(' to 'confgcc+=(' and drop new line with einfo.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #25) > `man 5 ebuild`: > "Note that the EXTRA_ECONF is for users only, not for ebuild writers. If you > wish to pass more options to configure, just pass the extra arguments to > econf." > > So change 'EXTRA_ECONF+=(' to 'confgcc+=(' and drop new line with einfo. good catch!
Created attachment 445698 [details, diff] Add Ada to toolchain.eclass v9 Latest revision based on latest in Gentoo tree.
(In reply to Steve Arnold from comment #19) > This is definitely cleaner than a separate package/eselect tool, but will > need to integrate with gcc-config to set the proper adalib/adainclude paths. Yes. > # Shared/static libraries and binaries SHALL reside in the standard locations You sure about this? Each lib is compiled with a particular compiler in a particular slot, shouldn't Ada libs also be installed according to compiler slot?
Created attachment 470640 [details, diff] Add Ada to toolchain.eclass v10 Patch against most recent toolchain.eclass
Can this patch be added into the eclass so I don't have to keep updating it?
Removing x86 stabilization team, as I don't see a direct role for us in this. Please add us again if you want something going through stabilization testing.
Any progress on this bug? Having ada USE flag for gcc would be great.
Yes, check github, I've updated it. I've managed to build up to 5.4.0, but 6.x is failing with: libtool: compile: /var/tmp/portage/sys-devel/gcc-6.1.0/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-6.1.0/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-l inux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/libgfortr an -iquote/var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/libgfortran/io -I/var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/libgfortran/../gcc -I/var/tmp/portage/sys-devel/gcc-6. 1.0/work/gcc-6.1.0/libgfortran/../gcc/config -I/var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/libgfortran/../libquadmath -I../.././gcc -I/var/tmp/portage/sys-devel/gcc-6.1.0/work/g cc-6.1.0/libgfortran/../libgcc -I../libgcc -I/var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace -std=gnu11 -Wall -Wstric t-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-sections -g -march=native -O2 -pipe -MT symlnk.lo -MD -MP -MF .deps/symlnk.Tpo -c /var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/libgfortran/intrinsics/symlnk.c -fPIC -DPIC -o .libs/symln k.o make[3]: *** No rule to make target 'gcc-6.1.0', needed by '../../gnatmake'. Stop. make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-6.1.0/work/build/gcc/ada/tools' make[2]: *** [Makefile:195: gnattools-native] Error 2 make[2]: Leaving directory '/var/tmp/portage/sys-devel/gcc-6.1.0/work/build/gnattools' make[1]: *** [Makefile:11306: all-gnattools] Error 2 make[1]: *** Waiting for unfinished jobs....
Created attachment 471560 [details] Full debug log of 6.1.0 This fails at all-gnattools -> gnattools-native target.
I've added 2 new boostrap compilers for amd64, 5.3.0 and 6.3.0, they are inside a dropbox folder: https://www.dropbox.com/sh/stljjvpj9201n8t/AAAzVG67ppskZ9UKiWTWz9Q_a?dl=0 I built the these by ebuild ... prepare, then configure, make, etc using the installed compilers. So, the 6.x series builds with the 5.4.0 compiler, as it should. In there is a compressed debug compile log of 6.1.0 which fails when building with emerge, see above it builds normally by hand. I get the same error when building 6.3.0 with emerge. The failure starts at: make -C ../gcc/ada/tools -f ../Makefile \ "CC=../../xgcc -B../../" "CXX=../../xg++ -B../../ -B../../../x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B../../../x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -L../../../x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L../../../x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs" "CFLAGS=-g -march=native -O2 -pipe -W -Wall" "LDFLAGS=-static-libstdc++ -static-libgcc " "ADAFLAGS=-gnatpg -gnata" "ADA_CFLAGS=" "INCLUDES=-iquote . -iquote .. -iquote ../.. -iquote /var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/gcc/ada -iquote /var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/gcc/config -iquote /var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/gcc -I/var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/include" "ADA_INCLUDES=-I- -I../rts -I. -I/var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/gcc/ada" "exeext=" "fsrcdir=/var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/gcc" "srcdir=/var/tmp/portage/sys-devel/gcc-6.1.0/work/gcc-6.1.0/gcc" "GNATMAKE=../../gnatmake" "GNATLINK=../../gnatlink" "GNATBIND=../../gnatbind" "TOOLSCASE=native" \ ../../gnatmake ../../gnatlink Live child 0x6858a0 (gnattools-native) PID 28783 Then for some reason, thinks there is a target with the name matching the compiler, which there isn't. I've no clue where it's coming from or how. Updating goal targets.... Considering target file '../../gnatmake'. File '../../gnatmake' does not exist. Considering target file 'gcc-6.1.0'. File 'gcc-6.1.0' does not exist. Looking for an implicit rule for 'gcc-6.1.0'. Trying pattern rule with stem 'gcc-6.1.0'. Trying implicit prerequisite 'gcc-6.1.0.o'. ...
I created this bug report because that old one is so old and uses all the stuff that needs to be purged from the Gentoo tree as it's a massive hack and uses a complete rewrite of the toolchain.eclass. This *needs* to be part of the toolchain.eclass so that cross-dev also works. That is what this buig fixes, albeit for some reason anything above 5.4.0 doesn't build yet and I'm yet to see any resolution or help.
Created attachment 477544 [details, diff] Add Ada to toolchain.eclass v11 A new patch against latest eclass, sync'd from today.
(In reply to Luke A. Guest from comment #37) > Created attachment 477544 [details, diff] [details, diff] > Add Ada to toolchain.eclass v11 > > A new patch against latest eclass, sync'd from today. FYI, I've not been able to test this yet.
Created attachment 488908 [details, diff] Latest toolchain.eclas from today, v12
Created attachment 489108 [details, diff] Latest toolchain.eclas from today, v13 The previous patch was wrong.
Created attachment 489110 [details, diff] New patch, v14 Removes a comment.
Created attachment 489112 [details, diff] Latest toolchain.eclas from today, v15 Sort the use flags.
Created attachment 489216 [details, diff] Latest toolchain.eclas from today, v16 Fixed the correct gcc and g++ bootstrap compilers, the names have changed since this was first created.
Ok, back to the issue at comment 33, where for some reason when compiling 6.3.0 with the 5.4.0 or the gnatboot strap tools, it fails because the makefiles are being passed a target of gcc-6.3.0!???
(In reply to Luke A. Guest from comment #44) > Ok, back to the issue at comment 33, where for some reason when compiling > 6.3.0 with the 5.4.0 or the gnatboot strap tools, it fails because the > makefiles are being passed a target of gcc-6.3.0!??? This also happens with gcc-6.1.0
Latest toolchain patch introduces a bunch of binary tarballs that don't exist: sys-devel/gcc $ LANG=C repoman manifest >>> Downloading 'http://distfiles.gentoo.org/distfiles/gnatboot-6.3-i686.tar.xz' --2017-08-17 21:57:45-- http://distfiles.gentoo.org/distfiles/gnatboot-6.3-i686.tar.xz Resolving distfiles.gentoo.org... 64.50.233.100, 140.211.166.134, 137.226.34.46, ... Connecting to distfiles.gentoo.org|64.50.233.100|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2017-08-17 21:57:45 ERROR 404: Not Found. >>> Downloading 'https://dev.gentoo.org/~nerdboy/files/gnatboot-6.3-i686.tar.xz' --2017-08-17 21:57:45-- https://dev.gentoo.org/~nerdboy/files/gnatboot-6.3-i686.tar.xz Resolving dev.gentoo.org... 140.211.166.183, 2001:470:ea4a:1:5054:ff:fec7:86e4 Connecting to dev.gentoo.org|140.211.166.183|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2017-08-17 21:57:46 ERROR 404: Not Found. !!! Couldn't download 'gnatboot-6.3-i686.tar.xz'. Aborting. !!! Fetch failed for gnatboot-6.3-i686.tar.xz, can't update Manifest Unable to generate manifest.
(In reply to Sergei Trofimovich from comment #46) > Latest toolchain patch introduces a bunch of binary tarballs that don't > exist: > > sys-devel/gcc $ LANG=C repoman manifest > >>> Downloading 'http://distfiles.gentoo.org/distfiles/gnatboot-6.3-i686.tar.xz' > --2017-08-17 21:57:45-- > http://distfiles.gentoo.org/distfiles/gnatboot-6.3-i686.tar.xz > Resolving distfiles.gentoo.org... 64.50.233.100, 140.211.166.134, > 137.226.34.46, ... > Connecting to distfiles.gentoo.org|64.50.233.100|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 2017-08-17 21:57:45 ERROR 404: Not Found. > > >>> Downloading 'https://dev.gentoo.org/~nerdboy/files/gnatboot-6.3-i686.tar.xz' > --2017-08-17 21:57:45-- > https://dev.gentoo.org/~nerdboy/files/gnatboot-6.3-i686.tar.xz > Resolving dev.gentoo.org... 140.211.166.183, > 2001:470:ea4a:1:5054:ff:fec7:86e4 > Connecting to dev.gentoo.org|140.211.166.183|:443... connected. > HTTP request sent, awaiting response... 404 Not Found > 2017-08-17 21:57:46 ERROR 404: Not Found. > > !!! Couldn't download 'gnatboot-6.3-i686.tar.xz'. Aborting. > !!! Fetch failed for gnatboot-6.3-i686.tar.xz, can't update Manifest > Unable to generate manifest. Currently not all the bootstraps have been built. I have 5.4 and 6.3.0 amd64 built. You can stop the from happening in your test env by commenting out the gnatboot i686 and arm lines and closing the string for amd64 as of now. We need to get past the issue at comment 44 before we can go further. There is absolutely no reason why the build process should be getting a target of gcc-6.1.0 or gcc-6.3.0 passed to it.I can build a compiler without emerge and with Ada support using 5.4.0 and 6.3.0, but for some reason within the emerge env, this fails.
Created attachment 489690 [details, diff] Removes usage of the P macro This patch needs to go into /usr/portage/sys-devel/gcc/files/6.3.0, in gcc/ada/gcc-interface/Makefile.in there used to be a macro defined called P, in the Gentoo dev environment, this P means the product. In the lines where it is used ../../gnatmake$(exeext): and ../../gnatlink$(exeext): the dependencies on P were not removed, so in the build, make would be trying to find the target of gcc-6.3.0/6.4.0/7.1.0/etc.
Created attachment 489692 [details, diff] Patch for gcc-6.3.0.ebuild Adds gnat specific path to remove P.
Created attachment 489694 [details, diff] Patch for gcc-6.4.0.ebuild Adds gnat specific path to remove P.
Created attachment 489696 [details, diff] Patch for gcc-7.1.0-r1.ebuild Adds gnat specific path to remove P.
Created attachment 490036 [details, diff] Patch for gcc-6.4.0.ebuild v2
@blueness as far as comment #15 I missed this bug for a while but this has been discussed a lot in #ada so I've been more-or-less in the loop. I was hoping that george would respond but that hasn't happened for many moons, and lately I've had too many customers/projects and no minimum distance between me and my wife while working... Anyway, there are apparently other users interested in preserving Ada support, but bootstrap compilers aren't as easy as they used to be and it *does* make more sense to fold it into the normal toolchain stuff rather than continue to maintain what is essentially a separate fork just for Ada. So it's about time for me to test this more heavily with the new bootstraps and (hopefully) move forward with the 6/7 versions (not sure about 5.x yet) and make gnat-gcc-4.9.4 the last version (possibly 5.4 for testing against new 5.4). Also, since I just hit a bug with some packages picking up gnat-gcc (non-Ada) headers it seems like a good time to make the switch. Lastly we still need to work out a new packaging policy/eclass for Ada packages but that needs more input (and toolchain comes first...)
arrr, this is already the shiznitz :P With a couple of tweaks, not only does it build a toolchain with Ada support, but then it builds ncurses with USE="ada". Updated toolchain.eclass still needs some gcc-config integration and some (hardened) QA fixes, but nice piece of work overall. Other packages like ncurses still rely on some ADA_PATH variables and need a place to install their sources/libs, so ebuild helper and policy draft (pretty much what was pasted here until we get more feedback) updates will come next.
(In reply to Luke A. Guest from comment #28) > (In reply to Steve Arnold from comment #19) > > # Shared/static libraries and binaries SHALL reside in the standard locations > > You sure about this? Each lib is compiled with a particular compiler in a > particular slot, shouldn't Ada libs also be installed according to compiler > slot? For now, yes, since gcc/gnat is now installed/slotted with full version (eg, 5.4.0) instead of two-digit gnat slot, the adalibs/adaincludes paths can default to LIBPATH/*. Once the packaging/policy decisions are firmed up, this might be tweaked a bit. The above default is fine for a simple build/install of something like ncurses, but the (really) old george eclass/eselect thing used to keep track of each package that installed "ada libs" and I'm not sure if that was because of just the 2-digit slot or not. It should fall out of the policy stuff, but at this point I'm not sure if we *need* to keep track of each installed set of libs per slot. Which means each compiler slot gets whatever is installed/built with that version, so we need to decide what we want when a slot version is uninstalled, etc.
As for the building of a bootstrap, I didn't do too much, I pretty much did what nerdboy (says he) did: ebuild gcc-6.4.0.ebuild prepare mkdir /tmp/{install,build}-gcc-6.4.0-amd64 cd /tmp/build-gcc-6.4.0-amd64 Pretty much took the options from /tmp/usr/bin/gcc -v from an existing gnat bootstrap. /var/tmp/portage/sys-devel/gcc-6.4.0/work/gcc-6.4.0/configure --target=x86_64-pc-linux-gnu --prefix=/usr --with-arch=athlon64 --enable-languages=c,ada,c++ --with-gcc --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libmudflap --disable-libssp --disable-libunwind-exceptions --enable-libada --enable-threads=posix --enable-shared --enable-multilib --enable-__cxa_atexit --enable-clocale=gnu --disable-altivec --disable-fixed-point --disable-libgcj --disable-libcilkrts --disable-libsanitizer --disable-libquadmath --disable-bootstrap --disable-libvtv --disable-libgomp --without-ppl --without-cloog --without-isl --with-multilib-list=m64,m32 --enable-multiarch --enable-targets=all make -j7 && make DESTDIR=/tmp/install-gcc-6.4.0-amd64 install-strip
(In reply to Steve Arnold from comment #53) > > So it's about time for me to test this more heavily with the new bootstraps > and (hopefully) move forward with the 6/7 versions (not sure about 5.x yet) > and make gnat-gcc-4.9.4 the last version (possibly 5.4 for testing against > new 5.4). Also, since I just hit a bug with some packages picking up > gnat-gcc (non-Ada) headers it seems like a good time to make the switch. Tamiko (on #gentoo-toolchain) has already told me to focus on 6/7 rather than 5.4.0.
Updated for various things; QA warnings in 6.x, path mangling, bootstrap use flag (at least for a little while) and tweaked the logic a bit to check for existing gnat. The TODO marks the most questionable piece I could use feedback on, couldn't find a better way to rest the path for non-bootstrap build (when it was blank it failed the gnat configure test). That said, 6.3/6.4/7.1 build fine from 6.4/7.1 bootstraps and previous/current installed gcc; they also build (slightly patched) ncurses Ada bindings, which get installed in the "normal" LIBPATH dirs for the active toolchain. So far I've only appended the basic ADA env vars to gcc_envd_file which is enough to both find the files when building and tell packages where to install Ada files. There is still one pullrequest for Luke but otherwise ready for feedback.
Finally found the upstream bug with all the trampoline patches; although there are several bugs with arch-specific "add-ons" to the original core set. I haven't checked the other arches yet, but x86/amd64 has the patches in 7.1 (but not 6.4 or below). I'm assuming they wouldn't apply cleanly to 6.x so would take some amount of effort to back-port/test. If nobody else does it in the next few weeks I might have time, don't let that stop anyone... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67205
This is pretty much done (pending any feedback) for the arches I can do with the hardware I have, mainly x86/amd64/arm/arm64. I dropped the "ada" support for 4.x and below, so the new stuff has bootstraps for 5.4, 6.4, and 7.2 (makes a clean-ish cutover from gnat-gcc 4.9.3). Mainly tested with hardened and related flags, built/rebuilt with both itself and the bootstrap builds, all green with the new patches (also tested with previous major version bootstraps and current, but current is default). Time to flame or merge (or flame then merge).
I made a pull request (to myself) against the latest tree for review purposes, add comments as needed. I'm fully armed with native and cross gnat toolchains now... https://github.com/sarnold/gentoo/pull/1
I tested it now with the =sys-devel/gcc-7.3.0-r1 and =sys-devel/gcc-4.9.4 on an ~amd64 default/linux/amd64/17.1/no-multilib profile in this order of versions. All worked perfectly for me, including switching gcc versions.
Do you please have a variant patch not using the in_iuse() function in global scope?
2020 brought in an undelayable update to gcc, and now I am without my faithful USE=Ada gcc-6.4.0. Where are we at?
We need new bootstraps, but for a quick fix on x86-64 (dunno about i586), we can use the dev-lang/gnat-gpl (2019-r1) toolchain as that bootstrap. But ideally, we need new ones for all targets. This is because there was an ABI change last time I tried looking at this and the bootstraps weren't linked statically, so the maths libs were all wrong versions. Then the Ada stuff needs to go back in, with nerdboy adding/checking what he did with the arm stuff before. Then the toolchain people need to accept the patches, not so simple.
The topic was brought up a few times in #gentoo-toolchain. It looks like there is disagreement between intent of these patches and intent of how ada@ manages toolchains. Reassigning to ada@ to agree on the approach.
(In reply to Sergei Trofimovich from comment #66) > The topic was brought up a few times in #gentoo-toolchain. It looks like > there is disagreement between intent of these patches and intent of how ada@ > manages toolchains. > > Reassigning to ada@ to agree on the approach. There is only one way to do this (for gcc's gnat), the correct way, the way I've already showed. For llvm/gnat, that can be a separate ebuild, that can co-exist with sys-devel/gcc +ada.
*** Bug 783807 has been marked as a duplicate of this bug. ***
nerdboy?
Since Adacore has discontinued GNAT GPL upstream, it would probably be a good idea to integrate these changes from ~GCC 12. I can confirm that manually enabling Ada support in the GCC ebuild and using the old GNAT GPL to bootstrap it works as expected.
(In reply to Andrew Athalye from comment #70) > Since Adacore has discontinued GNAT GPL upstream, it would probably be a > good idea to integrate these changes from ~GCC 12. I can confirm that > manually enabling Ada support in the GCC ebuild and using the old GNAT GPL > to bootstrap it works as expected. Did it build also all the dev-ada packages?
You can find the relevant changes and bootstraps in my overlay on gh.
ada use flag is now unmasked for x86 and amd64. gcc-12.2.0 can be used now to build gprbuild and xmlada For other architecture I don't see any other way except adding some gcc [ada] binary gnat-compilers out of the toolchain
Did you take anything from my overlay?
(In reply to Luke A. Guest from comment #74) > Did you take anything from my overlay? No, I don't know where it is, and what provide sorry
You haven't really been paying attention then? I've posted in the dev-ml about it, I emailed you directly and you ignored me. If you go to sarnold's github below you can get to it.
