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

[John Ralls]

On Dec 24, 2011, at 11:37 AM, John Ralls wrote:

> 
> On Dec 24, 2011, at 9:02 AM, Geert Janssens wrote:
> 
>> Op zaterdag 24 december 2011 08:06:28 schreef John Ralls:
>>> On Dec 24, 2011, at 6:04 AM, Geert Janssens wrote:
>>>> Op vrijdag 23 december 2011 21:45:02 schreef John Ralls:
>>>>> On Dec 22, 2011, at 11:07 PM, John Ralls wrote:
>>>>>> This produced a problem with gettext, but it's too late to
>>>>>> investigate
>>>>>> tonight. I'll have a look at it in the morning.
>>>>> 
>>>>> After a bit of a struggle with gettext, goffice, and openSP
>>>>> (mismatched
>>>>> compiler for the binaries of gettext-0.18.1.1-2, but 0.18.1.1-1 works;
>>>>> goffice-0.7 uses a Gtk class that's supposed to be deprecated in
>>>>> Gtk-2.24 but seems to be removed, and the C++ packaging of mingw
>>>>> libstdc++ was screwed up), I got a build all the way through most of
>>>>> Gnucash (it failed to set up a gconf directory in gnucash-2.4/inst).
>>>>> Close enough to commit today's work and see what happens on the
>>>>> nightly, so I did.
>>>> 
>>>> Thanks for your debugging efforts.
>>>> 
>>>> The nightly build failed at mingw already. But I assume this is normal
>>>> as you changed the gcc version. I have run a reset.sh on the server to
>>>> start with a clean environment and started another build. This is
>>>> running now, we'll see what the result will be.
>>> 
>>> Great, thanks.
>>> 
>>> Is there a way to tell the buildbot to run reset.sh without a) shell access
>>> or b) adding it at the top of install.sh?
>>> 
>> Not that I know of.
>> 
>> The build is now compiling the GnuCash sources, so it's proceeding nicely.
>> 
>> I won't be available anymore from now on until probably Tuesday. So if more 
>> actions are needed on the build server, either someone else will have to take 
>> over or it'll have to wait until Tuesday.
>> 
>> In any case,
>> 
>> Merry Christmass to all.
> 
> Well, it built, but it doesn't work. First, it couldn't find libgdk-pixbuf because I hadn't adjusted dist-impl.sh to include it. Next, it can't find an "entry point" (xmlGenericError) from libxml2.
> 
> I've worked around my install problem from last night (just needed to delete the inst directory and try again), so I'll try to get the last few issues sorted today.

Well, that didn't actually work out.

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.

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?

Regards,
John Ralls