Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Message-Id: <199912211903.NAA10378@hp2.xraylith.wisc.edu> To: Paul Sokolovsky cc: cygwin AT sourceware DOT cygnus DOT com, mingw32 AT egroups DOT com Subject: Re: SUMMARY: Known issues with gnuwin32 development tools of year 1999 In-reply-to: Your message of "Tue, 21 Dec 1999 18:35:10 +0200." <7774 DOT 991221 AT is DOT lg DOT ua> Date: Tue, 21 Dec 1999 13:03:21 -0600 From: Mumit Khan 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 > 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 AT sourceware DOT cygnus DOT com