Bug 346 - gcc install clobbers files that it shouldn't touch
Summary: gcc install clobbers files that it shouldn't touch
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 2.95
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
: 38628 (view as bug list)
Depends on: 7305 18244 23935 25938 26473 29205 40289 47484
  Show dependency treegraph
Reported: 2000-06-23 10:16 UTC by tv
Modified: 2014-11-08 11:15 UTC (History)
5 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2005-12-28 06:28:04


Note You need to log in before you can comment on or make changes to this bug.
Description tv 2000-06-23 10:16:00 UTC
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

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.


gcc-2.96-200006xx, gcc-2.95.x, egcs-1.2-1999xxxx


$ 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.
Comment 1 tv 2000-06-23 10:16:00 UTC
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.
Comment 2 Joseph S. Myers 2002-01-07 06:50:38 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed that this problem still applies with current mainline GCC CVS.
    I thought that this PR had been priority "high" at some point;
    it seems to have been quietly downgraded, presumably on the
    basis that it wasn't a regression; I've made it priority "high" again
    since it's still a serious problem that ought to be fixed rather
    than ignored.
Comment 3 Andrew Pinski 2003-05-27 23:13:37 UTC
I think the headers of libstdc++ is fixed but since gcj is added, that should be added in 
this bug.  I also think the _G_config.h and assert.h are fixed.

libraries are still in ${prefix}/lib, do not know about cross-compiler case, though.
Comment 4 Andrew Pinski 2003-06-13 02:42:48 UTC
Libgcj's bug dealing with this is bug 7305 which I marked as a bug that this depends on.
Comment 5 rsandifo@gcc.gnu.org 2004-12-03 11:33:27 UTC
The libgcj thing should be fixed now.  Are there any other
problems that would stop us closing this PR?
Comment 6 Steven Bosscher 2005-04-27 23:54:29 UTC
Can someone comment on the status of this bug? 
Comment 7 Andrew Pinski 2005-05-01 14:01:27 UTC
libmudflap does the same thing, see PR 18244.
Comment 8 Simon Brenner 2008-11-25 23:24:08 UTC
So, all issues mentioned in this bug are fixed, and related issues all have their own bugs? I think we should just close this one and ping/reconfirm/close bug 18244...
Comment 9 Joseph S. Myers 2010-05-22 18:00:52 UTC
*** Bug 38628 has been marked as a duplicate of this bug. ***
Comment 10 Manuel López-Ibáñez 2014-11-08 11:15:42 UTC
I'll go ahead and close this as everything originally reported seems to have been fixed. If there are further issues, a new bug should be opened with a clear list of files clobbered. The most recent duplicate about this was about -V not working and that got fixed.