This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Failure in a complete build of current gcc snapshot
- From: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>
- To: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- Cc: Angelo Graziosi <angelo dot graziosi at alice dot it>, GCC <gcc at gcc dot gnu dot org>
- Date: Sun, 26 Jul 2009 09:46:34 +0200
- Subject: Re: Failure in a complete build of current gcc snapshot
- References: <4A698B34.4000906@alice.it> <4A6B7DD7.3050703@alice.it> <4A6BA29D.2040105@gmail.com>
* Dave Korn wrote on Sun, Jul 26, 2009 at 02:26:05AM CEST:
> Angelo Graziosi wrote:
> >> make[4]: Nothing to be done for `install-exec-am'.
> >> test -z "/usr/local/gfortran/share/gcc-4.5.0/python" || mkdir -p --
> >> "/tmp/inst/usr/local/gfortran/share/gcc-4.5.0/python"
> >> /bin/sh: line 0: cd: /usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.5.0:
> >> No such file or directory
>
> Notice here how it tests for the real install dir, then if it doesn't exist
> it creates the DESTDIR-prefixed version, then it tries to cd into the real one
> and fails. That's definitely a bug there.
Not really. It tests whether the variable that contains the real
install dir has empty contents. 'test -z' is a simple string test.
This can happen in some situations automake has no control over, so
it needs a runtime test here.
One bug is that in libstdc++-v3/python/Makefile.am, in the
install-data-local rule, the code tries to cd to $(toolexeclibdir)
which is nonsensical. It needs to use $(DESTDIR)$(toolexeclibdir).
The other bug (the one about libstdc++*) also seems within that rule,
but I don't see it yet.
Is there a PR for this issue?
Thanks,
Ralf