This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
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] Release: gcc-2.96-200006xx, gcc-2.95.x, egcs-1.2-1999xxxx Environment: Any 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.
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.
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.
Libgcj's bug dealing with this is bug 7305 which I marked as a bug that this depends on.
The libgcj thing should be fixed now. Are there any other problems that would stop us closing this PR?
Can someone comment on the status of this bug?
libmudflap does the same thing, see PR 18244.
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...