I think the decision to force the user to specify -lmudflap should be revisited.
I agree.
The fixincludes build failed with link errors for undefined mudflap functions. The fixincludes Makefile.in does not use CFLAGS when linking. I added $(CFLAGS) to the 3 rules that contain a link command.
I think this can be committed as obvious, especially by a GWP person as you are...
I now get a configure failure in the intl directory. configure is unable to run programs compiled by $CC. I gets an error from the dynamic linker complaining that libgcc.so can't be found. The problem here is that the toplevel Makefile support for LD_LIBRARY_PATH is confused. See the SET_GCC_LIB_PATH support.
It is completely broken. If you modify configure.ac, and make from within the GCC directory, the LD_LIBRARY_PATH will not even include the GCC directory. I have a patch queued for 4.1 for this, but I want to see the PRs and try to reproduce the problem.
I don't think it is a requirement to only run make from within the toplevel, even if TARGET-* variables alleviate the problem.
! /* We must allocate one more entry here, as we use NOTE_INSN_MAX as the
! default field for line number notes. */
! static const char *const note_insn_name[NOTE_INSN_MAX+1] = {
I think this also ought to be committed.
Paolo
