On 10/03/2010 01:09 AM, Robert Ramey wrote:
Marsh Ray wrote:
On 10/02/2010 12:56 AM, Lars Viklund wrote:
On Wed, Sep 29, 2010 at 06:48:55PM -0800, Robert Ramey wrote:
Chris Yuen wrote:
Hey guys,
I am using boost::serialization from 1.44.0. One thing that I noticed is that linking statically to the serialization libs will add several hundred exports in the final exe file that I get. Using `dumpbin /exports my_program.exe`
These functions are not explicity called from the library. But they ARE called as part of the serialization process. Its just that MSVC doesn't see them. So when you compile for release, The MSVC Linker strips them out and the program won't work anymore. In order to work around this, these functions are explicitly exported. This prevents MSVC from stripping them out. For more information see force_include.hpp
The problem with exporting is that it adds a semantic meaning which is unwanted.
I'm not seeing this.
Adding an entry to the export table says "separately linked code can call me via this exported name/ordinal". I don't think this is the meaning that was intended.
I think the /include linker option is supposed to do what you want:
http://msdn.microsoft.com/en-US/library/2s3hwbhs%28v=VS.80%29.aspx "Specifying a symbol with this option overrides the removal of that symbol by /OPT:REF."
You can even specify it in the source:
#pragma comment(linker, "/include:__mySymbol")
http://msdn.microsoft.com/en-us/library/7f0aews7%28VS.80%29.aspx
I don't see how one could pass a symbol generated by template to to a linker switch or to a pragma.
Yeah good point. Perhaps template instantiation could generate a reference to the symbol from within some other object that does have a fixed name? I'm sure I've seen this done somewhere but don't recall exactly how. Maybe something involving the template generating a static data member with a constructor that passes the object's address to some function the linker cannot eliminate, and there had to be at least one function actually called in that translation unit in order to prevent the linker from throwing it out entirely. Not saying it's necessarily a great solution, but...
These exported symbols are excellent for provoking bugs in software that makes assumptions about the maximum reasonable length a symbol should be able to have.
I'm no seeing this either. I don't see how that this symbol information is accessible. Even if it is, I don't see how it could be used.
It goes into the the PE32 "export table", usually by name. IIRC, the export table points to NUL-terminated strings with a length limitation in some obscure document somewhere. These export table names are visible without debug symbols and are to be compared case insensitively.
Someone else has reported that msvc no longer strips these symbols but has been unable to test this. I don't see how it's possible for the compiler/linker to know which unreferred to symbols can be stripped and which cannot be.
Generally, unless it's exported, or called or address taken by something which is not removed, then it will be removed by /OPT:REF.
GCC has some attributes which one can attach to flag function which shouldn't be stripped so it's not a problem there. The IBM compiler recently added attributes handle this as well.
That sounds like a better design for C++ than the linker option. - Marsh