"Flattening" a static library
"Flattening" a static library
- Subject: "Flattening" a static library
- From: Daniel Jalkut <email@hidden>
- Date: Wed, 02 Nov 2005 18:28:28 -0500
Is there an easy way to defy the "just a bunch of linked files"
aspect of a static library, such that the compiled object remains
statically linkable but has some of the self-contained qualities of a
dynamic library? I'm in a situation where I have to add a bunch of
sources to a an existing project as a static library, but there are
conflicts between the names of both source files and functions.
Suppose my static library contains these files:
CoreStuff.c
PithyStuff.c
SeedyStuff.c
Each defines functions that are interdependent on each other source
file. Together, they perform a valuable task which can be exposed
through a single function. What are my options for "flattening" the
static library so that, when I go to link it with my existing
project, only the single exported function will contaminate my
existing project's namespace?
Ideally I'd like to be able to create a library that contains,
instead of 3 sections "CoreStuff.o, PithyStuff.o, and SeedyStuff.o,"
a single "BadApple.o," with a single exported function. I suppose I
could create a nasty super-C file that includes all the ".c" files.
Are there other options?
If that's not particularly easy, I might also be interested in some
kind of post-build binary edit of the static library that would
simply go through and append a suffix to every exported symbol, and
every object file name. If I had a library libBadApple.a with
constituent objects named "badApple_CoreStuff.o", etc., and functions
named things like "badApple_HelloWorld()" then I think it would be
sufficient.
If you have any tips on the viability of either of the above
approaches, I'd love to hear them! Of course, I'd also be glad to
hear suggestions for altogether better ways of solving this problem.
Unfortunately, the use of a dynamic library or bundle is not really
convenient here.
Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden