[Mingw-w64-public] __cxxabiv1 linker issues

[Kai Tietz]

Hi Patrick,

2012/1/3 Patrick Spendrin <ps_ml at gmx.de>:
> Hi everybody,
>
> we are currently using the 4.4.7 build of ozkan, but due to a bug in the
> std::string handling (copying std::string's across dll boundaries
> corrupts the heap) we now have to update our compiler.

Well, this might be caused by missing build-option about dynamical strings.

> We have hit an issue with all the compilers tested so far:
> when linking binaries build with -Wl,disable-auto-import we get a lot of
> undefined references to vtable's of __cxxabiv1::__function_type_info
> etc. This can be fixed by either using the static libstdc++ or by
> removing disable-auto-import. Since we want to keep disable-auto-import,
> do you have an idea how to fix this?
> My first idea was to check for the exports of the libstdc++ dll but
> those are correct and the symbols in question are contained inside the
> libstdc++. Looking for the header in question, the symbols are not
> exported via declspec(dllexport), but that would have given other linker
> errors as well (e.g. about the destructor of those classes). Also, it
> doesn't seem as if the header file for those symbols is read at all, the
> compiler doesn't seem to take a look at cxxabi.h (even though it will do
> so later in our build).
Well, and this might be the real underlying issue.  As auto-import
explicit handles to translate from non-dllexported-symbols to the
imported dllexported-symbols, it solves the issues.  libstdc++ doesn't
provide for Win32 targets proper declspeced symbols for import.  There
is already a gcc bug-report for it.  IIRC the initial plan here was
that this declspec-exporting/importing shall be done via attributed
namespace, but this feature isn't implemented until now.

> So my question is: what is different in that part of gcc between those
> versions (we tested sezero 4.5 and rubenvb 4.6.3-1).

Well, here Ozkan and Ruben might be better able to describe the differences.

> regards and thanks for all your work,
> Patrick

Regards,
Kai