dllexport and inline methods

[Jeffrey Walton]

On Sun, Apr 7, 2013 at 10:27 PM, Geoff Worboys
<geoff@telesiscomputing.com.au> wrote:
> I wrote:
> [...]
>>     class __declspec(dllexport) A {
>>     public:
>>         int fa() { return m; }
>>         int ga();
>>     private:
>>         int m{0};
>>     };
>
>>     class __declspec(dllexport) B {
>>     public:
>>         int fb();
>>         int gb();
>>     private:
>>         int m{0};
>>     };
>>     inline int B::fb() { return m; }
>>
>>     class C {
>>     public:
>>         int fc() { return m; }
>>         __declspec(dllexport) int gc();
>>     private:
>>         int m{0};
>>     };
> [...]
>> Notice that inline methods for class A and class B are NOT
>> being inlined inside the library (and the compiler does tell us
>> why in the case of B::fb()).
> [...]
>
> For those of us that would like to be able to build optimised
> shared libraries under Windows, without having to rewrite all
> code to look like class C above, I think I have found a work-
> around.
>
> An off-list reply to my query suggested I play with .def files.
> I had previously discarded using def files as being too hard
> with C++.  But it turns out not to be so hard.
>
> First step:
>
>   Stop using dllexport and dllimport with mingw/gcc.  Leave
>   your macros in place so they will work with msvc builds, but
>   under gcc set to them to blank.
>
>   Add this to your linker commands: -Wl,--export-all-symbols
>   (the -Wl, prefix needed if passing through gcc/g++)
>
>   Make sure your build produces its own def file:
>     -Wl,--output-def=mylib.def
>
> ...
> 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.

Jeff