[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem is CC environment var. (was Re: Something screwed up in PROJECT_ROOT or PROJECT_TOPdir)
- Date: Mon, 21 Feb 2005 09:52:58 -0500
- From: Peter Dufault <dufault at hda dot com>
- Subject: Re: Problem is CC environment var. (was Re: Something screwed up in PROJECT_ROOT or PROJECT_TOPdir)
On Feb 21, 2005, at 8:08 AM, Ralf Corsepius wrote:
... I would not exclude handling of CC to be broken in RTEMS toplevel
configure script, but similar to other problems you are reporting, I
can't reproduce them, nor am I aware of any problem related to setting
I'll set up a Linux system to try to reproduce them. As I said, maybe
the GNU M4 stack corruption is present but not being detected - it is
stackovf.c detecting the stack corruption and aborting.
I applied the automake patch, which is still required in the very
latest automake, that bug report should be updated to point that out.
Unfortunately I still can't build without --enable-multilib after
getting rid of "CC" and applying the automake patch - I still wind up
with the -isystem headers in the wrong place in the tree, one level too
What is your top_builddir, MULTIBUILDTOP and PROJECT_INCLUDE in your
Makefile if you build, for example, "psim" without --enable-multilib?
I wind up with:
top_builddir = .
which, when run from rtems-4.7/powerpc-rtems/c/psim/cpukit, is
rtems-4.7/psim/lib/include, the wrong result.
I'll build now with --enable-multilib, and in a few hours I'll know if
I can now get all the way through the build.
It may seem like a lot of problems, but it has boiled down to:
Stack corruption detected by M4 wrecking the bootstrap;
-isystem headers go in the wrong place unless I specify
Using "CC" in environment instead of "CC_FOR_TARGET" and "CC_FOR_HOST".
HD Associates, Inc.