Re: SUMMARY: Known issues with gnuwin32 development tools of year 1999

[Mumit Khan <khan at NanoTech dot Wisc dot EDU>]

Paul, thanks for the nice summary ...

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

Good to know it's fixed.

> 
> 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.

Likewise.

> 
> 3.
> PROBLEM
> On Win9x, mingw32's as indeterministically screws up symbol names
> STATUS
> Not fixed
> DESCRIPTION

I would have expected this to be fixed with 1 and 2! Can you find out
why not? Since all calls to fseek and fwrite goes through bfd_seek
and bfd_write (which have mingw32 workaround now), I don't know why
this still persists. Of course, I can't reproduce this, which makes
it even harder to fix.

> PROBLEM
> Object-producing gnuwin32 tools didn't make distinction between data
> and code symbols.
> DESCRIPTION

Good.

> 5.
> PROBLEM
> g++ generates internal compiler error when compiling code which
> dll-imports classes with virtual functions.
> STATUS

This will be in my update for 2.95.2 ... "real soon now".  It was really
a matter of digging into MS assembler output and figuring out what it's
doing. Not my idea of a fun evening.

> 6.
> PROBLEM
> g++ bloats code when compiling dll.

G++ needs to emit vtables and RTTI info in DLLs, and that's part of the
bloat. It also needs to emit a lot more than would be required for static
builds. Thank Microsoft for the DLL design that uses "multiple symbol 
spaces". Now, say it with me -- "True" PIC (Position Independent Code) 
is a good thing ;-)

The big problem here is *linking* a DLL, and the biggest culprits for
a *large* DLL are, starting from the worst offender:

  1. dlltool -- it takes forever to create those zillions of little files
  and assembling those individually. Creating an import library takes
  upto 80% of the total time sometime, even on Linux! If someone can
  fix dlltool to bunch these up in blocks of say 100 or so, it will
  speed things up considerably.

  2. multiple passes -- of course this requires that each pass load up
  all those symbols each time.

The problem is somewhat fixed by DJ's pe-dll (ie., ld with --shared 
option to directly create DLLs), but that's not in the public versions
yet. The current pe-dll version in Cygwin v1.0 can't create C++ DLLs
because of a bug in exporting common symbols, which are plentiful in
C++. And the sourceware development version is crippled for pe-i386
right now. Can't win ;-)

> 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

It should work fine for Cygwin right now if you're using the latest 
Cygwin snapshot. However, there is one pending patch that CGF is still
looking at that is necessary for doing it right (signals, I/O, network,
etc -- anything that requires Cygwin to use a separate thread).

> 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.

Yes. You can always COM however. Note that multiple interface COM objects
don't work in G++ due to vtable issues.

> c) Implib incompatibility: some scripts to convert msvc's ones were
> posted on list, Anders Norlander (http://www.acc.umu.se/~anorland/gnu-win32/i
> ndex.html)
> have utility for this.

If someone would fix up implib to be "bfd'ized", then it would be a big
boost for creating import libraries. Perhaps it already is ...

> d) Object file incompatibility: some exists, Mikey
> <jrson@az.freei.net> made package
> (ftp://ftp.franken.de/pub/win32/develop/gnuwin32/mingw32/porters/Mikey/) whic
> h improves
> (or solves) it to some degree. Also, his package contains wrappers for
> gcc/ld/ar to act as corresponding native tools.

Until and unless the copyright is assigned to FSF, this is of course not
going to be part of the standard toolchain. The legality of using public 
domain code in GPL'd code is murky at best, and FSF will not take the 
chance of a legal challenge down the line.  Fact of life, sorry. 

Note that DJ has added support for pre-v6 MSVC import libraries in the
linker; v6+ implibs are not COFF, so that's a different story altogether.
This is in the binutils development sources available from sourceware
if anyone wants to look at it.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com