other/346: gcc install clobbers files that it shouldn't touch

[tv at duh dot org]

>Number:         346
>Category:       other
>Synopsis:       gcc install clobbers files that it shouldn't touch
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 23 10:16:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Todd Vierling
>Release:        gcc-2.96-200006xx, gcc-2.95.x, egcs-1.2-1999xxxx
>Organization:
>Environment:
Any
>Description:
I'm going to apologize beforehand for the sternness of this writing; the
reason for this is described in the [VENT] section at bottom.

At installation, the following files clobber anything in their path, and do
not belong in the places they are installed, in many situations:

- _G_config.h and assert.h are being written to $(gcc_tooldir)/include, even
though they are *compiler specific*:  these belong in $(libsubdir)/include.  
In the target-specific dir, this means that you cannot use two different
compiler versions with the same include tree.  [Note that assert.h does
check whether the version is from gcc or not; however, what about multiple
gcc versions?]

- The libsdtc++ v2 includes [I haven't checked v3 yet] are being written to
$(includedir), aka $(prefix)/include, even in the cross-compile case.  Not
only does this prevent using different compiler revisions with one target,
it also prevents different compiler levels with ANY target.  These C++
includes are *compiler specific* and belong in $(libsubdir)/include,
probably by default.

- And lastly, libstdc++.a.2.10.0 is going into $(prefix)/lib even in the
cross compile case.  The problem with installing in that location should be
flatly obvious.  The name libstdc++.a even exists in $(libsubdir)--as a
*symlink* to the one in $(prefix)/lib!

...

[VENT MODE="long-term-exasperation"]

Not all of us use one target per $(prefix), one type of compiler per target
library tree, or even one level of a compiler per target.  GCC is supposed
to be able to coexist with other GCC instances.  That's why $(libsubdir)
exists, and why this directory pre-empts other "standard" target include and
library directories.  If GCC isn't going to put all of its support stuff into
$(libsubdir), why does that _facade_ of an abstraction exist in the first
place?

IMNSHO, GCC should never, ever write anything to the target's include and
lib directories; and when creating a cross-compiler, never write to host
system visible directories.  GCC may need to override some things, with
fixincludes and whatnot (and, again, $(libsubdir) exists for precisely this
purpose), but it should be perfectly possible to install gcc with a
read-only filesystem mounted on $(prefix)/arch-vendor-target.

Now, I'm happy to create autoconfed switches to allow for this type of
installation and submit such changes, and the gcc maintainers certainly
don't have to make use of the switches, but I'd like to receive a rational,
non-brush-off, response to this bug report first.  The last several times
I've reported this, I received nothing but "It works for us, and we like
it this way, so go away" type of responses from Cygnus.

I hope responses to this PR won't be so rude.

[/VENT]
>How-To-Repeat:
$ cd gcc-2000xxxx; mkdir builddir; cd builddir
$ ../configure --target=some-other-system
$ make all install LANGUAGES="c c++"

Observe that files are in /usr/local/include, /usr/local/lib, and
/usr/local/some-other-system/include that should not be there.
>Fix:
I am happy to provide a fix with configure.in/Makefile.{in,am} diffs, but I
need confirmation that such fix would be accepted by the gcc maintainers
before wasting the effort.  See also, [VENT] under Description.
>Release-Note:
>Audit-Trail:
>Unformatted: