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~
