This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

PR4114, 4113, 4082, 4078, (part of) 4096 plus other reports in gcc-bugs


[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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]