Re: GCC-TM dependency build

Re: GCC-TM dependency build

[Richard Henderson]

On 04/08/2010 09:59 AM, Aldy Hernandez wrote:
> The problem is that now the problem is present on a serial make (ala,
> "/src/configure && make").

I've reliably reproduced this.  As far as I can tell, it's a problem
of makefile variable expansion in the top-level make.

For the folks just joining in gcc@, the problem is in the building of
libitm on the transactional-memory branch.  Libitm is written in C++,
and uses <cassert>.

On the *first* invocation of make, the value of CXX_FOR_TARGET that is
passed down to the libitm sub-make does *not* include the -I flags for
the appropriate libstdc++ directories, and so <cassert> is not found
and results in the obvious build error.  This failure can apparently
be masked by having an existing installation at PREFIX (which is I 
suppose why it took me so long to see the problem).

On the *second* invocation of make, the value of CXX_FOR_TARGET *does*
include the appropriate -I flags and compilation succeeds.

This failure does not appear for libjava, the only other c++ library,
because it only uses the C headers (<ctype.h> etc) instead of the C++
wrapper headers (<cctype>).  It doesn't *really* use libstdc++ at all.

As best I can figure, this...

> GCC_TARGET_TOOL(c++, CXX_FOR_TARGET, CXX,
>                 [gcc/g++ -B$$r/$(HOST_SUBDIR)/gcc/ -nostdinc++ `test ! -f $$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags || $(SHELL) $$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags --build-includes` -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs],
>                 c++)

... gets expanded too early in the make process.  During the first
invocation of make the testsuite_flags script does not yet exist,
and the variable is not re-evaluated after configure-target-libstdc++-v3.

I have no idea how to fix this.  Ideas?


r~

Re: GCC-TM dependency build

[Jonathan Wakely]

On 9 April 2010 17:00, Richard Henderson wrote:
>
> I have no idea how to fix this.  Ideas?

Maybe a dumb question, I don't know the context of this problem...

Is <cassert> the only C++ header that causes a problem?

<cassert> is exactly equivalent to <assert.h> because it only declares
macros, which are not in namespace std anyway.

So if that's the only problem, using <assert.h> instead of <cassert>
would solve it.

Re: GCC-TM dependency build

[Richard Henderson]

On 04/09/2010 03:16 PM, Jonathan Wakely wrote:
> Is<cassert>  the only C++ header that causes a problem?
>
> <cassert>  is exactly equivalent to<assert.h>  because it only declares
> macros, which are not in namespace std anyway.
>
> So if that's the only problem, using<assert.h>  instead of<cassert>
> would solve it.

No, we also use <type_traits>, so avoiding the C wrapper headers
doesn't really help.


r~