The library files are being compiled with :
[bash]-fPIC -fvisibility=hidden -fvisibility-inlines-hidden -ffunction-sections -fdata-sections [/bash] and linked with :
[bash]-static-libgcc -ldl -Wl,--gc-sections[/bash] The problem is the library size blow up to a amazing 17MB, without the above settings it's 28MB.. If I do a strip on the library afterwards, we get down in about 13-14MB, which is still too much. Looking at the output of nm it seems the hidding does not work properly, since it's exporting a large number of functions still.
With exact the same settings I can get 5.5MB after strip with gcc and 9MB before strip.
Even if I compile with intel and link with gcc directly, then the problem persists.
What settings do I need to set for intel to remove all the redudancy ?
The problem is that it exports a huge number of functions, which is not marked to be exported.
I think you need to review a couple of cases when some functions, declared as non-exported, are included in
a binary file of the shared library. I would consider cases:
1. If some 'FunctionA' is declared as inline, has implementation in a header file, and called at least
once in your codes onlythenithas to be included in a binary file ( this is expected result )
2.If some 'FunctionB' is declared as inline, has implementation in a header file, and not called at all in
any codes then it doesn't have to be included in a binary file ( this is expected result ).If it is included
then it looks like there is a problem with a C/C++ compiler.
The Boost is a huge template library andasimpleC++ templates-based test-case that uses atest shared
library, with some set offunctions declared differently,could helpto understand the problem.
32053 2012-03-29 09:57 t_gcc_ia32.so
30388 2012-03-29 09:56 t_icc_ia32.so
43273 2012-03-29 09:51 t_gcc_x64.so
15513 2012-03-29 09:50 t_icc_x64.so
cmd used is from your posting with "-fPIC": icpc -fPIC -shared t.cpp -fvisibility=hidden -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -Wl,--gc-sections -o t.so
So I might have missed something. Please let me know if the above is the what you have. We'd like to improve the code size issue if possible.
I might not have explained it clear enough, but above example is just a small one illustrating that exports end up in the library, which is not intended and most certainly different from gcc. So I was not argumenting on library size on this example only the exports. I think what goes on for my large library is that soo many functions get's exported, which makes the linker command --gc-section useless, since it can not tell which ones are not needed. Since my code is huge, I thought starting with having similar exported function like gcc was a good starting point. Try to run nm test.so | grep " T " on your two libraries.
With the "grep" cmd, I did see the big difference in the symbols being exported.
Let me file a bug to the compiler about this issue, but I'm not sure how likely it can be addressed in the current release though.