On Sun, Apr 7, 2013 at 10:27 PM, Geoff Worboys
<geoff@xxxxxxxxxxxxxxxxxxxxxxx> 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
