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

[Nedko Arnaudov <nedko dot arnaudov at atia dot com>]

>> 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

Yes I checked this, --with-headers in build-cross.sh script causes
creating sys-include

>  Whether this bullshitism caused configure to fail is unknown, the

Without additional options (they are not required in my case, but
build-cross.sh author may be has its reason to supplied these "useless"
configure options, i just don't know) configure script detects
HAVE_TIMES as bad as with them.

>  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....
I have this preprocessor conditionals in getruntime.c
>
>  Maybe your '/usr/local/include/sys/times.h' exists, and as seen earlier:
No, I only have it in /usr/include, /usr/local/include/ does not have
subdirectory named sys nor file of course.

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

I've commented HAVE_TIMES in $build/i386-mingw32/libiberty/config.h and
this helped (thanks). I also like the idea of finding why configure
incorrectly detects presense of sys/times.h in mingw headers but I need
some help to do this. I've checked
$build/i386-mingw32/libiberty/config.log and found only this line about
"times":

configure:2842: checking for times

Not sure if this is about sys/times.h
May be it is check for function called times() ?

Starge thing is that configuration of $build/i386-mingw32 stuff is not
done in configure state but while i do make. Any hints where to search
problem will be verry appreciated.

Also found these lines in $build/i386-mingw32/libiberty/config.status :

${ac_dA}HAVE_TIMES${ac_dB}HAVE_TIMES${ac_dC}1${ac_dD}
${ac_uA}HAVE_TIMES${ac_uB}HAVE_TIMES${ac_uC}1${ac_uD}
${ac_eA}HAVE_TIMES${ac_eB}HAVE_TIMES${ac_eC}1${ac_eD}

in config.log there are many assesrtions in BFD:
/home/nedko/cross-tools/i386-mingw32msvc/bin/ld: BFD 2.13.90 20030111 assertion fail /home/nedko/sandbox/cross/source/binutils-2.13.90-20030111-1-src/bfd/stabs.c:783

this includes test for "times"

the same assertion is throwed out when I try to link simple hello-world
program with cross-mingw gcc/binutils. While this issue (assertion in
bfd) is likely to be off-topic in crossgcc, it is unlikely to be problem
on Linux platform because build-cross.sh author provides binaries for
Linux and I assume that they work. (Unability to produce executables
means, IMHO, not working build tools). So I still suspect cross
compilation but I may be wrong. I'll try to track the bfd assertion but
if somebody has any hints, help will be very appreciated.

-- 
Nedko Arnaudov


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