Re: Cannot build OpenBSD hosted mingw32 targeted cross compiller. Looking for help.

["Kai Ruottu" <karuottu at mbnet dot fi>]

Nedko Arnaudov <nedko.arnaudov@atia.com> wrote:

> >  Ok, the GCC-build searches the MinGW-headers from these places
> > ($prefix/$target/*include') and it is surprising that you didn't put them
> > there before starting to build GCC, as if you hadn't consulted your
> > fine GCC-manual (RTFM) and the build instructions for cross-GCCs
> > ever...  Also all the target libs must be preinstalled from the MinGW
> > runtime and w32api packages (into $prefix/$target/lib).
> 
> The script i've ran do this. I have mingw headers in both
> /home/nedko/cross-tools/i386-mingw32/include
> and
> /home/nedko/cross-tools/i386-mingw32/sys-include

 Seemingly the script is buggy and uses '--with-headers' or something
to do the duplicating. AFAIK, the MinGW-headers shouldn't be tried to
be 'fixed' for GCC. One sane reason is that there is no other 'cc' which
uses them too, they already are 'fixed for GCC'. The old rule: "Don't
fix it if it ain't broken" should be followed. All the stuff in the 'sys-include' may be fixed 
by the 'fixinc' things, so there shouldn't be much
to fix. My advice about putting the w32api headers there before the
GCC build may then be wrong. It can be fully possible that the 'fixinc'
handles the header stuff sanely but one cannot be sure before one
tries...

> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>  /home/nedko/cross-tools/i386-mingw32/sys-include
>  /home/nedko/cross-tools/i386-mingw32/include
> End of search list.
> ----------------------------------
> 
> /home/nedko/cross-tools/i386-mingw32/sys-include
> /home/nedko/cross-tools/i386-mingw32/include
> 
> are the built-in search paths, right ? MinGW headers are there.

 Yes, and the search-order is just what the GCC-manual says about
SYSTEM_INCLUDE_DIR and STANDARD_INCLUDE_DIR with the
equivalent native GCC.  The w32api-headers also belong to the
MinGW headers and my suggestion would be to put them into the
'sys-include' and keep the 'include' for the runtime/standard headers.
But maybe it will be wise to do the w32api install afterwards... That
the runtime headers are duplicated is not very good.

> Your message (thanks), has cleared some things to me so now I'm sure
> that the problem is that MinGW gcc searches sys/times.h but it is not
> available in MingW headres. But MinGW headers are same when building
> Linux hosted and OpenBSD hosted gcc for MinGW. So the problem is why
> MinGW gcc searches for header (sys/times.h) that is not available in
> MinGW headers directories ($prefix/$target/*inculde). I suppose  that
> this is because I have such header in /usr/include (OpenBSD native gcc
> headers). Am I right ?

> /home/nedko/sandbox/cross/source/gcc-3.2.3-20030504-1/configure
> -v --prefix=/home/nedko/cross-tools --target=i386-mingw32
> --with-headers=/home/nedko/cross-tools/i386-mingw32/include
> --with-gnu-as --with-gnu-ld --without-newlib --disable-multilib
> Thread model: single gcc version 3.2.3 (mingw special 20030504-1)
 
 Your GCC-sources seem to be the already patched gcc-3.2.3 sources
taken from the MinGW archives, so everything looks almost good...

 But I cannot understand all this bullshitism in the configure command.
It should be enough that the target headers are jjust where the
'--with-headers' here tells, so this is vain and causes the duplicating.
With x86 the '--with-gnu-as' and '--with-gnu-ld' are also vain, with MIPS
and Sparc targets they usually are required. The '--without-newlib' is
also something weird, I don't know what it does here... As default
MinGW hasn't multilibs in use, so the last option is also vain. It could
use separate 'libstdc++' etc. for '-mcrtdll', '-mwin32s', -mwince' etc., if
there were alternative 'targets' to the current 'msvcrt'... But there aren't
elsewhere than with private local toolchains for Win32/Win32s/WinCE
(the last meaning the WinCE/PocketPC emulator with its own DLLs).
When I see things like this, they remind me about the CONFIG.SYS
and AUTOEXEC.BAT on DOS, people used to put all kind of 'useful'
things into them, they became useful when some friend told that a row
like that or that could be useful... Of course they hadn't a clue WHY
the rows were there or whether the added rows broke something...
The './configure --target=something' in the GCC-manual sounds
always much better than this kind of bullshitism...

 Whether this bullshitism caused configure to fail is unknown, the
'--with-newlib' assumes newlib and sets the 'config.h' for it... But what
the '--without-newlib' does, is totally fuzzy... Running configure should
check the target C library if no '--with*-newlib' were used...

 Ok, the installed MinGW-patches there should have fixed the file
'libiberty/getruntime.c' or something else so that it doesn't try to
'#include <sys/times.h>' :

#ifdef HAVE_TIMES
#ifdef HAVE_SYS_PARAM_H
#include <sys/param.h>
#endif
#include <sys/times.h>
#endif

although this tells that configure should take care about this and not
define HAVE_TIMES when the MinGW headers don't have it....

 Maybe your '/usr/local/include/sys/times.h' exists, and as seen earlier:

> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include

this will be also checked by your new gcc/cpp. But if configure found
it using your new GCC, then using the same GCC later should find
it too... Weird indeed... Anyway these 'common' places for different
GCCs can be a trap and I would check the '/usr/local/include' in any
case... It definitely shouldn't have any native host dependent stuff.

 Why the LOCAL_INCLUDE_DIR appeared here needs some kind of explanation, it 
should be disabled in the FSF-sources, but the
'$prefix/include', here '/home/nedko/cross-tools/include' should be
listed... I don't use '--prefix=', so my $prefix is the default '/usr/local'
and '$prefix/include' is the same as '/usr/local/include'... But current
GCCs should enable the '$prefix/include' too.

> Next is output of running configure for gcc:

 This was a wrong logfile, the right one would have been the:

     $build/i386-mingw32/libiberty/config.log

and the 'config.h' in the same place telling the results. So you can
hack this and fix the HAVE_TIMES definition there and don't try
to find out why the configure failed... But looking at the logfile and
trying to fix the bug in configure could be better. Maybe other things
failed too and checking the 'config.h' for sanity is motivated...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com