This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
PR4114, 4113, 4082, 4078, (part of) 4096 plus other reports in gcc-bugs
- To: libstdc++ at gcc dot gnu dot org
- Subject: PR4114, 4113, 4082, 4078, (part of) 4096 plus other reports in gcc-bugs
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Date: Fri, 24 Aug 2001 16:48:11 -0500 (CDT)
- CC: ungaro at pegasus dot fmrp dot usp dot br, partain at dcs dot gla dot ac dot uk, ajhood at fl dot net dot au, Hermann dot Rochholz at faidor dot de, gcc-bugs at gcc dot gnu dot org, karl at gnu dot org, bkoz at gcc dot gnu dot org, rkl at connect dot org dot uk, apiszcz at mitre dot org
- Reply-to: rittle at labs dot mot dot com
[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
- Follow-Ups:
- Re: PR4114, 4113, 4082, 4078, (part of) 4096 plus other reports in gcc-bugs
- Re: PR4114, 4113, 4082, 4078, (part of) 4096 plus other reports in gcc-bugs
- Re: PR4114, 4113, 4082, 4078, (part of) 4096 plus other reports in gcc-bugs
- Re: PR4114, 4113, 4082, 4078, (part of) 4096 plus other reports in gcc-bugs