Thanks again for responding:On Nov 3, 2005, at 11:41 AM, Rush Manbert wrote: Oh, sorry. So some of the functions in the static lib don't get pulled in by the linker because it already has a function with the same signature that is part of your app?
Yep. Say a function "PeelRind()" is defined in my app and in the static library. When one of the modules in the static library resolves "PeelRind()" it uses the version already defined in my app. It sounds like you have these limitations:
* You're in C, so no namespaces. * You can't change the static lib sources, or their file names. * You can't change the conflicting names in the app.
Yep, more or less. I *can* change the sources but I would rather not. Because there is a likelihood that I'll need to synchronize these changes over time with the originators of the source. I can try to convince them to change their code to use more unique symbol names, but I'd rather not push my technical problem back onto them. (If this is not true, then how about adding module-specific function name prefixes to the app sources? That will keep them from conflicting with your lib sources, although it's sort of backward from the more general solution of adding module-specific prefixes to the static lib sources. That would keep the static lib from conflicting with anything in the next app you link to it.)
I have done this as a temporary workaround. I will probably keep this solution unless I come up with something more automatic to do the trick. 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. 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. 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 :)
Thanks again for your comments, Daniel
|