PR4114, 4113, 4082, 4078, (part of) 4096 plus other reports in gcc-bugs
Loren James Rittle
rittle@latour.rsch.comm.mot.com
Fri Aug 24 14:49:00 GMT 2001
[I have tried to CC everyone that has been reporting this issue.]
Benjamin, I was happy that you assigned the PR to me since I had been
meaning to take a close look at this issue. I have gone through and
closed all related PRs with a pointer to PR4082. The main reason I
had not yet is that until PR4113, people were not reporting exactly
how they were configuring their gcc source tree (although I was
beginning to guess at the problem).
All these reports are all caused by people running configure in
$(srcdir). This is explicitly documented in
libstdc++-v3/docs/html/install.html as the wrong thing to do:
``<LI><EM>gccbuilddir</EM>: The build directory for the compiler in
<EM>gccsrcdir</EM>. GCC requires that it be built in a different
directory than its sources.''
However, most people don't even know they need to read that file
before they bootstrap top-level.
gcc/doc/install.texi, as should have been shipped with 3.0 and 3.0.1
(and I believe it did), says this a bit less forcefully and disagrees
with our assessment in libstdc++-v3 (in that is says it might actually
work):
``First, we @strong{highly} recommend that GCC be built into a
separate directory than the sources which does @strong{not} reside
within the source tree. This is how we generally build GCC;
building where @var{srcdir} == @var{objdir} should still work, but
doesn't get extensive testing; building where @var{objdir} is a
subdirectory of @var{srcdir} is unsupported.''
I did advocate that we document libstdc++-v3's stronger requirement in
the top-level documentation before the 3.0 release but it was never
done. Perhaps configuring in $(srcdir) actually semi-worked for the
3.0 release (at least it didn't break bootstrap). I can almost
guarantee that I never configure in $(srcdir) since you get all sorts
of trash in your CVS working tree... I surely didn't test the jumbo
patch which created libstdc++-v3/include/Makefile.am with that style
of in-source tree configuration. Did anyone?
The question is: How do we clean this mess up? At this point, I don't
even see what is wrong with include/Makefile.am .
Regards,
Loren
More information about the Gcc-bugs
mailing list