[lmi] shared libstdc++ for mingw32

[Vadim Zeitlin]

 Hello again,

 I've decided to switch this discussion here so that we could reference it
in the archives later.

 First the good news: I did manage to make my sample to work by creating a
shared libstdc++.dll using the commands

        dlltool --export-all --output-exp a.exp --dllname libstdc++.dll \
                --output-lib libstdc++.dll.a /mingw/lib/libstdc++.a
        gcc -shared a.exp /mingw/lib/libstdc++.a -o libstdc++.dll

If I move this libstdc++.dll to /mingw/lib and remove the original
libstdc++.a, then the sample builds with a single linker message (it's not
even a warning):

Info: resolving typeinfo for intby linking to __imp___ZTIi (auto-import)

and works correctly. As a nice side effect, it's also signficantly smaller,
of course.


 Second the bad news: the libstdc++.dll I "built" using the above commands
seems to be not 100% working. First of all, the dll.a file produced doesn't
work at all: if I copy it to /mingw/lib (so that it is used instead of
directly taking the symbols from DLL [nice, I didn't know mingw could do
this]), I get errors:

fu000001.o(.idata$3+0xc): undefined reference to `libstdc___dll_a_iname'
fu000002.o(.idata$3+0xc): undefined reference to `libstdc___dll_a_iname'
nmth000000.o(.idata$4+0x0): undefined reference to `_nm___ZTIi'
collect2: ld returned 1 exit status

And if I don't use it but use just the libstd++.dll, the wx DLLs can't be
built as I get tons of errors like this:

variable 'vtable for __cxxabiv1::__vmi_class_type_info' can't be
auto-imported. Please read the documentation for ld's --enable-auto-import
for details.


 Conclusion: it seems clear that using shared libstdc++.dll does solve the
problem. It's also clear that the dlltool hack I used to create it from
static lib doesn't quite work. If you agree with using the dll, then
someone should look into building it correctly. Using the DLL has
obvious advantages: exceptions work, total size is smaller and linking
faster but also a disadvantage: it is not standard and so is another setup
step. I do believe it's worth it though. BTW, the reason libstdc++.dll is
not included in mingw32 is because some people think that using it would
force any applications compiled with g++ to fall under GPL. I don't see how
can anyone seriously believe this but in any case this is not a problem for
lmi, of course.

 Please let me know if I should continue with trying to build a working
libstdc++.dll. If the answer is yes, I'd prefer to do it now rather than
return to it later and lose time in "context switches".

 Thanks,
VZ