If I compile and link an executable with the -export-dynamic flag, it doesn't apply to symbols stored in archives that are linked. The flag only on exports symbols for objects that are linked that aren't in archives. Can someone explain why this would be?
A:
Because archives don't import or export anything.
A '.a' file is just a compendium of '.o' files. There is no concept of import and export until they are linked, either into an executable or a shared library. There is no data structure in an 'ar' archive to store such a thing.
bmargulies
2010-01-28 17:32:10
But when I link the executable together with the archive, it *could* pull all the symbols for each .o in the archive, couldn't it? Or does the actual executable end up different in the end if you link against the .o's individually vs. a .a of the .o's?
jdizzle
2010-01-28 17:54:59
It can be different unless you use --whole-archive, which is a relatively recent invention. Nested archives are news to me.
bmargulies
2010-01-28 20:27:54
Part of our build process was adding an archive to an archive, but I think it's actually a bug/oversight. We're linking against the nested archive explicitly, so I think the nested archive is being ignored as unrecognizable.
jdizzle
2010-01-29 14:17:11
A:
The problem seems to be that .o files inside .a files are only linked if they are needed by the executable (apparently it's called "dead-stripping"). In my case, the symbols are only required by a shared library that is explicitly opened with dl commands. I can link with the --whole-archive option (on GNU, at least), which will force the linking of all the objects in the archive.
jdizzle
2010-01-28 18:21:58
Please use comments, or edit your question, instead of creating an answer.
bmargulies
2010-01-28 20:27:19
Why? I'm allowed to answer my own question. In fact it recognizes that use-case specifically.
jdizzle
2010-01-29 14:14:09