Unstable development, guile 1.8 and gcc 4.5.2

Phil Longstaff plongstaff at rogers.com
Tue Mar 22 09:21:21 EDT 2011


Forgot to add: one advantage if this works vs the script to build webkit in the 
gnucash tree is that this method doesn't require cygwin but uses mingw+msys.

 Phil
---------
I used to be a hypochondriac AND a kleptomaniac. So I took something for it.




________________________________
From: Phil Longstaff <plongstaff at rogers.com>
To: Geert Janssens <janssens-geert at telenet.be>; gnucash-devel at gnucash.org
Sent: Tue, March 22, 2011 9:14:50 AM
Subject: Re: Unstable development, guile 1.8 and gcc 4.5.2


Geert,

you say "the updated gcc can't build the stable branch on Windows".  What is the 
problem?

I don't have the details handy, but I am experimenting with a different gcc 
build (tdm gcc http://tdm-gcc.tdragon.net/) which seems more up-to-date than 
mingw.  I am trying to build webkit/gtk for win32 from source using instructions 
I found on-line 
(http://opensourcepack.blogspot.com/2011/01/building-webkitgtk-on-windows.html). 
 No success yet as I'm still working on a common build environment for webkit 
and gnucash.

 Phil
---------
I used to be a hypochondriac AND a  kleptomaniac. So I took something for it.




________________________________
From: Geert Janssens <janssens-geert at telenet.be>
To: gnucash-devel at gnucash.org
Sent: Tue, March 22, 2011 8:05:55 AM
Subject: Unstable development, guile 1.8 and gcc 4.5.2

I had the privilege to apply the fist series of patches to trunk after the 2.4 
branch was created. After some IRC chat with Derek yesterday, I think these 
patches require some more explanation and discussion.

The birdseye view to this issue is this:
* In total I applied 12 patches, which actually are all  required to get the 
Windows build working with guile 1.8.
* These patches have been tested and work (on my system), but are fairly 
invasive, as they require a gcc update.
* This is no problem if you are only interested in the unstable branch.
* It becomes a problem if you wish to be able to build either the unstable 
branch or a stable branch alternatively in one and the same mingw environment, 
because the updated gcc can't build the stable branch on Windows.

We need to find a solution for this on our own (Windows) build server. Your 
feedback on this is welcome.

If you care about this, or want to know more, please read on for the more 
detailed version.

For reference, the patches are:
1.  http://svn.gnucash.org/trac/changeset/20435
2.  http://svn.gnucash.org/trac/changeset/20436
3.  http://svn.gnucash.org/trac/changeset/20437
4.  http://svn.gnucash.org/trac/changeset/20438
5.  http://svn.gnucash.org/trac/changeset/20439
6.  http://svn.gnucash.org/trac/changeset/20440
7.  http://svn.gnucash.org/trac/changeset/20441
8.  http://svn.gnucash.org/trac/changeset/20442
9.  http://svn.gnucash.org/trac/changeset/20443
10. http://svn.gnucash.org/trac/changeset/20444
11. http://svn.gnucash.org/trac/changeset/20445
12. http://svn.gnucash.org/trac/changeset/20446

Let me start with some background on these patches. Why 12 and why are they 
all required ?

I started this work a couple of months back [1], attempting to get guile 1.8.7 
running on Windows. This didn't work at all back then, because guile 1.8.7 had 
bugs that prevented it from being built on Windows. These bugs have been fixed 
in guile 1.8.8, so I restarted my attempts as soon as 1.8.8 was out.

It became clear quite early in the process that is was not possible to build 
the more  recent guile with gcc 3.x. So as a first intermediate step, I tried 
to get guile 1.6 (the old version) to build with gcc 4.x. Unfortunately after 
many attempts and tweaks I didn't manage to do so.

So the choice for Windows was guile 1.8.8 with gcc 4.5.2 or guile 1.6.x with 
gcc 3.x. I just didn't find another way.

Getting the window build compiling with gcc 4.5.2 and guile 1.8.8 is the work 
of patches 5, 8, 9 and part of patch 10. Initially I didn't remove the slib 
stuff, because it was still used in many parts of GnuCash. But while I could 
build guile 1.8.8 with gcc 4.5.2, it didn't work at all with slib. For some 
reason the search path used by slib's "require" function was completely 
garbled in the new setup. There are two slib functions which are used a lot in 
GnuCash: require and printf. But require is even used to test if slib is 
installed correctly at configure time (both for guile/slib on  windows as for 
gnucash on all platforms). I did spend some time trying to correct this, but 
eventually I gave up. The primary reason is that I remembered a set of patches 
by Andy Wingo to remove the slib dependency from gnucash [2]. So it would be a 
waste of effort to get slib running in the new setup, only to remove it again 
shortly afterwards. So instead, I chose to apply Andy's patches first 
(temporarily breaking the build on Windows in the process), and simply remove 
the slib dependency completely before updating guile itself. These are the 
first 4 patches in the list.

The remaining patches are just some cleanup actions for small bugs that 
appeared as a result of the other patches.

That's the background on the patchset. I have tested it, and it works fine 
here. So in itself this patchset is good for trunk.

So where's the problem ?

As said before, due to some compilation issues, it's  either gcc 4.5.2/guile 
1.8 or gcc 3.x/guile 1.6. A mixed combination doesn't work. And I'm 
simplifying this slightly, because gcc has it's own depencencies on mingwrt.  
I don't remember exactly, but I *believe* the mingwrt version required by gcc 
4.5.2 isn't compatible with gcc 3.x and the other way around. And something 
similar may be the case for other gcc dependencies.

So that means that the same build environment can't be used anymore for stable 
builds and unstable builds.

If you already had a GnuCash build environment set up earlier and wish to test 
new patches, you can upgrade your build environment with these steps:
* run reset.sh
* remove g++.exe from your mingw/bin directory.
* configure custom.sh to get svn updates from trunk
* update the build scripts (svn update in the directory containing install.sh)
The next run of install.sh will then download and install the proper version 
of gcc and its dependencies over the old ones.

But I haven't tested this in the other direction. I'm not sure you can do the 
same thing to go back to the old gcc and dependencies if you need to build 
from the gnucash 2.4 branch or an older tag somewhere.

Obviously this is only a problem if you intend to build both stable and 
unstable versions of gnucash on one and the same machine. I'm not sure if many 
people are building gnucash on Windows anyways, let alone both stable and 
unstable. But our automated build server is heavily impacted because of this. 
It is configured to automatically build the latest svn trunk commit and any 
tags that weren't build until then. That means it will try to build both 
sources that require the old or the new gcc. Something we can't right now.

So the big question here is, how can we solve this, both short term (the trunk 
build is broken right now) as potentially  long term (so a future major build 
system change doesn't cause the same head-ache again) ?

I don't have a complete answer yet. But here are some thoughts:

* A "minimal" impact solution would be to change the install scripts to allow 
for multiple gcc installations. I'm not sure if this is even possible though. 
gcc may require a particular mingwrt version. And at the same time, we don't 
support multiple build directories for any other dependency. If you want a new 
version of libofx, you need to remove the older version first. By default the 
same would be true for gcc. This may need some tweaking and testing to pull 
off. The advantage of this solution (if it can be done) would be that one 
build system can build all tags and releases, simply because it just has to 
pick the right compiler depending on the target. But both are installed 
alongside one another.

* Slightly more invase approach is to  have independent MSYS/mingw build 
environments depending on what you want to build. This can be set up 
relatively easily. There is a problem with the msys installer script that IIRC 
assumes it's the only installation available and hence interferes with already 
installed msys configurations. But that can be worked around. I am 
successfully using two independent MSYS/mingw configurations for quite some 
time now. This works fine if you manually choose which tag or branch to build, 
because depending on your target, you can choose to work in to old or the new 
build environment. The complication here comes from the automated setup on the 
build server. How can it determine automatically which MSYS/mingw environment 
to use depending on the target ? How does it know it should build trunk in the 
new environment, while 2.4.5 should be built in the old environment. But later 
2.5.0 should be built in the new  environment again ?

* For the build server, we could go one step further and simply have two 
separate VM's, one for the old build environment and one for the new build 
environment. This avoids the msys interference issue from the previous point, 
but the other issue remains ? How does the automated system know in which 
environment to build its targets ? 

* And a last option I hadn't considered so far: if the guile/gcc update turns 
out to be stable enough, we may backport it to the 2.4 branch. That would 
avoid any build system duplication after all. Obviously that would mean the 
build system from that point on wouldn't be able to rebuild old tags, but it 
would be able to build both new tags and trunk. Old tags are normally not 
rebuilt anyway so that may not be an issue. The issue here is that I don't 
want to call this update stable enough. I have tested it locally, but that 
doesn't mean it doesn't  contain bugs.

What do you think ? Which solution would be preferable and realistic (in terms 
of effort vs gain) ?

Geert

[1] https://bugzilla.gnome.org/show_bug.cgi?id=621238
[2] https://bugzilla.gnome.org/show_bug.cgi?id=615168
_______________________________________________
gnucash-devel mailing list
gnucash-devel at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


More information about the gnucash-devel mailing list