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

[Christian Stimming]

Am Dienstag, 27. Dezember 2011, 22:51:46 schrieb Geert Janssens:
> > There is enough goofiness with MinGW GCC 4.4.0 that I couldn't get it to
> > link properly in a couple of places, and the one that ultimately kicked
> > my butt was libgsf->libxml2, where the linker won't accept that
> > xmlGenericError actually *is* exported, even though several other
> > libraries link it just fine.

My first thought was that there might be multiple libxml2.dll somewhere in the 
various packages (such as one from gnome or ourselves and another one in 
ActivePerl, or similar). But I guess you've already checked for those.

> > So I spent a couple of (partial) days with GCC 4.5 guile 1.8.7. No joy
> > (and this won't be any surprise to Geert) because Slib has an issue
> > with its load path. It sure looks to me like Guile treats paths
> > differently under Win32 than under Darwin & Linux, because (use-modules
> > (ice-9 slib)) works fine in the latter and fails with a duplicated path
> > in the former. I'm very much a Scheme/Guile noob, though, so I'm very
> > likely missing the real problem. I can't even add (write) calls to get
> > guile.init to tell me where it's going astray.
> > 
> > So at this point I'm not sure where to go. It's tempting indeed to say
> > that Geert should just backport the changes that got rid of SLib:
> > They're not likely to be central to anything besides reports -- and
> > besides, they're known to mostly work. OTOH, it seems risky to
> > introduce a significant change right before a release... so how
> > significant are the changes?
> 
> I'm very sorry GCC 4.4 didn't work out. I had really hoped I didn't succeed
> because my knowledge of the build system was too limited, but clearly there
> are other issues.
> 
> While you were at it, I already silently tried to backport all guile 1.8.8
> related changes to 2.4, but that didn't succeed either. I probably still
> missed some commits.
> 
> This continues to show what a hornet's nest the depedencies on Windows are.
> 
> At this point I'm actually more inclined to go for plan B, forget the
> dependency updates on 2.4 and instead focus on getting 2.6 ready and with
> aqbanking 5.

I can't add any wisdom as well. Concerning the errors the two of you are 
reporting, I also don't have any further idea.

Hence, in order to get a new release up and running, I would indeed also vote 
for getting a 2.5/2.6 version ready in the rather near future, instead of 
trying other random bits with the 2.4 branch. Of course, if anyone still finds 
out what's wrong with the current 2.4 build, this would be fine as well, but 
on the other hand investing one's time in the new branch is probably the more 
future-proof investment of time...

Regards,

Christian