Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>,
	<http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id: <199908241538.KAA30352@mercury.xraylith.wisc.edu>
To: stern AT itginc DOT com
cc: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: Dynamically linking multiple copies 
In-Reply-To: Your message of "Mon, 23 Aug 1999 14:37:08 PDT."
             <19990823213708 DOT 5699 DOT rocketmail AT web1401 DOT mail DOT yahoo DOT com> 
Date: Tue, 24 Aug 1999 10:38:44 -0500
From: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>

James Stern <jsternitg AT yahoo DOT com> writes:
> This is a follow-up to my prior question on dynamic
> linking.  I mastered Mumit Khan's dllwrap (Thank you,
> Mumit) in a test program but just hit a roadblock when
> I tried to dllwrap my production system.
> 
> The production system has 30+ libraries.  Presently,
> all are statically linked but I want to link them
> dynamically.
> 
> I chose one of the 30+ libraries at random
> ("libaction") and tried to dllwrap it (to create
> libaction.a and libaction.dll).
> 
> However, dllwrap failed because the library has some
> unresolveds from other libraries.
> 
> This is in keeping with a reply of Mumit's, which said
> that each dynamic library needed to be self-contained.

That's the kicker in all of this. You should how big our
DLLs get because of this issue (we haven't completed the
work to convert out 50+ shared libraries into DLLs yet).

> But it leaves me with a problem.  Do I have to chase
> down the libraries libaction.a needs (and the
> libraries they need, and the libraries they need, and
> so on) and add the appropriate -l options when I build
> libaction.a?  Or can I just write a gawk program to
> declare the missing functions __declspec (dllimport)
> without worrying which libraries they come from?

Yes.

The following may work: let's say you have n modules that you want to 
turn into DLLs, all of which have subtle dependencies (this can usually 
be avoided, or at least alleviated, by a better system design, but 
that's a different issue). Now you can't just keep on building these
DLLs without the rest since windows requires symbol resolution. What
you can do is to do a first pass and create all the import libraries
and *then* build the DLLs by linking them against all the import
libraries.

> 
> I understand that I'll have to supply all the right
> libraries when I link the main program.  That's ok.  I
> just don't want to compute the dependencies for each
> of 30+ libraries.
> 
> I was about to write the above-mentioned gawk program
> myself when I hit another roadblock.  How do I tell
> the difference between an undefined function and an
> undefined extern variable?  'nm' marks them both 'U'. 
> I need to distinguish one from the other to write that
> gawk script.

Too complicated.

Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com