Re: Upgrading from b20.1 to 1.1.x - now my static linking fails !

[MarketLogix <mlx at mlx dot com>]

No sweat,

I don't think its got anything to do w/ how I'm building my
.dll because don't forget that under scenario #1 where I'm using
all the latest stuff, my .dll builds and loads beautifully !!!

My problem is that if I try to statically link to a totally
STATIC library (not an import library to a .dll) the linker
can't resolve symbols that ARE in the library.

The strangest part is that that same static library is the one
I need to link in to create my .dll that works !!!

Its kinda confusing ... here's an example.

1. I ar & ranlib a standard static lib: libMYSTUFF.a

2. I create a .dll by compiling DllEntry.c (w/DllMain)
   and linking it (via ld) -lMYSTUFF to create MYSTUFF.dll

3. I can run non-cygwin apps that call LoadLibrary() on MYSTUFF.dll
   and they run like champs !!!

4. If I write a simple .c w/main() that calls a func in libMYSTUFF.a
   I can compile my .c but when I staticly link -lMYSTUFF, I get:

collect2: ld returned 1 exit status

BUNCH of undefined references to data & functions that nm will show are there !!!

Stanger still is that it only seems to be happening with
one of my libaries, and most have ObjC classes & methods
in them so I don't think its an ObjC mismangling factor ...

I just reupgarded only binutils & gcc-2.95.2-2 with setup
in case my home building of gcc was faulty but the result is
still the same !!!

bisk :(

Begin forwarded message:

Date: Mon, 31 Jul 2000 18:39:46 -0400
From: Charles Wilson <cwilson@ece.gatech.edu>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
To: mlx@san.rr.com
CC: cygwin@sourceware.cygnus.com
Subject: Re: Upgrading from b20.1 to 1.1.x  - now my static linking fails !

Okay, sorry -- I didn't connect your message with the other ones. I
can't offer any cogent advice -- except "it works for me". zlib, libpng,
libjpeg, libjbig, libtiff -- all contain dll and static lib, I built
both dynamically-linked and statically-linked executables for each
package, and they all worked -- linking with an import lib, and with the
static lib, and directly to the dll using ld.exe's new ability to
generate a "virtual" import lib on-the-fly.

So, it seems you've stumbled on an obscure bug -- I'd concentrate on
what you're doing that is *different* from normal dll usage -- like that
funky stdcall wrapper dllinit thingy... BTW, did you use
--enable-stdcall-fixup and/or --add-stdcall-alias as linker options when
building your dll/import library?

--Chuck


MarketLogix wrote:
>
> Thanks,
>
> But let me resummarize what I've got so far ...
>
> 1st scenario:
>
> gcc-2.95.2-2 + latest/binutils = good .dll / .exe static link failures .
>
> 2nd scenario:
>
> gcc-2.95.2-2 + release/binutils = bad .dll / .exe static links fine .
>
> If interested, please see earlier messages of this thread ...
>
> Thanks again,
>
> bisk
>
> Begin forwarded message:


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com