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

[Alexandre Oliva <aoliva at redhat dot com>]

On Aug 24, 2001, Loren James Rittle <rittle@latour.rsch.comm.mot.com> wrote:

> Benjamin, I was happy that you assigned the PR to me since I had been
> meaning to take a close look at this issue.

Me too.  I had been meaning to look into it too, because I knew
exactly what the problem was, but I haven't had the time to get to it
yet.  Since you're now the happy owner of the PR, I'll clue you into
the problem, and hopefully you'll be able to beat to fixing it.

> 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 .

The problem is that it uses glibcpp_srcdir to access files outside
libstdc++-v3's tree, expecting gcc to be a sibling of libstdc++-v3.
Unfortunately, when srcdir=., our smart build machinery duplicates the
top-level source tree into the target directory, so that:

<target>/[multilibdirs]libstdc++-v3/foo -> ../../[...]libstdc++-v3/foo

You're probably wondering why.  Think, for example, of libiberty: it's
built for the host in <toplevel_builddir>/libiberty and for the target
in <toplevel_builddir>/<target_alias>/[multilib]libiberty.  When
srcdir=builddir, you'd get libiberty configured in the top-level
directory for the host build.  Then, when the time came for the target
build, configure would fail because the source dir was already
configured.  So, we create these links and configure in-place too.
The second reason for these links is the assumption that, if you're
building with srcdir=builddir, it's because your make doesn't properly
support VPATH builds.  This doesn't matter for GCC these days, since
we decided that a POSIX-compliant make is required, but there was a
time when we supported them, and this trick worked quite well.
Anyway, it can't be dropped unless we also drop the ability to build
in the source tree.  I recall having done a lot of work to make sure
GCC 3.0 could build in the source tree (even though it wouldn't
install; shame on me :-(  I had planned to do it before 3.0.1 too, but
I didn't have time (more shame on me :-)  Anyway, the damage is done,
and we should attempt to fix this for 3.0.2.

The solution is to base references to sibling directories in
toplevel_srcdir (defined in libstdc++-v3's configure.in): it points to
the actual top-level directory, regardless of whether srcdir is a full
or relative pathname, or whether we're in a linked-mirror of the
source tree or doing a VPATH build.


As for clobbering the source tree in order to test this stuff, you may
use symlink-tree to create a mirror of the source tree and then build
in it, so it won't affect the actual source tree.  A better (IMO)
alternative, in case you have spare disk space and write permissions
in the filesystem containing the source tree, is to use this
shell-script instead:

duptree

I believe the only reason why it uses bash instead of any Bourne shell
is that `test -e' is a built-in in bash, and not supported by some
external `test' programs.  Besides, running an external `test' would
make this script way slower.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me