This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Disable bprob.exp for cross targets
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Eric Christopher <echristo at redhat dot com>
- Cc: Joern Rennecke <joern dot rennecke at superh dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 1 Oct 2003 00:44:23 -0400 (EDT)
- Subject: Re: [PATCH] Disable bprob.exp for cross targets
On Tue, 30 Sep 2003, Eric Christopher wrote:
> > So it seems a wart in the gcc build process to not be able to
> > handle this, but instead requiring installed headers to fulfill
> > the dependency for building the full libgcc. I guess libgcc
> > should be moved to toplevel, and depend on maybe-newlib or
> > something. (Huh, we're slowly getting the same maze of
> > dependencies as when building gcc+glibc.)
> We need the headers to build libgcc to begin with.
No, not at all.
I built for mn10300-elf to check what happens for a vanilla ELF
target and not just rely on my memory. This was in a tree a
couple of weeks old. Newlib in the tree causes these options to
be used by the target gcc:
but $BUILDDIR/mn10300-elf doesn't exist when gcc (and libgcc) is
built. Still it works, so at least for mn10300, none of the
target-specific files are included. Since any target-specific
files would be included from generic newlib files, it seems the
same goes for other newlib targets. I looked, and except for
cygwin, I didn't see any target-specific #includes in
Then I thought "what happens without -Dinhibit_libc" and added a
":" in front of inhibit_libc being set in gcc/configure. *The
toolchain still built*, now with a few less warnings from
libgcc about undeclared functions and a new from libgcov about a
missing declaration of ftruncate. ;-)
Conclusion: -Dinhibit_libc can be left out for current in-source
newlib. Since there are other assumptions on newlib and gcc
always being in sync, I think that for newlib -Dinhibit_libc can
be taken out generally.
I also tried --without-newlib with newlib still in the tree
which gets rid of the options above (and should cause newlib and
libgloss not to be built), and gcc and libgcc still built,
thanks to -Dinhibit_libc.
Things broke down later, trying to build libgloss(!), because of
a configure bug: --without-newlib sets skipdirs but the
machinery that excludes libgloss when no newlib is to be built
only looks at noconfigdirs.
> Unless libgcov
> requires libc too?
Nope, apparently not, but it seems it needs headers.