This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: a mudflap experiment on freebsd
- From: Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>
- To: GCC Development <gcc at gcc dot gnu dot org>, wilson at specifixinc dot com
- Date: Wed, 23 Feb 2005 10:00:07 +0100
- Subject: Re: a mudflap experiment on freebsd
- References: <1109136952.23448.19.camel@aretha.corp.specifixinc.com>
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