Re: Mixing Static and Dynamic Librararies, Multiple Definitions of Symbol, Two-Level Namespace
Re: Mixing Static and Dynamic Librararies, Multiple Definitions of Symbol, Two-Level Namespace
- Subject: Re: Mixing Static and Dynamic Librararies, Multiple Definitions of Symbol, Two-Level Namespace
- From: Tony Becker <email@hidden>
- Date: Mon, 30 Jul 2007 14:21:02 -0400
We had some issues mixing static (3rd party) and dynamic libraries/
frameworks. You might try the following "ld" options:
-ObjC -bind_at_load
and avoid the:
-all_load
option (which was the cause of our multiple symbol warnings)
On Jul 30, 2007, at 1:56 PM, Markus Hanauska wrote:
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
_______________________________________________
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