Re: Fwd: GCC 3.1 linux-to-mingw32 near success but still some questions remain ;-)

["Kai Ruottu" <kai dot ruottu at luukku dot com>]

> >  Did you install the Mingw-patches for gcc-3.1.x ?  Don't remember any
> > problems with these...
> 
> Sorry, I haven't installed any patches(I haven't really looked at whether 
> such patches exist, either)
> What's the reason that one would have to apply "external" patches to the gcc 
> source tree?

 The Mingw-port of 3.1.x is in beta-stage and not all proposed
changes are integrated to the FSF-sources. Perhaps never... When
these are for the 'GCC-kernel', to the stuff below the 'gcc/config',
getting them there requires at least some bureaucracy. I would expect
only some 'trusted to know what they are doing'-people to be allowed
to modify the 'kernel' parts...

 Neither I have yet checked the latest patches, but my tries have 
happened with the gcc-3.1.1 prereleases:
 ftp://sources.redhat.com/pub/gcc/snapshots
not with the gcc-3.1 release sources. Probably some of the newer 
Mingw-stuff has been integrated there. I installed some patches some
months ago. The last I built for Mingw-target was the 20020715-
prerelease... I may have done some fixes to the sources because all
the builds have gone without any problems a couple of months now...

> > > 3) Why did I have to patch the ld/pe-dll.c file?
> >
> >  The specific binutils sources you have are aimed for the single-eyed
> > 'Windoze-host & Windoze-target' builds with 'msys', 'cygwin' etc., not
> > for generic builds on a Unix-compatible system with 'strncasecmp()'
> > (glibc or libiberty or something) instead of 'stricmp()'...
> 
> So no easy configure; make; make install on every platform just yet I guess...

 The binutils-snapshots:
   ftp://sources.redhat.com/pub/binutils/snapshots
were tried from the weekly '20020716' sources on Linux
for Mingw-target at the same time with the latest GCC-3.1.1
sources and they seemed to meet your requirement...

> For now, I've dropped the idea of building native mingw tools, because I have 
> discovered a severe problem with my cross compiler when trying to 
> cross-compile the latest wxWindows sources from CVS:
> 
> i686-pc-mingw32-c++ -shared 
> -Wl,--out-implib,lib/libwx_msw-2.3-i686-pc-mingw32.dll.a -o 
> lib/libwx_msw-2.3-i686-pc-mingw32.dll  accel.o app.o bitmap.o bmpbuttn.o 
> 
> <...tons of object files...>
> 
> inftrees.o infcodes.o infutil.o inffast.o automtn.o dataobj.o dropsrc.o 
> droptgt.o oleutils.o uuid.o -Wl,--subsystem,windows -mwindows  -lm -lrpcrt4 
> -loleaut32 -lole32 -luuid -lwinspool -lwinmm -lshell32 -lcomctl32 -lctl3d32 
> -ladvapi32 -lwsock32
> Creating library file: lib/libwx_msw-2.3-i686-pc-mingw32.dll.a
> i686-pc-mingw32-c++: Internal error: Segmentation fault (program ld)
> Please submit a full bug report.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> make: *** [lib/libwx_msw-2.3-i686-pc-mingw32.dll] Error 1

 Don't know which is the latest 'acid-tested' binutils-version for
Win32, but I would expect the official '2.11.2' being near it... But
I haven't experience with big C++-produced archives, those import 
libs and DLLs generated in the Insight-builds, 
'libtcl83.a'/'tcl83.dll' etc. may be the biggest I have needed to
produce... But they are all made from plain-C objects, not from 
objects with very long mangled symbol names...

 If the "latest wxWindows sources from CVS" don't need any up-to-date
features from the binutils, then trying binutils-2.11.2 could help. 
Or if some are needed, the up-to-date snapshots would be the 
solution.  I have attached my 'RedHat6.2-compatible' 'ld' for Win32
targets, linked against glibc-2.1.3, so if your Debian is somehow up-
to-date, it could run this executable:

C:\temp\mingw32>h:\usr\local\i486-linux-gnu\bin\objdump -p ld

ld:     file format elf32-i386

Program Header:
    PHDR off    0x00000034 vaddr 0x08048034 paddr 0x08048034 align 
2**2
         filesz 0x000000c0 memsz 0x000000c0 flags r-x
  INTERP off    0x000000f4 vaddr 0x080480f4 paddr 0x080480f4 align 
2**0
         filesz 0x00000013 memsz 0x00000013 flags r--
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 
2**12
         filesz 0x0008c1b7 memsz 0x0008c1b7 flags r-x
    LOAD off    0x0008c1c0 vaddr 0x080d51c0 paddr 0x080d51c0 align 
2**12
         filesz 0x00000bf0 memsz 0x00002274 flags rw-
 DYNAMIC off    0x0008cb78 vaddr 0x080d5b78 paddr 0x080d5b78 align 
2**2
         filesz 0x000000c8 memsz 0x000000c8 flags rw-
    NOTE off    0x00000108 vaddr 0x08048108 paddr 0x08048108 align 
2**2
         filesz 0x00000020 memsz 0x00000020 flags r--

Dynamic Section:
  NEEDED      libc.so.6
  INIT        0x8049158
  FINI        0x80b0fcc
  HASH        0x8048128
  STRTAB      0x8048a48
  SYMTAB      0x8048438
  STRSZ       0x32b
  SYMENT      0x10
  DEBUG       0x0
  PLTGOT      0x80d5c50
  PLTRELSZ    0x2a0
  PLTREL      0x11
  JMPREL      0x8048eb8
  REL         0x8048e68
  RELSZ       0x50
  RELENT      0x8
  VERNEED     0x8048e38
  VERNEEDNUM  0x1
  VERSYM      0x8048d74

Version References:
  required from libc.so.6:
    0x0d696911 0x00 03 GLIBC_2.1
    0x0d696910 0x00 02 GLIBC_2.0

 Yes, I have Linux-target tools on Windoze... A big sin perhaps, but 
when visiting there, capability to handle executables this way and
sometimes compiling some "Hello World" apps there is nice...  Ok, it
is zipped...  Binary-compatability between Linux'es must sometimes be
checked...

 If substituting your current 'ld' for Mingw with this causes the 
link succeeding, perhaps trying a new build with the sources is then
motivated.

> Obviously, there's not much I can do about that, except make sure I have 
> enough free disk space (600MB) and memory (384 MB)

 Should be enough...

> Would ld give a more "informative"  error message if free memory or so was 
> the problem?

 Maybe adding '-Wl,-verbose' to the CFLAGS in the related Makefile 
would tell something more... This should give very 'verbose' 
output...

> Or, in other words, does this look like a very severe (misbuild?) problem?

 The binutils have been the problem area always, since the very 
stable '990817' snapshots (which I have used the last three years), 
the next one to fill the requirements is somehow unclear... But at
the '2.11' age they should have been ok again. Don't know about the
current '2.12'-level tools, but someone mentioned them being "quite
buggy"... Too many targets to serve perhaps -- fix one and break
another. The Win32-target really isn't important for the binutils-
people ("those Win32-people use only the prebuilt Cygwin and Mingw
tools, so why care..."). Those who must build the binutils from src,
must first investigate which sources should work...

Cheers, Kai
 
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  Ld.zip
     Date:  18 Jul 2002, 21:31
     Size:  265878 bytes.
     Type:  ZIP-archive

Attachment: Ld.zip
Description: Zip archive

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