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

[John Ralls]

On Dec 27, 2011, at 1:57 PM, Christian Stimming wrote:

> 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...


Jeez, you guys give up *way* too easily! ;-)

The problem with SLib turns out to be a Guile bug: ice-9/boot-9/load-modules determines a absolute path isn't portable, which is why we were seeing the "double" paths. The easy fix is a one-liner. I'd file a bug, but "Submit" is crossed off in the menu, so to hell with them. (The problem may or may not exist in 2.0; the code is totally different, so I can't tell without testing, and I'm not going to take time now to do that.)

I'd mis-diagnosed the libxml problem, too. After I got past the SLib issue and got a dist made, I had the same symbols problem again. This turns out to be a disconnect between install-impl.sh and dist-impl.sh: Install builds libxml2 from source for Gnome, and dist used a downloaded binary. That isn't going to work.

So with the changes checked in (and a reset.sh), it should build a working package... at least, it does here.

It's still not quite ready for release: Gnucash isn't noticing that AQB is present.

But it's bedtime now, and tomorrow's Habitat.

Regards,
John Ralls