Mail Archives: cygwin/1999/12/21/11:40:02
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
workarounds.
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.
1.
PROBLEM
On Win9x, mingw32's ld produced broken DLLs
STATUS
This problem fixed in Mumit Khan's gcc-2.95.2-mingw package.
2.
PROBLEM
On Win9x, mingw32's strip cripled DLLs
STATUS
This problem was related to the above and was fixed in Mumit
Khan's gcc-2.95.2-mingw package.
3.
PROBLEM
On Win9x, mingw32's as indeterministically screws up symbol names
STATUS
Not fixed
DESCRIPTION
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.
4.
PROBLEM
Object-producing gnuwin32 tools didn't make distinction between data
and code symbols.
DESCRIPTION
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.
http://www.infoservice.lg.ua/~paul/devel/static2dll_howto.txt)
STATUS
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 (http://www.acc.umu.se/~anorland/gnu-win32/index.html)
pexports utility (pached version at http://www.infoservice.lg.ua/~paul/devel/binutils.html)
5.
PROBLEM
g++ generates internal compiler error when compiling code which
dll-imports classes with virtual functions.
STATUS
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):
------ g++-dllimport-workaround.mk
%.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;
}
{print}
------
6.
PROBLEM
g++ bloats code when compiling dll.
DESCRIPTION
When compiling c++ code for dll, gcc produces code by order bigger
than usually. Linking that code requires *lot* memory.
STATUS
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.
7.
PROBLEM
Lack of compatibility and interoperatability with native (i.e. msvc++)
compiler and applications
STATUS
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 (http://www.acc.umu.se/~anorland/gnu-win32/index.html)
have utility for this.
d) Object file incompatibility: some exists, Mikey
<jrson AT az DOT freei DOT net> made package
(ftp://ftp.franken.de/pub/win32/develop/gnuwin32/mingw32/porters/Mikey/) 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,
Paul mailto:paul-ml AT is DOT lg DOT ua
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -