Mail Archives: cygwin/1997/11/06/01:08:10
To those who're following the egcs on cygwin32 saga, you might be
interested to know that I managed to get the whole egcs bit to build
as native win32 apps (gcc, gas, ld, windres, etc) and other than a
small problem (See "Known Problems" later), it seems to work. Even
``gcc -pipe'' works. To be honest, I've really only tested x-compiling
from a linux box, and only 5 liner toys on a win32 host.
I've been watching Colin Peters' mingw32 work for a while, and just
recently found J.J.vanderHeijden's (J DOT J DOT vanderHeijden AT student DOT utwente DOT nl)
work on creating native gcc and binutils with mingw32. For egcs, I
started with the patches from J.J.vanderHeijden's web page at
<a href="http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32/">,
and then finally got the whole thing working as a cross-compiler on
linux (the easy part), and then native via canadian cross.
Here's the list of programs (My dev tree doesn't have some of the tools
you'd normally get with gnu-win32, such as make, flex, bison etc, but
just the compilier toolchain):
addr2line.exe gcc.exe objcopy.exe
ar.exe gcov.exe objdump.exe
as.exe gdb.exe protoize.exe
c++.exe genclass ranlib.exe
c++filt.exe gperf.exe size.exe
dlltool.exe gprof.exe strings.exe
g++.exe i386-mingw32-gcc.exe strip.exe
g77.exe ld.exe unprotoize.exe
gasp.exe nm.exe windres.exe
Over the next week or so, I'll make the patches available. My source tree
is a mess since it's a combination of various pieces from various
distributions, and having the patches alone might not help you much.
My sincere thanks to Colin Peters and J. J. VanderHeijden for all their
work that got me interested in this.
Here's what I started with (number of * marks relative size of patches):
gnu-win32 b18 CDK:
gdb/ ***
readline/ *
winsup/mingw/ *
egcs-971023:
gcc/ ****
libio/
libiberty/ **
libstdc++/
binutils-971023:
bfd/ *
gprof/
gas/
ld/
binutils/ ***
libg++-2.8.0b6 (+patches from HJ Lu)
librx/
libg++/
gprof/
Windows32api v0.1.2:
Headers/
Source/
Good things:
1. It works! In theory the compiler tools should run quite a bit faster,
but I don't care either way since I use x-dev tools exclusively.
2. For *one* numerically intensive code, a crude measurement shows
30% speed improvement. I'll attribute that the to the CRTDLL
trig routines, and to the process creation and etc that is known to
be currently intolerably slow on cygwin32.
Known problems:
1. gdb user-interface stinks, no thanks to the minimal readline support
for non-Unix boxes. Can't step over CRTDLL exported functions for
some reason; gdb gets into a "__image_base" and then you have to
use "finish" and then "next" to step over. Minor annoyance.
2. CRTDLL exports need lots of work. Thanks to Colin for doing all this
work that the rest of us can start from. Ditto for the headers. I
use MS-DEV headers, so I don't really care much ;-)
3. DLL stub archives (eg., libkernel32.a) created from cygwin32 b18 are
not compatible. Startup files are also not backward compatible. This
is usually not a problem.
4. There is a small problem with cpp trying to optimize include paths,
and in the process losing all the -I <dir> parameters! I have
disabled it for now before I figure out the problem. It now works,
albeit a tad bit slower perhaps.
There is only one right way to use cygwin32 -- use it as a cross-compiler
on some other platform ;-)
Regards,
Mumit -- khan AT xraylith DOT wisc DOT edu
http://www.xraylith.wisc.edu/~khan/software/gnu-win32
ftp://ftp.xraylith.wisc.edu/put/khan/gnu-win32
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -