Mixing Static and Dynamic Librararies, Multiple Definitions of Symbol, Two-Level Namespace
Mixing Static and Dynamic Librararies, Multiple Definitions of Symbol, Two-Level Namespace
- Subject: Mixing Static and Dynamic Librararies, Multiple Definitions of Symbol, Two-Level Namespace
- From: Markus Hanauska <email@hidden>
- Date: Mon, 30 Jul 2007 19:56:58 +0200
I hope someone here could help me with a little linking problem.
I have a plain C library, that has to be a static one (please don't
suggest to change that, it's not possible, it must be static, it
can't be dynamic), that offers a great number of useful low level
functions.
Now I have a framework and this framework makes heavily use of this
static library (the framework is of course shared across multiple
projects). I have a couple of other frameworks and some of them use a
small subset of the static library (the compiler seems to strip out
unused functions, some dylib's are smaller than the static library
itself).
Finally, I have a main binary and the main binary also uses some of
the static library functions.
So the frameworks are compiled against the static library and the
main binary is as well... so far so well.
First problem: I get duplicate symbol warnings. Not too bad. All link
against the same static library, so all symbols are the same if they
have the same name, doesn't matter which one dyld will use at runtime.
Second problem: Now it gets tricky. The static lib declares a couple
of global variables (about 8). I know, global is bad, but these must
be global. One example is the global Logger. I want all the
Frameworks, all the functions in the static lib and the main binary
to use the same logging facility. And since they all need to access
it, it must be global.
The problem is, each framework has an own instance of the variable.
That means, if I init the logger in my main binary, it is still NULL
when accessing it from within a framework method (it is not when
accessing it from within a main binary method).
I guess that is the two-level namespace thingy I read on the man page
of ld (for the first time in my life, to be honest). Okay, but I
don't think forcing a flat namespace is the way to go. I link against
external libraries for that I have no source, should two of them ever
define a function with the same name, I have a big problem.
My next idea was to not define the variables in the static lib
anymore, instead only in the main binary. The static lib won't care,
the symbols are not resolved when I compile it. The main binary would
probably compile fine, too. But the frameworks won't compile any
longer. They complain about undefined symbols. And they are right,
they are undefined at compile time, but they won't be at runtime.
I found no way to have them ignore these symbols. I know that they
will resolve at runtime, but ld seems not to trust me ;-)
I can't use the -U parameter, it won't work, only in flat namespace.
I can use -undefined dynamic_lookup, this does work and yields the
expected results (now there is only one instance of each global
symbol), but the problem is, it suppresses all undefined symbol
errors. Even if I just make a typo by one letter, it will not yield
any error. I won't see that there is a problem, unless I build it all
and try to run it... which is quite sub-optimal IMHO.
Any idea how one could link dylibs and a main binary against the same
static library without duplicate symbol warnings and with every
symbol that is a variable existing only once in the whole namespace?
Or maybe to better describe the issue:
How can I enforce that the symbol FOO is the same symbol across
multiple dylibs and one executable binary? Is that possible?
--
Best Regards,
Markus Hanauska
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden