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