[Bug bootstrap/26323] New: toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc

[Bug bootstrap/26323] New: toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc

[pinskia at gcc dot gnu dot org]

PR 26259 raises a semi valid concern but it was not written correctly in the
first place which is why it was closed so I am opening this new one to explain
what is going on.

Toplevel directories are sometimes associated with languages via
gcc/language/config-lang.in but that associated and be removed when removing
gcc/language which causes that toplevel directory to be built.

This is an enhancement because gcc/language/config-lang.in is the documented
way of adding the association.

Maybe adding toplevel/directory/associate-config.in will fix this.


-- 
           Summary: toplevel directories should be assocaited at the
                    toplevel with a language being built instead of with a
                    subdirectory of gcc
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26323

[Bug bootstrap/26323] toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-16 16:11 -------
*** Bug 26259 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26323

[Bug bootstrap/26323] toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-02-16 16:17 -------
Also I should point out this is not documented in the user manual because well
users should not be deleting directories.  It is documented in the internals
manual, maybe not as big as it should be but it is there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26323

[Bug bootstrap/26323] toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc

[rob1weld at aol dot com]

------- Comment #3 from rob1weld at aol dot com  2009-01-13 00:14 -------
In gcc version 4.4.0 20090111 (experimental) [trunk revision 143259] we have
the: "Cannot build gnattools while gnatlib is out of date or unbuilt" Bug.


# gmake clean-gcc
...
# gmake
...
gmake[4]: Leaving directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/libgcc'
g
...
gmake[5]: Entering directory `/usr/share/src/gcc_build/gcc'
gmake[5]: `ada/s-oscons.ads' is up to date.
gmake[5]: Leaving directory `/usr/share/src/gcc_build/gcc'
test -f stamp-libada || \
        gmake -C ../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-m64" "LN_S=ln
-s" "SHELL=/bin/sh" "GNATLIBFLAGS=-W -Wall -gnatpg -m64" "GNATLIBCFLAGS=-g -O2
-m64" "TARGET_LIBGCC2_CFLAGS=-fPIC" "THREAD_KIND=native" "TRACE=no"
"MULTISUBDIR=/amd64"
"libsubdir=/usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/amd64" "objext=.o"
"prefix=/usr/local" "exeext=.exeext.should.not.be.used "
'CC=the.host.compiler.should.not.be.needed'
"GCC_FOR_TARGET=/usr/share/src/gcc_build/./gcc/xgcc
-B/usr/share/src/gcc_build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
-B/usr/local/i386-pc-solaris2.11/lib/ -isystem
/usr/local/i386-pc-solaris2.11/include -isystem
/usr/local/i386-pc-solaris2.11/sys-include" "CFLAGS=-g -O0 -fprofile-arcs
-ftest-coverage    -m64 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes" gnatlib-shared \
        && touch stamp-libada
true  DO=all multi-do # gmake
gmake[4]: Leaving directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libada'
gmake[3]: Leaving directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/libada'
gmake[2]: Leaving directory
`/usr/share/src/gcc_build/i386-pc-solaris2.11/libada'
gmake[2]: Entering directory `/usr/share/src/gcc_build/gnattools'
rm -rf ../gcc/ada/tools
mkdir -p ../gcc/ada/tools
(cd ../gcc/ada/tools; ln -s ../sdefault.adb .)
rm -f ../gcc/ada/tools/mlib-tgt-specific.adb; ln -s
/usr/share/src/gcc_trunk/gcc/ada/mlib-tgt-specific-solaris.adb
../gcc/ada/tools/mlib-tgt-specific.adb;
touch ../gcc/stamp-tools
Cannot build gnattools while gnatlib is out of date or unbuilt
gmake[2]: *** [../gcc/stamp-gnatlib-rts] Error 1
gmake[2]: Leaving directory `/usr/share/src/gcc_build/gnattools'
gmake[1]: *** [all-gnattools] Error 2
gmake[1]: Leaving directory `/usr/share/src/gcc_build'
gmake: *** [all] Error 2


You may get this message; if you type:
# cd gcc_build/gcc/..
# make clean-gcc
# make
...
"Cannot build gnattools while gnatlib is out of date or unbuilt".

Rob


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26323

[Bug bootstrap/26323] toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-13 00:18 -------
>"Cannot build gnattools while gnatlib is out of date or unbuilt".


That bug is a different issue than this bug.  Please don't confuse the two.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26323

[Bug bootstrap/26323] toplevel directories should be assocaited at the toplevel with a language being built instead of with a subdirectory of gcc

[rob1weld at aol dot com]

------- Comment #5 from rob1weld at aol dot com  2009-01-13 02:52 -------
(In reply to comment #4)
> >"Cannot build gnattools while gnatlib is out of date or unbuilt".
> That bug is a different issue than this bug.  Please don't confuse the two.

I searched before I posted to try to avoid a dupe.

As long as this _second_ manifestation of "Cannot build gnattools while ..."
is recorded as a bug _somewhere_ then that is OK. It would be a 'fix' in _my_
instance if typing "make" built gnatlib first (so it was not "out of date or
unbuilt") and then was able to build gnattools successfully.

Thanks for the info,
Rob


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26323