This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> > 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |