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 sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-Id: <200007311649.AA08997@mlx.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v148.2.1) From: MarketLogix Date: Mon, 31 Jul 2000 09:49:49 -0700 To: cygwin AT sourceware DOT cygnus DOT com Subject: Upgrading from b20.1 to 1.1.x - now my static linking fails ! Reply-To: mlx AT san DOT rr DOT com Hi. Well, decided to try once again to upgrade from b20.1 ... On a fresh machine w/no previous Cygwin install, Here's what I've done: 1. Installed the v1.0 CD to default location. 2. On the evening of 7/28, used the web site setup utility (works real nice BTW) to download the latest to a local directory & then did my updating from there. 3. Also, downloaded gcc-2.95.2-2 w/src & built/installed it to /usr mainly because I need ObjC. I've got a fairly extensive .dll that I've developed and have been using quite happily since b19. Its created by simply linking together all of my static libraries along w/a .c module that "stdcalls" only the functions that I mean to export plus the module w/DllMain. I use the age old "3-pass" method that calls ld directly to create the .dll. My .dll builds, strips and loads just fine !!! This is where I will typically run into serious "challenges" whenever trying to roll into a new Cygwin version. Super cool that it works right out of the box :) BUT, BUT, Here's the weird thing: When I try to build a Cygwin .exe, the compile pass is just fine but, upon linking, those exact same static libraries I used to create my .dll, certain functions and ObjC classnames error out as "undefined references" !!! I know that they are NOT really undefined because: 1. nm shows that they are there. At least nm ouput symbol names of my b20.1 vs. v1.1.x .a look the same. But far more importantly 2. My .dll references the same symbols and not only builds but is loaded by non-cygwin applications and runs w/them just fine !!! The only difference in the build method, that's obvious to me, is that when building a .dll, I call ld directly where when building an .exe, I call "gcc -o" Is there something "experimental" going on with either the binutils that I've updated via setup or that gcc-2.95.2-2 I've recompiled ? Anybody with an idea of the best place to start to diagnose this ? I do notice interesting differences between the .a created by b20.1 vs. v1.1.x: ---------------------------------- ------------------- MktInfoMgr.o: MktInfoMgr.o: 00000000 b .bss 00000000 b .bss 00000000 ? .ctor 00000000 ? .ctor 00000000 d .data 00000000 d .data 00000000 ? .stab 00000000 ? .stab 00000000 ? .stabstr 00000000 ? .stabstr 00000000 t .text 00000000 t .text 00000004 C _CMCCURVE_FUNC 00000010 C _CMCCURVE_FUNC 00000004 C _MLX_MODULE 00000010 C _MLX_MODULE 00000018 d _SCCSID 00000018 d _SCCSID 000027ac T __GLOBAL_$I$MktInfoMgr.m 000024e8 T __GLOBAL_$I$MktInfoMgr.mFORufb Note (what looks to be) garbage at the end of __GLOBAL_$I$MktInfoMgr.m Also, I see that in the b20.1 archive there is no extra character, ie. unix endings while in the 1.1.x archive we have DOS endings even tho it looks like the default mounting mode has switched to binary ! Its text!=binary for my b20.1 setup ... Yikes ! I'm thoroughly confused here ... Should I get ahold of a different binutils and/or gcc package ? Thanks, bisk -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com