On Sun, Apr 7, 2013 at 11:53 PM, Geoff Worboys <geoff@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > 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.) I just have some painful past experience. > ... > There also remains the possibility of globals named the same > in both libraries and not intended to be exported. Most of Yes, this is the potential problem I have encountered in the past. An application linked to <somelib.a> with a global object, and a shared object used by the program also linked against <somelib.a>. > 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.) I use a function with a static local since it also fixes the order-of-initialization problem. I'm not sure inlines and anonymous namspaces do the later. Jeff
