[Bug bootstrap/26259] New: --enable-languages=c,c++,fortran needs ada

[Bug bootstrap/26259] New: --enable-languages=c,c++,fortran needs ada

[bkoz at gcc dot gnu dot org]

Posted here:
http://gcc.gnu.org/ml/gcc/2006-02/msg00150.html

However, I have noticed this recenly as well. This is considered a bug, as
--enable-languages should actually work.


-- 
           Summary: --enable-languages=c,c++,fortran needs ada
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bkoz at gcc dot gnu dot org


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-13 17:00 -------
I have never seen this in my builds and I don't have Ada installed on my main
machine which I bootstrap on.

What is most likely happening is someone did svn change in the ada subdirectory
and did not also do it in the gnattools directory also.


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[bkoz at gcc dot gnu dot org]

------- Comment #2 from bkoz at gcc dot gnu dot org  2006-02-13 18:21 -------

You can reproduce by checking out the gcc tree, and then removing the ada
directories, and trying to build with --enable-languages=c,c++.

-benjamin


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-13 18:23 -------
Yes you forgot to remove the library and tools directory for Ada.
This "bug" report is, doctor it hurts when I do this.  Doctor: Don't do it
then.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[gdr at integrable-solutions dot net]

------- Comment #4 from gdr at integrable-solutions dot net  2006-02-14 18:15 -------
Subject: Re:  --enable-languages=c,c++,fortran needs ada

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| Yes you forgot to remove the library and tools directory for Ada.

So what?  He did not ask for building Ada in --enable-languages.
Clearly this is a bug.  If I don't want to build C++, I don't have to
remove the language and front-end directory -- it suffices I don't ask
for C++ in --enable-languages.  Ada should not be any different.

| This "bug" report is, doctor it hurts when I do this.  Doctor: Don't do it
| then.

That is pure nonsense.

-- Gaby


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2006-02-14 18:19 -------
(In reply to comment #4)
> Subject: Re:  --enable-languages=c,c++,fortran needs ada
> 
> "pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> | Yes you forgot to remove the library and tools directory for Ada.
> 
> So what?  He did not ask for building Ada in --enable-languages.
> Clearly this is a bug.  If I don't want to build C++, I don't have to
> remove the language and front-end directory -- it suffices I don't ask
> for C++ in --enable-languages.  Ada should not be any different.

Lets look at what happens here.  The ada subdirectory in gcc was removed so the
toplevel configure did not know those libraries/programs are only to build when
ada is enabled.

The same goes for when removing the c++ subdirectory in gcc and libstdc++ is
still being built.
Likewise for libgfortran and the fortran subdirectory.

Ada is no different in this respect, in fact it just shows up more because more
people remove the subdirectory and not thinking about the toplevel directories
than say C++ or Java or Fortran.


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[gdr at integrable-solutions dot net]

------- Comment #6 from gdr at integrable-solutions dot net  2006-02-14 19:14 -------
Subject: Re:  --enable-languages=c,c++,fortran needs ada

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #4)
| > Subject: Re:  --enable-languages=c,c++,fortran needs ada
| > 
| > "pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
| > 
| > | Yes you forgot to remove the library and tools directory for Ada.
| > 
| > So what?  He did not ask for building Ada in --enable-languages.
| > Clearly this is a bug.  If I don't want to build C++, I don't have to
| > remove the language and front-end directory -- it suffices I don't ask
| > for C++ in --enable-languages.  Ada should not be any different.
| 
| Lets look at what happens here.  The ada subdirectory in gcc was
| removed so the toplevel configure did not know those
| libraries/programs are only to build when ada is enabled.

But the point is that the build machinery should not attempt to build
those libraries/programs when ada is not part of --enable-languages,
not just when the ada directory is present or absent.  The decision
should be based on --enable-languages, nto just absence or presence of
directory. 

| The same goes for when removing the c++ subdirectory in gcc and libstdc++ is
| still being built.

No.  If not language (e.g. c++) requiring libstdc++ is specified, its
build is not attempted, where the subdirectory is present or not.

-- Gaby


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-02-14 20:16 -------
(In reply to comment #6)
> But the point is that the build machinery should not attempt to build
> those libraries/programs when ada is not part of --enable-languages,
> not just when the ada directory is present or absent.  The decision
> should be based on --enable-languages, nto just absence or presence of
> directory. 
But the language subdirectories has this information in config-lang.in.
For an example ada/config-lang.in:

target_libs="target-libada"
lang_dirs="gnattools"


So What do you expect when removing the ada subdirectory?
C++ has the same issue:
target_libs="target-libstdc++-v3"

And it has been this way since 2000:
revision 1.8
date: 2000/12/12 20:28:51;  author: aoliva;  state: Exp;  lines: +3 -1
branches:  1.8.2;  1.8.10;  1.8.12;
* configure.in: Simplify language enabling/disabling code.
* configure: Rebuilt.
* ch/config-lang.in (target_libs): Set.
(build_by_default): Set to no.
* cp/config-lang.in (target_libs): Set.
* f/config-lang.in (target_libs): Set.
* java/config-lang.in (target_libs): Set.
* objc/config-lang.in (target_libs): Set.


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[gdr at integrable-solutions dot net]

------- Comment #8 from gdr at integrable-solutions dot net  2006-02-14 20:37 -------
Subject: Re:  --enable-languages=c,c++,fortran needs ada

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #6)
| > But the point is that the build machinery should not attempt to build
| > those libraries/programs when ada is not part of --enable-languages,
| > not just when the ada directory is present or absent.  The decision
| > should be based on --enable-languages, nto just absence or presence of
| > directory. 
| But the language subdirectories has this information in config-lang.in.
| For an example ada/config-lang.in:
| 
| target_libs="target-libada"
| lang_dirs="gnattools"

Yes, I understand that.  What I'm saying is that that file *enables*
program/libraries to build for ada target; so by default the build
machinery should not try to build anything that does not come from
implied config-lang.in.  In this case, since ada was not enabled, the
ada-related tools builds should not be attempted -- whether the
relevant config-lang.in is present or absent.

-- Gaby


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-02-14 20:46 -------
(In reply to comment #8)
> Yes, I understand that.  What I'm saying is that that file *enables*
> program/libraries to build for ada target; so by default the build
> machinery should not try to build anything that does not come from
> implied config-lang.in.  In this case, since ada was not enabled, the
> ada-related tools builds should not be attempted -- whether the
> relevant config-lang.in is present or absent.

Actually it does not enable the program/library for ada language, it says those
libraries are assiocated with the language and will be disable when the
language is not in --enable-languages=.  So when you
remove the directory and config-lang.in, you lose the ability to disable them
with --enable-languages=.

This is the opposite from what you think it does.  I bet there is a documention
failure here but I have not checked yet.


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2006-02-14 20:50 -------
(In reply to comment #9)
> This is the opposite from what you think it does.  I bet there is a documention
> failure here but I have not checked yet.

http://gcc.gnu.org/onlinedocs/gccint/Front-End-Config.html#Front-End-Config
lang_dirs
If defined, this variable lists (space-separated) top level directories
(parallel to gcc), apart from the runtime libraries, that should not be
configured if this front end is not built. 


So it looks like it is documented a little but maybe not as we should have it.


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[gdr at integrable-solutions dot net]

------- Comment #11 from gdr at integrable-solutions dot net  2006-02-14 21:11 -------
Subject: Re:  --enable-languages=c,c++,fortran needs ada

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Comment #10 from pinskia at gcc dot gnu dot org  2006-02-14 20:50
-------
| (In reply to comment #9)
| > This is the opposite from what you think it does.  I bet there is a
documention
| > failure here but I have not checked yet.
| 
| http://gcc.gnu.org/onlinedocs/gccint/Front-End-Config.html#Front-End-Config
| lang_dirs
| If defined, this variable lists (space-separated) top level directories
| (parallel to gcc), apart from the runtime libraries, that should not be
| configured if this front end is not built. 
| 
| 
| So it looks like it is documented a little but maybe not as we should have
it.

OK; that is odd (in terms of usability) but I guess a documentation
clarification is most certainly welcomed.

-- Gaby


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[bkoz at gcc dot gnu dot org]

------- Comment #12 from bkoz at gcc dot gnu dot org  2006-02-15 17:03 -------

Andrew. 

Perhaps the original post was not clear. You seem to be confused, in any case.
(And a bit melodramically hostile, but whatever, "el Doctor.") 

Here, try this:

cp gcc gcc.noada
cd gcc.noada
rm -rf gcc/ada libada

then try to build those sources with --enable-languages=c,c++. 

You'll find this build fails. Thus, I've reopened this bizarrely closed bug
report. Not only does this fail, but you will also find this is a regression.

Where does this fail, might you ask? Why, I'll tell you.

make[3]: Leaving directory
`/mnt/hd/bld/gcc.noada/build-i686-pc-linux-gnu/libiberty/testsuite'
make[2]: Leaving directory
`/mnt/hd/bld/gcc.noada/build-i686-pc-linux-gnu/libiberty'
yes
checking whether /mnt/hd/bld/gcc.noada/./gcc/xgcc
-B/mnt/hd/bld/gcc.noada/./gcc/
-B/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/bin/
-B/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/lib/ -isystem
/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/include -isystem
/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/sys-include supports
-Wmissing-format-attribute... yes
checking whether /mnt/hd/bld/gcc.noada/./gcc/xgcc
-B/mnt/hd/bld/gcc.noada/./gcc/
-B/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/bin/
-B/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/lib/ -isystem
/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/include -isystem
/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/sys-include supports -pedantic
-Wno-long-long... /bin/sh: line 0: cd:
/mnt/hd/src/gcc.noada/gnattools/../gcc/ada/: No such file or directory
yes
checking how to run the C preprocessor... /bin/sh: gnatls: command not found
make[2]: Entering directory `/mnt/hd/bld/gcc.noada/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.adb; ln -s
/mnt/hd/bld/gcc.noada/gnattools/mlib-tgt-linux.adb
../gcc/ada/tools/mlib-tgt.adb;  rm -f ../gcc/ada/tools/indepsw.adb; ln -s
/mnt/hd/bld/gcc.noada/gnattools/indepsw-linux.adb ../gcc/ada/tools/indepsw.adb;
touch ../gcc/stamp-tools
Cannot build gnattools while gnatlib is out of date or unbuilt
make[2]: *** [../gcc/stamp-gnatlib] Error 1
make[2]: Leaving directory `/mnt/hd/bld/gcc.noada/gnattools'
make[1]: *** [all-gnattools] Error 2
make[1]: *** Waiting for unfinished jobs....
/mnt/hd/bld/gcc.noada/./gcc/xgcc -B/mnt/hd/bld/gcc.noada/./gcc/
-B/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/bin/
-B/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/lib/ -isystem
/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/include -isystem
/mnt/hd/bld/H-x86-gcc.noada/i686-pc-linux-gnu/sys-include -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for stdlib.h... (cached) yes
checking for strings.h... (cached) yes
checking for unistd.h... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking sys/file.h usability... yes
checking sys/file.h presence... yes
checking for sys/file.h... yes
checking for sys/stat.h... (cached) yes
checking for clearerr_unlocked... yes
checking for feof_unlocked... yes
checking for ferror_unlocked... yes
checking for fflush_unlocked... yes
checking for fgetc_unlocked... yes
checking for fgets_unlocked... yes
checking for fileno_unlocked... yes
checking for fprintf_unlocked... no
checking for fputc_unlocked... yes
checking for fputs_unlocked... yes
checking for fread_unlocked... yes
checking for fwrite_unlocked... yes
checking for getchar_unlocked... yes
checking for getc_unlocked... yes
checking for putchar_unlocked... yes
checking for putc_unlocked... yes
checking whether abort is declared... yes
checking whether asprintf is declared... no
checking whether basename is declared... no
checking whether errno is declared... no
checking whether vasprintf is declared... no
checking whether clearerr_unlocked is declared... yes
checking whether feof_unlocked is declared... yes
checking whether ferror_unlocked is declared... yes
checking whether fflush_unlocked is declared... yes
checking whether fgetc_unlocked is declared... yes
checking whether fgets_unlocked is declared... no
checking whether fileno_unlocked is declared... yes
checking whether fprintf_unlocked is declared... no
checking whether fputc_unlocked is declared... yes
checking whether fputs_unlocked is declared... no
checking whether fread_unlocked is declared... yes
checking whether fwrite_unlocked is declared... yes
checking whether getchar_unlocked is declared... yes
checking whether getc_unlocked is declared... yes
checking whether putchar_unlocked is declared... yes
checking whether putc_unlocked is declared... yes
checking for an ANSI C-conforming const... yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking for mmap... yes
checking whether read-only mmap of a plain file works... yes
checking whether mmap from /dev/zero works... yes
checking for MAP_ANON(YMOUS)... yes
checking whether mmap with MAP_ANON(YMOUS) works... yes
checking whether to enable maintainer-specific portions of Makefiles... no
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: creating mkheaders.almost
config.status: creating config.h
make[1]: Leaving directory `/mnt/hd/bld/gcc.noada'
make: *** [all] Error 2
<bkoz@wells> /mnt/hd/bld/gcc.noada 


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2006-02-15 17:06 -------
gnattools is just like libada in the sense it needs also to be deleted too if
you delete libada and gcc/ada directories.

This is not really a regression except a regression in the scripts which don't
delete the correct stuff.  I wonder if the snapshots scripts are correct,
actually I know they are because I was able to build with gcc-core recently.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2006-02-15 17:09 -------
The wiki mentions what needs to be removed also:
http://gcc.gnu.org/wiki/SvnSetup

 $ svn switch svn+ssh://gcc.gnu.org/svn/gcc/emptydir libada
 $ svn switch svn+ssh://gcc.gnu.org/svn/gcc/emptydir gnattools
 $ svn switch svn+ssh://gcc.gnu.org/svn/gcc/emptydir gcc/ada
 $ svn switch svn+ssh://gcc.gnu.org/svn/gcc/emptydir gcc/testsuite/ada


See how gnattools is removed and also libada.


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++,fortran needs ada

[bkoz at gcc dot gnu dot org]

------- Comment #15 from bkoz at gcc dot gnu dot org  2006-02-15 17:22 -------
Andrew, thanks for the svn wiki pointer. 

I guess I'm left unimpressed at the current --enable-languages=c,c++ behavior
though. This flag should not be a hint! 

Right now, instead of --enable-languages doing something sensible, ie, building
the languages that are requested, it instead requires that the gcc developers
go through and strip out a random number of inconsistently named directories
for each language that they don't wish to build. This is insane.

-benjamin


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[bkoz at gcc dot gnu dot org]

------- Comment #16 from bkoz at gcc dot gnu dot org  2006-02-15 18:41 -------

Current behavior conflicts with docs:
http://gcc.gnu.org/install/configure.html

Andrew, please stop closing this.


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |
            Summary|--enable-                   |--enable-languages=c,c++ not
                   |languages=c,c++,fortran     |working as expected,
                   |needs ada                   |documented


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[pinskia at gcc dot gnu dot org]

------- Comment #17 from pinskia at gcc dot gnu dot org  2006-02-15 18:55 -------
Lets take a look at this again one more time.
You said you did "rm -Rf gcc/ada libada" but not "rm -Rf gnattools".

Where does it say in that documention what happens if you remove the gcc/ada
directory?
If it does say what happens I am missing it then.

You removed the gcc/ada directory which contained config-lang.in which tells
the build mechanism what toplevel directories are associated with the langauge
and what will be disabled when the language is disabled.  Since you did this,
the toplevel make files will always include gnattools so the build will fail as
expected as there is no way to tell the building mechanism to disable gnattools
when the ada language is enabled.

If you do "rm -Rf gcc/java libjava", then libffi will build always unlike the
previous behavior which was to build libffi only when java was enabled.

There might be an internal documention problem here but that is a totally
different issue from the orginal problem.  The internal documention does
document part of this as referenced in comment # 10.

I think there is a misunderstanding on how our build mechanism works and has
since at least 2000, just getting exposed now because more libraries/programs
are moving to the toplevel instead of living in their language subdirectory of
gcc.


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[gdr at integrable-solutions dot net]

------- Comment #18 from gdr at integrable-solutions dot net  2006-02-16 01:59 -------
Subject: Re:  --enable-languages=c,c++,fortran needs ada

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| ----------------------------------------------------------------------------
|              Status|UNCONFIRMED                 |RESOLVED
|          Resolution|                            |INVALID

Andrew --
  Please stop closing issues until you fully appreciate what people are
getting at.  The current behaviour does NOT make much sense.

  BTW, you don't need a poll on IRC about me and this issue, as I've
heard.  Thanks. 

-- Gaby


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[gdr at integrable-solutions dot net]

------- Comment #19 from gdr at integrable-solutions dot net  2006-02-16 02:00 -------
Subject: Re:  --enable-languages=c,c++,fortran needs ada

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| The wiki mentions what needs to be removed also:
| http://gcc.gnu.org/wiki/SvnSetup

The Wiki is nice and helpful but it is not GCC official
documentation.  If there is any documented behaviour it should be part
of GCC.  If the documented behaviour does not make any sense, it
should be changed.

-- Gaby


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[gdr at integrable-solutions dot net]

------- Comment #20 from gdr at integrable-solutions dot net  2006-02-16 02:01 -------
Subject: Re:  --enable-languages=c,c++,fortran needs ada

"bkoz at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| I guess I'm left unimpressed at the current --enable-languages=c,c++ behavior
| though. This flag should not be a hint! 

Fully agreed.  This issue should be reopened and the current behaviour
be improved.

-- Gaby


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[gdr at gcc dot gnu dot org]

-- 

gdr at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-02-16 02:02:15
               date|                            |


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[gdr at integrable-solutions dot net]

------- Comment #21 from gdr at integrable-solutions dot net  2006-02-16 02:05 -------
Subject: Re:  --enable-languages=c,c++ not working as expected, documented

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| I think there is a misunderstanding on how our build mechanism works and has
| since at least 2000,

since when it started working like that does not make it less than a
bug.  I had the same understanding as Benjamin when I saw the PR; then,
walking through the steps just convinces me that the current behaviour
is useless.  It does not matter since when it was like that.

-- Gaby


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[pinskia at gcc dot gnu dot org]

------- Comment #22 from pinskia at gcc dot gnu dot org  2006-02-16 02:07 -------
How would you guys design this?
Have configure do all the work?
What happens when someone wants to add a new language, do you have to update
configure?
Why should that happen, that is just extra work.
The behavior that is happening here is the same behavior that actually does
make sense as the language configuration is done in config-lang.in and nowhere
else (well Ada is special in that it has some code in the toplevel configure
but no other language is that special).

Lets look at what Ben did, he remove the library and ada language directories
without removing the Ada runtime programs directory which means it will always
build the runtime programs.

If I remove the gcc/cp directory, libstdc++ will always be built.

This is invalid as this is how the build system is done.

If you guys want it changed, write to the list instead of writting into this
bug as the build maintainers don't read the bug reports that much (or even
patches lately).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at gcc dot gnu dot org
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[pinskia at gcc dot gnu dot org]

------- Comment #23 from pinskia at gcc dot gnu dot org  2006-02-16 02:12 -------
By the way the patch which actually fixed the behavior to this behavior:
http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00602.html

Note before this patch all target libraries were build so this is not a
regression or even a bug.


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[pinskia at gcc dot gnu dot org]

------- Comment #24 from pinskia at gcc dot gnu dot org  2006-02-16 02:18 -------
GDR you commented on this before:
http://gcc.gnu.org/ml/java/2000-12/msg00174.html

Back when the patch was created did you forgot about removing directories now?

Since Ben is removing directories in the first place, this is the reason why
this is invalid and not because gnattools is being built even with
--enable-language=c++.


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[gdr at integrable-solutions dot net]

------- Comment #25 from gdr at integrable-solutions dot net  2006-02-16 14:49 -------
Subject: Re:  --enable-languages=c,c++ not working as expected, documented

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| How would you guys design this?

That was explained in the several messages we sent.

| Have configure do all the work?

No.  We would like configure not to be overzealous.

| What happens when someone wants to add a new language, do you have to update
| configure?

No, on the contrary.

[...]

|              Status|NEW                         |RESOLVED
|          Resolution|                            |INVALID

You seem to be toally confused and unable to understand the issue.
For the nth time, please stop closing this issue.

-- Gaby


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[gdr at integrable-solutions dot net]

------- Comment #26 from gdr at integrable-solutions dot net  2006-02-16 14:52 -------
Subject: Re:  --enable-languages=c,c++ not working as expected, documented

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| GDR you commented on this before:
| http://gcc.gnu.org/ml/java/2000-12/msg00174.html

good.  So you understand that building things that are not asked for
was considered at best annoying back then.

| Back when the patch was created did you forgot about removing
| directories now? 

so does it make it less issue today?  Please stop being silly.

-- Gaby


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[gdr at gcc dot gnu dot org]

------- Comment #27 from gdr at gcc dot gnu dot org  2006-02-16 14:54 -------
see comment #12.


-- 

gdr at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented

[pinskia at gcc dot gnu dot org]

------- Comment #28 from pinskia at gcc dot gnu dot org  2006-02-16 15:09 -------
(In reply to comment #24)
> Since Ben is removing directories in the first place, this is the reason why
> this is invalid and not because gnattools is being built even with
> --enable-language=c++.

Again this has nothing to do with the real behavior of the options since they
are acting like they should as there is no way for the configure to tell
gnattools is for Ada only.

Again this bug is about removing two directories and then trying to build
without removing the thrid, it goes wrong.  If someone removes gcc/cp,
libstdc++ will always be built because there is no way for the build mechanism
to recognize that libstdc++ belongs to building only with c++ turned on.  This
case is no different.

Closing as works for me since Benjamin removed directories to begin with.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WORKSFORME


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented when removing gcc/ada and libada but not gnattools

[gdr at gcc dot gnu dot org]

------- Comment #29 from gdr at gcc dot gnu dot org  2006-02-16 15:30 -------
(In reply to comment #28)
> (In reply to comment #24)
> > Since Ben is removing directories in the first place, this is the reason why
> > this is invalid and not because gnattools is being built even with
> > --enable-language=c++.
> 
> Again this has nothing to do with the real behavior of the options since they
> are acting like they should as there is no way for the configure to tell
> gnattools is for Ada only.

It is good that configure cannot tell whether gnattools is for Ada only.
What the issue is about is that gnattools (or any other component in similar
situations) should not be set to be built by default and relying on the
presence of a directory to tell whether it should be disabled or enabled.


> Again this bug is about removing two directories and then trying to build

You're totally confused.  The bug really is about components being built
when they are not asked for.  "removing two directories" is just a way
to trigger the behaviour.
Since you're unable to appreciate that point, you have earn the right NOT
to touch this PR.  Please concentrate your helping effort on other issues.
You're NOT being helpful here.


-- 

gdr at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2006-02-16 02:02:15         |2006-02-16 15:30:19
               date|                            |


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented when removing gcc/ada and libada but not gnattools

[pinskia at gcc dot gnu dot org]

------- Comment #30 from pinskia at gcc dot gnu dot org  2006-02-16 15:37 -------
(In reply to comment #29)
> > Again this bug is about removing two directories and then trying to build
> 
> You're totally confused.  The bug really is about components being built
> when they are not asked for.  "removing two directories" is just a way
> to trigger the behaviour.

Actually the components were asked for since gnattools was not associated with
any language after the removal of gcc/ada.


> Since you're unable to appreciate that point, you have earn the right NOT
> to touch this PR.  Please concentrate your helping effort on other issues.
> You're NOT being helpful here.

I have been helpful by saying why it is not working the way you want it to be
working.  This is how the building works.  Removing the language subdirectory
causes libraries and directories not be associated with a language, how clear
is that?  config-lang.in is how you associate the directories with the
language.  In fact the only reason why it is showing up more is that more
directories are being associated with languages.  In fact before 2000, there
was no way which caused --enable-languages=c++ to build also libobjc and
libjava.


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented when removing gcc/ada and libada but not gnattools

[gdr at gcc dot gnu dot org]

------- Comment #32 from gdr at gcc dot gnu dot org  2006-02-16 15:53 -------
.


-- 

gdr at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2006-02-16 15:30:19         |2006-02-16 15:53:43
               date|                            |


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented when removing gcc/ada and libada but not gnattools

[gdr at integrable-solutions dot net]

------- Comment #31 from gdr at integrable-solutions dot net  2006-02-16 15:53 -------
Subject: Re:  --enable-languages=c,c++ not working as expected, documented when
removing gcc/ada and libada but not gnattools

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #29)
| > > Again this bug is about removing two directories and then trying to build
| > 
| > You're totally confused.  The bug really is about components being built
| > when they are not asked for.  "removing two directories" is just a way
| > to trigger the behaviour.
| 
| Actually the components were asked for since gnattools was not
| associated with any language after the removal of gcc/ada.

That is wrong.  The component should be asked for because that
decision is derived from the --enable-languages setting, not because
gcc/Ada is missing.  That is what the defect is about.  See Benjamin's
comment #15.

| > Since you're unable to appreciate that point, you have earn the right NOT
| > to touch this PR.  Please concentrate your helping effort on other issues.
| > You're NOT being helpful here.
| 
| I have been helpful by saying why it is not working the way you want it to be
| working.  This is how the building works.

yes, you have been saying how it works, not *why* it should work that
way.  The PR acknowledges how it is currently working; the PR is
saying that that current behaivour is not very helpful and should be
improved.  Please take a deep breath and explore that path.  Is it
really helpful or useful it wokrs the way it currently is?  Can it be
improved?   While exploring that path, don't consider the current
behaviuour "God given".

-- Gaby


-- 


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

[Bug bootstrap/26259] --enable-languages=c,c++ not working as expected, documented when removing gcc/ada and libada but not gnattools

[gdr at gcc dot gnu dot org]

------- Comment #33 from gdr at gcc dot gnu dot org  2006-02-16 15:56 -------
.


-- 

gdr at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |


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

[Bug bootstrap/26259] 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]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
            Summary|--enable-languages=c,c++ not|toplevel directories should
                   |working as expected,        |be assocaited at the
                   |documented when removing    |toplevel with a language
                   |gcc/ada and libada but not  |being built instead of with
                   |gnattools                   |a subdirectory of gcc


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

[Bug bootstrap/26259] 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 #34 from pinskia at gcc dot gnu dot org  2006-02-16 16:11 -------
This bug was orginally opened and not really explaining what happened until
comment #2 and even then it was really "You tell the doctor, it hurts when I do
this and the doctor explains, do not that then".  The reason for that reason
was simple, this is how it works.  Now if the person was not removing gcc/ada,
it would be a different issue but since it is removal of this directory which
caused it, it is not a matter of what is the correct behavior for documented
behavior (as it is documented that config-lang.in controls the association).

This is a dup of bug 26323 which explains what really wants to be changed
instead of going in circuls of the current correct behavior.

*** This bug has been marked as a duplicate of 26323 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug bootstrap/26259] 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 #35 from pinskia at gcc dot gnu dot org  2006-02-16 16:11 -------
(In reply to comment #34)
> This is a dup of bug 26323 which explains what really wants to be changed
> instead of going in circles of the current correct [documented] behavior.


-- 


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