[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)

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 up CC.

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 high.

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 = .
PROJECT_INCLUDE = $(top_builddir)/../$(MULTIBUILDTOP)//../../../psim/lib/include

or: ../../../../psim/lib/include

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 --enable-multilib;
Using "CC" in environment instead of "CC_FOR_TARGET" and "CC_FOR_HOST".


Peter Dufault
HD Associates, Inc.