Re: [MinGW] Set NATIVE_SYSTEM_HEADER_DIR relative to configured prefix

[Bob Rossi <bob_rossi at cox dot net>]

On Mon, Dec 18, 2006 at 12:47:40PM -0800, Brian Dessent wrote:
> Bob Rossi wrote:
> 
> > If I try to compile 'gcc -o main main.c' it can't find stdio.h. If I try
> > to compile 'g++ -o main main.cpp' it can't find iostream.
> > 
> > If I then untar the mingw-runtime and the w32api into the C:/mingw
> > directory both the gcc and g++ commands find the header files, however,
> > they end with this error,
> 
> Uh, you do realize that stdio.h is not part of gcc right?  So it will
> *never* work if all you do is copy over gcc.  Having mingw-runtime and
> w32api present are absolutely positively always required for a working
> MinGW compiler, period.  This would be the analogue of having no libc
> headers on a *nix system, it just won't work.

/me slams my head into the desk. I thought the c and c++ headers came
with the compiler. Your explanation above is helpful. I'm assuming the
trick I was doing earlier with sysroot somehow helps solve the problem
where the user unpacking gcc no longer has to also unpack the
mingw-runtime and the w32api.

> > BTW, if I run on the machine I compiled gcc, this command,
> >   PATH=/home/bobbybrasko/gcc/destdir/mingw/bin:$PATH gcc -o main main.c
> > it works. However, if I run this command
> >   PATH=/home/bobbybrasko/gcc/destdir/mingw/bin:$PATH g++ -o main main.cpp
> > it doesn't work.
> >   main.cpp:1:20: error: iostream: No such file or directory
> >   main.cpp: In function 'int main(int, char**)':
> 
> Putting aside the idea of a relocatable compiler for a moment, you
> appear to be confused about DESTDIR.  This is meant to be used to
> install files to a *temporary* staging location.  You should never try
> to run them from there.  They will only work when they are located in
> the place specified by prefix.

Ugh, yes, I was confused. Ok, this is good news, since this is what I've
reverted to. I'm now building with --prefix=/mingw and using DESTDIR and
then tarring that up, and untarring on another machine in C:\mingw.

I'm compiling from dos, on this new machine, hopefully C:\mingw and
/mingw are the same?

> Now, in the specific case of the MinGW target, there is supposed to be
> code in the driver that locates everything relative to the binaries
> rather than using the configured absolute paths, so that the above
> restriction is lifted.  But it would seem that either this code has
> bitrotted or something else is wrong.

OK, I'm currently building 3.4.2 to make sure I'm not going insane. This
should be doable, since it's been done by Danny. This seems to be a good
starting point. The downside is, Ranjit Mathew said he has got this
working with 4.1 releases. I just can't reproduce his work.

Once a solution is created for this, i'd be happy to automate this on
the weekly snapshots, so that it doesn't bitrot again.

Bob Rossi