Re: Dynamically linking multiple copies

[Paul Sokolovsky <paul-ml@is.lg.ua>]

Hello James,

James Stern <jsternitg@yahoo.com> 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@is.lg.ua



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