Re: Fwd: Re: later w32api package required to build cygwin

[David Starks-Browning <starksb at ebi dot ac dot uk>]

On Thursday 14 Nov 02, David Starks-Browning writes:
> On Thursday 14 Nov 02, Nicholas Wourms writes:
> > After investigating a few minutes, I found that in 
> > Makefile.common changing:
> > 
> > w32api_include:=-I$(w32api_source)/include
> > 
> > to
> > 
> > w32api_include:=-isystem $(w32api_source)/include
> 
> No, something else is going on.
> 
> In fact, the right "-isystem $(w32api_source)/include" appears in the
> c++ command line, by virtue of the FLAGS_FOR_TARGET definition in
> configure.in.
> 
> However, the c++ front-end also feeds "-isystem /usr/include/w32api"
> to cc1plus.exe, before the cvs one in the Makeile.  This screws us up.
> 
> Is this coming from the specs file?  If "-isystem /usr/include/w32api"
> has to be there (because gcc won't ever find it otherwise?), then a
> workaround for building Cygwin is to replace -isystem with -I in
> FLAGS_FOR_TARGET.  At least, I think that will work.  I'll try it now.

Sigh.  That causes another problem.  It brings
"$(w32api_source)/include" ahead of "." in the include search list:

#include "..." search starts here:
#include <...> search starts here:
 /home/starksb/cvs/sources.redhat.com/src/winsup/w32api/include
 .
 /home/starksb/cvs/sources.redhat.com/src/winsup/cygwin
 /home/starksb/cvs/sources.redhat.com/src/newlib/libc/sys/cygwin/include
 ../../../../src/winsup/cygwin/config/i386
 /lib/gcc-lib/i686-pc-cygwin/3.2/include
 /usr/include/w32api
 /home/starksb/cvs/sources.redhat.com/src/winsup/cygwin/include
 /home/starksb/cvs/sources.redhat.com/src/newlib/libc/sys/cygwin
 /home/starksb/cvs/sources.redhat.com/build/i686-pc-cygwin/newlib/targ-include
 /home/starksb/cvs/sources.redhat.com/src/newlib/libc/include
End of search list.

This breaks the compile of cygthread.cc, because it gets
winsup/w32api/include/winbase.h before ./winbase.h.  (So I haven't got
as far as fhandler_floppy.cc yet.)

Why are there two vastly different versions of winbase.h in different
places?  (Maybe they're not supposed to be so vastly different?)

I'm off to bed.  But if the different versions of winbase.h are by
design, I won't know how to solve the w32api/include problem when I
wake up.

Regards,
David