Problem is CC environment var. (was Re: Something screwed up in PROJECT_ROOT or PROJECT_TOPdir)

[Peter Dufault]

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 = .
MULTIBUILDTOP =
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

Peter Dufault
HD Associates, Inc.