Re: "Flattening" a static library
Re: "Flattening" a static library
- Subject: Re: "Flattening" a static library
- From: Rush Manbert <email@hidden>
- Date: Thu, 03 Nov 2005 17:22:52 -0800
Daniel Jalkut wrote:
<snip>
The linker can link several object files into a single object file.
Can you do this with your static lib object files, then create a
static library from the single object file that you created? It seems
like that would pull in all of your code, and it will be correctly
linked internally. Of course, then you will have problems with
multiple symbol definitions. (which you might be able to sidestep by
using the dangerous -m flag to ld)
When the linker links several object files into a single object, it
seems to retain the separate modules. In fact, the interdependencies
between the separate modules in the archive are not resolved until the
archive is linked in with the application at final link time. Are you
suggesting there is a linker option to cause all the separate ".o" files
to be linked into a self-contained, non-dynamic library? That's exactly
what I want if such a thing exists.
Hi Daniel,
One last time and I'll shut up. It sounds like you have already tried
what I was thinking about, and the linker didn't do what I expected. I
would expect that linking a.o, b.o, and c.o to create d.o would resolve
all of the dependencies between a, b, and c, but that doesn't seem to be
the case from what you said above. That sucks...
>> Another approach along these lines. Link all your static lib object
>> files together to form a single object file, then apply a binary edit
>> (that you must write, I guess) that removes all entry point
>> definitions except your single function. Then throw the resulting file
>> into the final link, or make a static lib out of it. This is like your
>> idea of editing the static lib, but it might be easier to strip the
>> entry point definitions than it would be to change all of them.
>>
>
> I tried something like this using an export file and the "nmedit" tool.
> It turns all the non-exported functions into static, private functions.
> But since the archive (static library) is arranged as this unresolved
> collection of modules, this causes the interdependencies to fail to
> resolve with the static library is linked in with the final product.
>
Yes, I would only expect something like this to work if the linker would
do what I wanted it to do. :-(
>> Hmmm, maybe making your "super-C" file isn't such a bad idea. There
>> aren't any pretty solutions that I can think of...
>>
>
> I might give that idea a spin... just feels so ... dirty :)
I understand. Icky as anything. :-)
Good luck,
Rush
_______________________________________________
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