Hi Patrick, 2012/1/3 Patrick Spendrin <ps...@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 ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
