r21768 - gnucash/branches/2.4/packaging/win32 - More changes to compile gtk-2.24.

Christian Stimming christian at cstimming.de
Fri Dec 30 17:21:52 EST 2011


Am Donnerstag, 29. Dezember 2011, 15:11:39 schrieb John Ralls:
> >> Which turned out to be more WebKit contamination, sort of. Ktoblzcheck
> >> needs a couple of libraries from mingw (libstdc++-6.dll and
> >> libgcc_s_dw2-1.dll) and we were relying on WebKit to provide them --
> >> but it only provides an older version of libstdc++-1.
> > 
> > Very interesting. Now, libktoblzcheck isn't anything miraculous - it's
> > just a C++ library that we build ourselves. Apparently once we do this,
> > the libstdc++ of the compiler needs to be present but hasn't been so
> > far.
> > 
> > This change is most probably also needed in trunk, isn't it?
> 
> It wouldn't matter whether we built it or got a binary from somewhere: If it
> links against libstdc++, it has to have it. C++ library symbols are
> "mangled" in a compiler-specific way, so it's not possible to link a
> program made with one compiler against a library made with another. But
> that wasn't the problem here: The libstdc++-6 that WekKit provided didn't
> define a symbol that ktoblzcheck wanted (__gxx_personality_v0), but there
> are a couple of dozen others that it was perfectly happy with. That
> indicates a libstdc++-6 version problem rather than a wrong compiler
> problem.

Yes: From the description it sounds as if webkit's libstdc++6 was older than 
the one of the mingw that we use. Hence the newer one of mingw has some symbol 
which the older one hasn't, and this is what the hand-compiled ktoblzcheck 
complains about. But I don't know libstdc++ version details here.

> It looks to me from the symbols imported from libgcc_s_dw2-1 (Unwind_resume,
> _deregister_frame_info, _moddi3, and _register_frame_info) that it has to
> do with debugging, so we might be able to get rid of that dependency by
> changing CFLAGS.

I tried, but apparently linking against libstdc++ always pulls in this 
libgcc_s. There were no CFLAGS or similar that triggered the linking to this 
library, nor were there any that could be removed to remove this dependency.

> I don't know if it needs changing in trunk. AQB works there, right?

I haven't checked myself on windows, ever. From the gnucash-de mailing list 
reports apparently it does work.

Regards,

Christian


More information about the gnucash-devel mailing list