From: andrae AT gpc DOT de (Andrae Behrens)
Subject: bugs in "gcc version cygnus-2.7.2-961023"
24 Apr 1997 14:57:46 -0700
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <335E8166.6BA4.cygnus.gnu-win32@gpc.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.0b2 (Win95; I)
Original-To: gnu-win32 AT cygnus DOT com
X-Priority: 3 (Normal)
Original-Sender: owner-gnu-win32 AT cygnus DOT com

Dear developers,

testing the version of gcc usable for Win32 platforms pointed to in
the subject of the mail I detected the following bugs:

1. at declaration like:
   char * PASCAL function();
   forces gcc to get problems parsing the inside declarated
   macro __attribute__(...).
   Using at the other hand 
   LPSTR PASCAL function() compense the parsing problem.
   I detected the problem compiling Sockets.h:
   at the point:
   char * PASCAL inet_ntoa (struct in_addr in);
   changing this line to:
   /*char **/ LPSTR PASCAL inet_ntoa (struct in_addr in);
   helped.

2. In header Defines.h the macro VER_PLATFORM_WIN32_WINDOWS I 
   missed. Following the declarations from bc5 I wrote:
   #define VER_PLATFORM_WIN32_WINDOWS (1)
   to compense the problem.

3. the declaration: char* tempnam(char*,char*); I missed in 
   using #include <stdio.h>

4. Asking your FAQ nobody answered me to solve the problem of
   of automaticaly invoking the C++ constructor/destructor
   code inside a *.dll. The mingw32 files are able to provide
   the correct startup objects to force the linking process 
   collecting all necessary symbols and call "do_global_ctors"
   and so on. Please correct your startup files.

5. import libraries like libkernel32.a do not include all symbols
   exported by the related DLL at Win95. For example the entry to
   CreateToolhelp32Snapshot is not accessible (others too).

6. Not really a bug but a problem is the different declaration
   of fd_set and related macros in Sockets.h and the clib headers.
   Please think about the possibiliy of using both API4s together.
   Bc54s clib is not unix but it gives me the possibilty to
   mix both API4s. It should be a goal for you to reach the
   same behaviour.

7. At least but also not a bug is my hint to ld4s production of tonns
   of *.o files during the linking process. A simple comparision:
   one of the dll4s I need at windows platforms (*.so, *.sl files
   at unix platforms) is compiled by Borlands C++ 5.0 compiler in
   180 seconds. Gcc needs at all unix platforms we use longer.
   But gcc in your distribution needs 20 minutes at the same 
   machine. (Pentium 166, 64MB, 2GB Quantum). Gcc2.7.2 runs much 
   faster at the same machine under Linux2.0. 

My last message to your e-mail addresses to get basicly infos was
bounced by your DNS MX enty. I hope you will send me a 'receipt'
and some comments to my 'frog'-perspective to your work. Please 
dont angry but I hope my hints can help you to develop a really
good alternative toolset.

Thanks to your work and your attention,
  Andrae

-- 
http://www.tu-chemnitz.de/ftp-home/pub/Local/simulation/poses++/www
--
Dr. Andrae Behrens           Phone: +49-371-572820
GPC mbH                      Fax:   +49-371-5728244
Altchemnitzer Str. 52/54     mailto: poses AT gpc DOT de  or andrae AT gpc DOT de
D-09120 Chemnitz (Germany)
-
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".