Mail Archives: cygwin/2000/07/31/19:08:22
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 AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
To: mlx AT san DOT rr DOT com
CC: cygwin AT sourceware DOT cygnus DOT 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 AT sourceware DOT cygnus DOT com
- Raw text -