dllexport and inline methods

[Jeffrey Walton]

On Sun, Apr 7, 2013 at 11:53 PM, Geoff Worboys
<geoff@telesiscomputing.com.au> 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