This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
The location of the Ada runtime and utilities is inconsistent with the location of all other language runtimes. They should be moved to their own toplevel subdirectory, and their build harness brought into line with the other languages. Release: 3.1 20020308 (prerelease)
From: "Joseph S. Myers" <jsm28@cam.ac.uk> To: <zack@codesourcery.com> Cc: <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org> Subject: Re: ada/5911: Ada runtime and utilities should be broken out to their own directory Date: Sun, 10 Mar 2002 19:05:13 +0000 (GMT) On 10 Mar 2002 zack@codesourcery.com wrote: > >Severity: non-critical > >Priority: low > >Class: change-request > The location of the Ada runtime and utilities is inconsistent > with the location of all other language runtimes. They > should be moved to their own toplevel subdirectory, and their > build harness brought into line with the other languages. Since the present system means that the Ada libraries aren't properly built in multilib variants, this should be considered an actual serious bug, not just a low-priority change-request. -- Joseph S. Myers jsm28@cam.ac.uk
From: Florian Weimer <fw@deneb.enyo.de> To: zack@codesourcery.com Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: ada/5911: Ada runtime and utilities should be broken out to their own directory Date: Sun, 10 Mar 2002 22:47:15 +0100 zack@codesourcery.com writes: > The location of the Ada runtime and utilities is inconsistent > with the location of all other language runtimes. They > should be moved to their own toplevel subdirectory, and their > build harness brought into line with the other languages. For technical reasons, the GNAT front end is built using the run-time library sources which come with the compiler sources, and not using the installed GNAT run-time library on the host system. In other words, the compiler depends on a (rather small) subset of the run-time library sources. However, there is no reason why a large part of the run-time library could not be moved to a separate directory. For the build, we should use another separate directory, IMHO.
From: Zack Weinberg <zack@codesourcery.com> To: "Joseph S. Myers" <jsm28@cam.ac.uk> Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: ada/5911: Ada runtime and utilities should be broken out to their own directory Date: Mon, 11 Mar 2002 02:04:51 -0800 On Sun, Mar 10, 2002 at 07:05:13PM +0000, Joseph S. Myers wrote: > > Since the present system means that the Ada libraries aren't properly > built in multilib variants, this should be considered an actual serious > bug, not just a low-priority change-request. Didn't realize that. Good point. (I don't think it's a release blocker, though, even if Ada is considered part of the release.) zw
From: Zack Weinberg <zack@codesourcery.com> To: Florian Weimer <fw@deneb.enyo.de> Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: ada/5911: Ada runtime and utilities should be broken out to their own directory Date: Mon, 11 Mar 2002 02:07:27 -0800 On Sun, Mar 10, 2002 at 10:47:15PM +0100, Florian Weimer wrote: > zack@codesourcery.com writes: > > > The location of the Ada runtime and utilities is inconsistent > > with the location of all other language runtimes. They > > should be moved to their own toplevel subdirectory, and their > > build harness brought into line with the other languages. > > For technical reasons, the GNAT front end is built using the run-time > library sources which come with the compiler sources, and not using > the installed GNAT run-time library on the host system. I'm aware of this. > However, there is no reason why a large part of the run-time library > could not be moved to a separate directory. In fact, I don't see any reason why it should inhibit moving all of it. gcc/ada/Make-lang.in can just reference the files from $(srcdir)/../libada/. > For the build, we should use another separate directory, IMHO. I'm sorry, I don't know what you mean here. zw
From: Florian Weimer <fw@deneb.enyo.de> To: Zack Weinberg <zack@codesourcery.com> Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: ada/5911: Ada runtime and utilities should be broken out to their own directory Date: Mon, 11 Mar 2002 11:29:03 +0100 Zack Weinberg <zack@codesourcery.com> writes: >> For the build, we should use another separate directory, IMHO. > > I'm sorry, I don't know what you mean here. Sorry, s/build/tools/ (such as gnatmake; gnatbind has to be built during compiler bootstrap, together with gnat1).
State-Changed-From-To: open->analyzed State-Changed-Why: This is a well-understood change request; it causes endless irritations with the build process.
Related bug 5910, which is so they get built with just make all/bootstrap.
This really should be done for 3.5 as 3.5 will be a big release (with the addition of the tree-ssa branch).
This is not a mere enhancement request, it causes all sorts of build bugs, as you can see from the dependency list.
<< This is not a mere enhancement request, it causes all sorts of build bugs, as you can see from the dependency list. >> Actually this is not quite true: most if not all the PR that have been marked as dependent on this one can be fixed independently of this issue. Concerning this specific PR, I believe everyone agrees this would be a good thing, the main question is how to achieve this. For one thing, I started looking at how you add a new e.g. libada directory (and enable its configuration and build from the top level directory) and I must admit that it is not at all clear how to to that (I'm not a configure expert anyway). Assuming "someone" would add a dummy libada directory that would get configured and built (e.g. with an empty Makefile and configure) automatically, I could then start working on providing an actual configure.in and Makefile.in to make it work for real. Any volunteer ? Arno
Subject: Re: Ada runtime and utilities should be broken out to their own directory On Tue, 21 Oct 2003, charlet at gcc dot gnu dot org wrote: > For one thing, I started looking at how you add a new e.g. libada directory > (and enable its configuration and build from the top level directory) and > I must admit that it is not at all clear how to to that (I'm not a configure > expert anyway). > > Assuming "someone" would add a dummy libada directory > that would get configured and built (e.g. with an empty Makefile and configure) > automatically, I could then start working on providing an actual > configure.in and Makefile.in to make it work for real. I expect Nathanael can advise on this - and also on anything special needed in that directory to ensure that such things as multilibs and Canadian crosses work properly. (Current documentation in this area is rather lacking, though there's the old etc/configure.texi included in binutils that documents the *old* toplevel system.)
*** Bug 5910 has been marked as a duplicate of this bug. ***
Subject: Bug 5911 CVSROOT: /cvs/gcc Module name: gcc Changes by: charlet@gcc.gnu.org 2004-02-10 10:44:14 Added files: libada : ChangeLog Makefile.in configure configure.in Log message: 2003-02-10 Arnaud Charlet <charlet@act-europe.fr> PR ada/6637, PR ada/5911 * configure.in, Makefile.in, configure: Merge with libada-branch Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libada/ChangeLog.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libada/Makefile.in.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libada/configure.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libada/configure.in.diff?cvsroot=gcc&r1=1.1&r2=1.2
Subject: Bug 5911 CVSROOT: /cvs/gcc Module name: gcc Changes by: charlet@gcc.gnu.org 2004-02-10 10:51:33 Modified files: gcc/ada : ChangeLog config-lang.in Log message: PR ada/6637, PR ada/5911 Merge with libada-branch: * config-lang.in: Build libada only when ada is built. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcc&r1=1.445&r2=1.446 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/config-lang.in.diff?cvsroot=gcc&r1=1.9&r2=1.10
Subject: Bug 5911 CVSROOT: /cvs/gcc Module name: gcc Changes by: charlet@gcc.gnu.org 2004-02-10 10:54:48 Modified files: . : configure.in configure Makefile.def Makefile.in ChangeLog Log message: PR ada/6637, PR ada/5911 Merge with libada-branch: * configure.in, Makefile.tpl, Makefile.def: Add target-libada, with appropriate dependencies. Add --enable-libada configure switch. * configure, Makefile.in: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.in.diff?cvsroot=gcc&r1=1.267&r2=1.268 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.diff?cvsroot=gcc&r1=1.127&r2=1.128 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.def.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.196&r2=1.197 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.865&r2=1.866
libada-branch now merged, so it is no longer necessary to do a make -C gcc gnatlib_and_tools to build Ada, as well as handling of cross compilers and --enable-shared. Keeping this PR open for the issue of supporting multilib. I am not familiar with how multilib works, so this will likely require help from someone that knows this area. Arno
This is not an enhancement as it is required for correct compiling of code as it will cause things not to link or even worse link with the wrong one and cause an illegal instructions and such for the targets.
Mine. Discussion: http://gcc.gnu.org/ml/gcc/2008-07/msg00338.html
Subject: Bug 5911 Author: guerby Date: Wed Jul 30 06:45:39 2008 New Revision: 138294 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138294 Log: gcc/ChangeLog 2008-07-29 Laurent Guerby <laurent@guerby.net> PR ada/5911 * gnattools/Makefile.in: Replace stamp-gnatlib by stamp-gnatlib-rts. gcc/ada/ChangeLog 2008-07-29 Laurent Guerby <laurent@guerby.net> PR ada/5911 * gcc-interface/Makefile.in (MULTISUBDIR, RTSDIR): New variables. Pass MULTISUBDIR to recursive make. Use $(RTSDIR) instead of rts. Replace stamp-gnatlib* by stamp-gnatlib*-rts. * gcc-interface/Make-lang.in: Replace stamp-gnatlib2 by stamp-gnatlib2-rts. Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Make-lang.in trunk/gcc/ada/gcc-interface/Makefile.in trunk/gnattools/Makefile.in
Note that changes to gnattools/ are to be described in gnattools/ChangeLog.
Yes, I already moved the relevant entry to gnattools/ChangeLog.
Sorry about the misplaced ChangeLog
Subject: Bug 5911 Author: guerby Date: Sun Sep 21 11:45:23 2008 New Revision: 140525 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140525 Log: 2008-09-21 Laurent Guerby <laurent@guerby.net> PR ada/5911 * gcc-interface/Makefile.in: Add multilib handling for x86_64 and sparc. * system-linux-sparcv9.ads: New file. 2008-09-21 Laurent Guerby <laurent@guerby.net> Paolo Bonzini <bonzini@gnu.org> PR ada/5911 * Makefile.in (all, install, mostlyclean, clean, distclean): Add multilib handling. * configure.ac: Add multilib handling. * configure: Regenerate. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in trunk/libada/ChangeLog trunk/libada/Makefile.in trunk/libada/configure trunk/libada/configure.ac
To use Ada multilib with gnatmake: export FLAGS="-m32"; gnatmake $FLAGS --RTS=$(gcc -print-multi-directory $FLAGS) -f main.adb
> To use Ada multilib with gnatmake: > > export FLAGS="-m32"; gnatmake $FLAGS --RTS=$(gcc -print-multi-directory $FLAGS) > -f main.adb We should try and eliminate one of the redundant $FLAGS.
Paolo suggested: "Yes, you would basically take from gcc.c the code that turns "-m32" into "use multilib 32", and use it to make a --RTS option." I think Paolo said there might be some cleanup to do to gcc.c first but I can't find the reference. %I handling by gcc.c is also of interest and might be copied to gnat1 invocation. I believe you should open another PR about multilib and gnattools friendly command lines to follow up on this.
Subject: Re: Support for multilib in Ada > I think Paolo said there might be some cleanup to do to gcc.c first but I can't > find the reference. %I handling by gcc.c is also of interest and might be > copied to gnat1 invocation. Yes, there is code in gcc.c that understands multilib, and we should avoid duplicating it into gnat. Factoring it in a separate file would be nice. > I believe you should open another PR about multilib and gnattools friendly > command lines to follow up on this. Agreed.
Subject: Bug 5911 Author: ebotcazou Date: Fri Sep 26 08:33:04 2008 New Revision: 140687 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140687 Log: PR ada/5911 * gcc-interface/Makefile.in (SPARC/Solaris): Add multilib support. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in