Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Date: Tue, 24 Aug 1999 18:34:26 +0300 From: Paul Sokolovsky X-Mailer: The Bat! (v1.32) S/N 34D3AC61 Reply-To: Paul Sokolovsky X-Priority: 3 (Normal) Message-ID: <14773.990824@is.lg.ua> To: James Stern CC: cygwin AT sourceware DOT cygnus DOT com Subject: Re: Dynamically linking multiple copies In-reply-To: <19990823213708.5699.rocketmail@web1401.mail.yahoo.com> References: <19990823213708 DOT 5699 DOT rocketmail AT web1401 DOT mail DOT yahoo DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello James, James Stern wrote: JS> This is a follow-up to my prior question on dynamic JS> linking. I mastered Mumit Khan's dllwrap (Thank you, JS> Mumit) in a test program but just hit a roadblock when JS> I tried to dllwrap my production system. JS> The production system has 30+ libraries. Presently, JS> all are statically linked but I want to link them JS> dynamically. JS> I chose one of the 30+ libraries at random JS> ("libaction") and tried to dllwrap it (to create JS> libaction.a and libaction.dll). JS> However, dllwrap failed because the library has some JS> unresolveds from other libraries. JS> This is in keeping with a reply of Mumit's, which said JS> that each dynamic library needed to be self-contained. JS> But it leaves me with a problem. Do I have to chase JS> down the libraries libaction.a needs (and the JS> libraries they need, and the libraries they need, and JS> so on) and add the appropriate -l options when I build JS> libaction.a? No, that's bad approach. If you're author of those libraries, you probably know which libraries are leaves of your dependency grapth start with them and then proceed further. But if you think it's a chore - just link them all together into one dll! What you propose is neither first nor second and will give 30 dlls each containing copies of same lib. JS> Or can I just write a gawk program to JS> declare the missing functions __declspec (dllimport) JS> without worrying which libraries they come from? And what - you think it won't give you link errors? No, you'll still need implib to link with. But if you have implib, you'll not need those __declspec (dllimport) - implib has required stuff. __declspec (dllimport) is required only for *data*, for code is just a convenience which save you a jump. As you know, implib is build from def, so, the real question is 'how to produce def'. To produce dirty def is very easily - dlltool --export-all run on object set does that. It will be dirty because it exports many junk symbols (not all code uses static when needed, yes?). But you'll probably will live with that. What the real problem is that dlltool doesn't distinguish code and data symbols - defined, real symbols, what is shame! So, if any of your libs uses data interface, expect nice things as fetching jump instruction and then segfaulting on it. If you'd have data correctly marked as DATA in def, you'd get link error, go to header and add __declspec(dllimport) for that symbol. Enough, I guess. Resuming, build your libs as always, make def from object set of each, and then implib from each def. Link with corresponfing impdef of each lib instead of static lib. JS> I was about to write the above-mentioned gawk program JS> myself when I hit another roadblock. How do I tell JS> the difference between an undefined function and an JS> undefined extern variable? 'nm' marks them both 'U'. JS> I need to distinguish one from the other to write that JS> gawk script. Finding whether defined symbol code or data is easy - just look section it in. Finding type of undefined symbol is impossible, I guess, - just remember they all just address name and you can do anything with any address (of course, in practise, you'll probably never will get value stored at address of code symbol, but would you like to analyze code? ;-) ) JS> Thank you. JS> === JS> -- JS> Opinions expressed above are not necessarily my employer's. JS> James M. Stern JS> ITG Inc. Culver City, CA (213) 270-7955 Best regards, Paul mailto:paul-ml AT is DOT lg DOT ua -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com