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:

> 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.
>
> >      $build/i386-mingw32/libiberty/config.log
> 
> 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() ?

 Yes, you are right...

 I had still the results from my July 2003 build of gcc-3.2.2 for the
MinGW target on Linux and here the libiberty-configure saw the
'times()' being missing:

 ------------------------------------ clip ----------------------------------------------
configure:2843: checking for times
configure:2871: /home3/src/gcc-3.2.2-win32/build/gcc/xgcc -B/home3/src/gcc-3.2.2
-win32/build/gcc/ -B/usr/local/i686-mingw32/bin/ -B/usr/local/i686-mingw32/lib/ 
-isystem /usr/local/i686-mingw32/include -o conftest -O2 -Os   conftest.c  1>&5
/tmp/ccCId9SR.o(.text+0x9):conftest.c: undefined reference to `_times'
collect2: ld returned 1 exit status
configure: failed program was:
#line 2848 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char times(); below.  */
#include <assert.h>
------------------------------------ clip ----------------------------------------------

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

 If producing MinGW apps to test things before the compiler has been
built would be possible, that could be strange :-)  So it is quite normal
that the libiberty-configure for the target happens after the GCC for it
(the 'gcc' subdir) has been built. 
 
> in config.log there are many assesrtions in BFD:
> /home/nedko/cross-tools/i386-mingw32msvc/bin/ld:
> BFD 2.13.90 20030111assertion fail
> /home/nedko/sandbox/cross/source/binutils-2.13.90-20030111-1-src/bfd/stabs.c:783
> the same assertion is throwed out when I try to link simple hello-world
> program with cross-mingw gcc/binutils.

 My Win32-target binutils on Linux seemed now to be some snapshots from 2002:

	GNU ld version 020806 20020806
	  Supported emulations:
	   i386pe

and these didn't cause any problems here...  Maybe elsewhere,
sometimes it looks like the old MinGW tools with binutils-990817,
egcs-1.1.2 and gcc-2.95.3 and with old MinGW runtime, could be
better than the newer gcc-3.x based tools...  Ok, I have those
binutils snapshots (up to 031021 or something now), the FSF-
release (2.13.2.1 now) and the Linux-binutils (2.14.90.0.6 now)
sources, so taking one binutils source base more (the
'binutils-2.13.90-20030111-1-src' or something) from the
MinGW-site, really doesn't sound sane...  Three binutils
branches should be more than enough.

 I really don't know which other binutils should now work ok for the
Win32 (Cygwin and MinGW) targets (than those on the MinGW and
Cygwin sites)... And which binutils should work ok on the Win32 host,
and for most other targets there, especially with the MinGW host (probably
none what becomes to supporting those targets which use shared '.so'
files).

 On Linux I tried the binutils snapshots, the old FSF 2.13.2.1 release and the
2.14.90.0.6 Linux-binutils "release" (from 'ftp.kernel.org') and saw that
only the first sources seemed to work at all, both the old FSF release and the Linux
"release" crashed when trying to build. The 20031007 and 20031021 snapshots
were tried and they both could at least to be built...

 The Win32-target issue has always been a problem in binutils, the support for
the 'i386-pe' format being broken now and then and usually for a long time...

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

 Too many Swen-worms received (mailbox in the mail server being filled during
some days when being away a couple of weeks ago) seems to have caused me
to be thrown away also from the MinGW-list, no messages from it appeared
for a some weeks (and I don't even have cared...).  Anyhow the MinGW-list
could be the right place for reporting any problems like yours, with the Win32
target support on the other hosts (Linux, FreeBSD, OpenBSD, NetBSD, Solaris2,...),
when using those 'official' MinGW-binutils sources...

 Ok, I can only suggest you to try the current binutils snapshots instead
of the MinGW-ones. Maybe the support for other hosts has something
wrong in the quite "tailored for the Windoze-host" MinGW-binutils.

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