Re: [Mingw-users] Ready to build g77 for Vista
On Thu, 2008-01-10 at 15:11 +1100, Sisyphus wrote:
> Stumbling on ... in my search for clues as to why sys/wait.h is
> missing,
It is missing BY DESIGN, from the header set for the mingw32 compiler.
> I rebuilt the cross-compiler saving the output to a file. Going
> through that output I find a number of occurrences of:
>
> checking for sys/wait.h that is POSIX.1 compatible... yes
That would be correct, while running the native Linux hosted GCC, to
build the cross-compiler; the native compiler DOES have sys/wait.h
> ans also some occurrences of:
>
> checking for sys/wait.h that is POSIX.1 compatible... (cached) yes
This too would be correct, in a similar phase of the build procedure.
> But then I come to this:
>
> -----------------------------------
> Configuring in i686-pc-mingw32/libiberty
> configure: creating cache ./config.cache
> .
> .
> checking for sys/wait.h that is POSIX.1 compatible... no
> .
> -----------------------------------
>
> Is that sane?
Perfectly sane: at this stage, you are now running the cross-compiler
you just built, to build the foreign libraries it will use, when linking
code for the Win32 target platform; that cross-compiler should *never*
find sys/wait.h, for it is not supposed to be present, (unless you are
deploying some third party add-on library which provides it).
> Or could that be the source of the trouble?
Unlikely.
> My expectation is that if configure finds a POSIX.1 compatible
> sys/wait.h on one occasion, it should do so on *every* occasion.
It should, if on every occasion, it is the same compiler that is invoked
to test for its presence; while building a cross-compiler, this is not
necessarily true. My expectation is that a natively hosted compiler,
which targets Linux, should find such a sys/wait.h, but a compiler which
targets mingw32 should not.
The burning issue is, when you come to use the cross-compiler to build a
crossed-native compiler for mingw32, why does configure believe that it
can find sys/wait.h, for by this stage of your build, it should only
ever be using i686-pc-mingw32-gcc to perform the check, and that should
always say `no'. Is it possible that you have some cross pollution of
the include paths, for your native and cross-hosted compilers? Or maybe,
a stale cache file, (which configure really ought to reject), from the
cross-compiler build propagating misinformation to the crossed-native
build? Make sure you invoke the crossed-native build in a completely
independent, and clean (empty) build directory.
HTH,
Keith.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users