Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Message-ID: <3978AC2E.7145C717@ece.gatech.edu> Date: Fri, 21 Jul 2000 16:01:50 -0400 From: Charles Wilson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Danny Smith , cygwin@sources.redhat.com Subject: Re: binutils prerelease available for testing (feedback needed) References: <20000721062628.85462.qmail@hotmail.com> <3978840D.7740F581@ece.gatech.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit OK! The problems that I have been seeing must be related to my *overly complex* testing -- I can only figure there's something in one of my hacked up libpng .c or .h files that I am overlooking, since I did have to *hack* libpng so that it would export a data item. The following tests were done using binutils from CVS 20000721 + Mark E.'s patch I downloaded Mumit's dllhelpers, and built the .c version *by hand* using 'gcc -shared' and this .def file: EXPORTS dll_double_square @ 1 ; dll_float_square @ 2 ; dll_get_global_int_var @ 3 ; dll_global_int_var @ 4 DATA ; dll_int_square @ 5 ; dll_set_global_int_var @ 6 ; I even *omitted* the dllinit.o file from the dll, so as to force cygwin to use the built-in dllinit methods. Build dll: gcc -c -DBUILDING_DLL=1 -I. -g -Wall - cdll.o cdll.c gcc -shared -Wl,--out-implib=libcdll.dll.a -Wl,--enable-auto-image-base -o libcdll.dll cdll.def cdll.o Build exec's: gcc -c -I. -g -Wall -o usedll.o usedll.c CASE 3 (use import lib) ld -Bdynamic -o usedll-imp.exe /usr/lib/crt0.o -L./ -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2 -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib usedll.o -lcdll -lgcc -lcygwin -luser32 -lkernel32 ladvapi32 -lshell32 -lgcc CASE 2 (link direct to dll) mv libcdll.dll.a libcdll.dll.a.foo ld -Bdynamic -o usedll-dll.exe /usr/lib/crt0.o -L./ -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2 -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib usedll.o -lcdll -lgcc -lcygwin -luser32 -lkernel32 ladvapi32 -lshell32 -lgcc Both usedll-imp.exe and usedll-dll.exe worked fine. Taking a look at the executable symbols: nm -a usedll-imp.exe | grep dll_global_int_var 008040b4 I __imp__dll_global_int_var nm -a usedll-dll.exe | grep dll_global_int_var 008040e8 I __imp__dll_global_int_var 00801590 T _dll_global_int_var Interesting: when using the import lib, you only get the __imp__ symbol, but when linking directly to the dll (i.e. using a virtual import lib) you get both symbols. In either case, however, the executable works properly. My earlier reported problems must have been due to mistakes in my hacked up libpng, but I haven't located them. Sorry for the confusion. --Chuck (used the same link command to -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com