SUMMARY: Known issues with gnuwin32 development tools of year 1999

Paul Sokolovsky
Tue Dec 21 08:39:00 GMT 1999

In this message I would like to survey some problemetic spots which
bothered development process with gnuwin32 in year being over. It
mostly related to binutils/g++, and doesn't pretend to be
comprehensive list of all problems. On the other hand, it is quite
optimistic: most being reported problems are already solved by this
time, some don't, but will be in near future and currently have

I would like to thank Mumit Khan, from communication with whom most of
the content below emerged, and Cygwin stuff, maintainers of affected
packages, who were responsive and thoughtful towards fixing problems.
Also, thanks to other people who provided
solutions/workarounds/consulting for the problems.

On Win9x, mingw32's ld produced broken DLLs
This problem fixed in Mumit Khan's gcc-2.95.2-mingw package.

On Win9x, mingw32's strip cripled DLLs
This problem was related to the above and was fixed in Mumit
Khan's gcc-2.95.2-mingw package.

On Win9x, mingw32's as indeterministically screws up symbol names
Not fixed
This problem shows when producing a .def file from object files: some
symbols have strange garbage charcers (up to 3) attached. This problem
related to two above, but doesn't seem to be fixed yet. Cause of all
them lies in bfd's (library to handle object files, on which all
binutils rely) way of creating sections: it just skips beyond and of
file with lseek when section padding is required. According to POSIX,
zeroes must be written to file in such cases. But Win9x (unlike NT)
dishonours this and leaves previous medium contents. AFAIK, for PEI
(PE-image) file format special patch was applied, but usual objects
use PE format and don't affected by it. PE uses 4-bytes padding, so
sometimes up to 3 garbage bytes may show up.

Object-producing gnuwin32 tools didn't make distinction between data
and code symbols.
Due to design of Windows DLL, all dll-imported symbols must be handled
specially. This can be easily worked around for code symbols, but not
data. However, there were time when same workaround was (incorrectly)
applied for data. This led to hard-to-find errors and inability to use
efficient techniques for robust DLL producing (see e.g. )
Fixed in gcc-2.95.2 releases for mingw32 and cygwin.
If you want to produce .def file from existing dll, where symbols
correctly marked for data, you may use patched version of Anders
Norlander's ( )
pexports utility (pached version at )

g++ generates internal compiler error when compiling code which
dll-imports classes with virtual functions.
According to Mumit Khan, this problem is fixed in development
snapshots and next release of gcc will be free from it. If you cannot
wait till then, following makefile workaround might help you (just
include it in the main makefile):

%.o: %.cpp
        $(CXX) $(CXXFLAGS) -mnop-fun-dllimport -S $<
        awk -f vt-fix.awk $(basename $<).s | as -o $@
        rm $(basename $<).s
------ vt-fix.awk
#!awk -f

/^\.globl _=/           {bad_vt=1; next;}
/^\.section/ && bad_vt   { vt_name=substr($2,7,length($2)-10); }
/^_=/                   {
                          print ".globl _"vt_name
                          print "_"vt_name":"; bad_vt=0; next;

g++ bloats code when compiling dll.
When compiling c++ code for dll, gcc produces code by order bigger
than usually. Linking that code requires *lot* memory.
AFAIK, nothing on this route. With my project, I needed 300mhz/128mb
box to *link* code comfortably (it took about 2 hours to link it on
24mb). After enough annoyance, I wrote awk scripts which postprocess
assembly (in the spirit of hack above). After this, I again can feel
comfortably with my old p5-100/24.

Lack of compatibility and interoperatability with native (i.e. msvc++)
compiler and applications
This spans several points:

a) C dlls are interoperatable with mingw32, and Mumit Khan told he
made some changes to improve it for cygwin
b) C++ dlls aren't supposed to be interoperatable. As g++ faq
explains, the problem is not only in symbol mangling, but in deeper
issues also.
c) Implib incompatibility: some scripts to convert msvc's ones were
posted on list, Anders Norlander ( )
have utility for this.
d) Object file incompatibility: some exists, Mikey
<> made package
( ) which improves
(or solves) it to some degree. Also, his package contains wrappers for
gcc/ld/ar to act as corresponding native tools.

Merry Chistmas,


Want to unsubscribe from this list?
Send a message to

More information about the Cygwin mailing list