Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner 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 <mlx AT mlx DOT com>
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