Jeffrey Walton wrote: > On Sun, Apr 7, 2013 at 10:27 PM, Geoff Worboys >> QUESTION: Does anyone know of any down-side to using >> --export-all-symbols other than the increase in interface >> size (and resulting startup impact)? > I believe there are two. First is violation of the One > Definition Rule. Destructors could run twice on the same > object and cause a crash (if the linker combines symbols). > Second is an increased export symbol table size. The second I can live with because I can eliminate that when I create the cleaned-up def file to control the export. The first is obviously more of a concern. Do you happen to have a link to anything that might cover the destructor part of the problem in more detail? (Something that might explain when/why it happens and how to avoid it. The only Google results I found appeared to be discussing Linux builds.) If I understand correctly, most of the detritus I am seeing inside the --export-all-symbols result comes from inline functions from the std and runtime libraries that were needed by the library itself. I'm not clear on exactly how this will be dealt with if the executable and/or other libraries use the same functions, but I'm assuming/hoping that will be handled as part of the normal exemption inline gets from ODR. There also remains the possibility of globals named the same in both libraries and not intended to be exported. Most of those can be hidden inside unnamed namespaces. (I have one exception to that in my current library - so far it appears to be working as expected.) Thanks for your input. -- Geoff Worboys Telesis Computing Pty Ltd
