Am Thu, 02 Aug 2012 00:30:35 +0200
schrieb "Stefan Frijters" <sfrijters@gmail.com>:

> On Sunday, 15 July 2012 at 15:11:03 UTC, Sönke Ludwig wrote:
> >
> >>
> >> Anyway, building a compiler on the raspberry pi worked for me,
> >> although
> >> it took a long time to build. I created a new wiki page with
> >> build
> >> instructions:
> >> https://bitbucket.org/goshawk/gdc/wiki/Raspberry%20Pi
> >>
> >
> > I've done some new attempts. After using a different OS image on a different SD card, everything worked much better (raspbian "Pisces"). I followed your instructions on the wiki page but had to change arm-linux-gnueabi to arm-linux-gnueabihf and later removed them altogether with the same effect.
> >
> > However, compilation got stuck at the same place as before. It couldn't find <bits/predefs.h> and other architecture specific files. Symlinking from /usr/include/arm-linux-gnueabihf/* to gcc/* helped a bit until it stopped with the same error as in the build log that I posted before.
> >
> > I will probably just try the debian image, although a system with hardfloat support would be pretty important in the long run. But the fact that it doesn't find the /sys/, /bits/ etc. headers sounds like it is just some stupid little build problem. But I'm much too unfamiliar with the GCC build process to make effective guesses for a solution.
> 
> Following the instructions at Johannes Pfau's link above I managed to get the compiler up and running on the squeeze image (not counting stupidity on my part which made the compilation fail more than six hours into the process...). So thanks for that! However, I am curious if anyone has made any progress getting it to work on the raspbian image. I will try some things tomorrow (though I'm a newbie, so I doubt I'll get very far on my own) but with the 8-hour compilation cycles I would like to avoid any stupid mistakes if possible. Any experiences or tips would be helpful!
> 
> Regards,
> 
> Stefan
> 

I haven't tried raspbian yet, but it's always good to make sure all packages necessary for building gcc are installed (make sure to do this before calling the gcc configure script!):
-----------
sudo apt-get install build-essential git
sudo apt-get build-dep gcc
-----------
also make sure to enable swap.

Usually the configure flags described on GDC's main page work fine:
-----------
../configure --enable-languages=d --disable-bootstrap \
        --disable-shared --disable-nls --prefix=/opt/gdc \
        --with-bugurl="https://bitbucket.org/goshawk/gdc/issues" \
        --enable-checking=yes \
        --disable-libgomp --disable-libmudflap
-----------

but you can also have a look at the flags the system gcc has been compiled with:
-----------
gcc -v
-----------

On Thursday, 2 August 2012 at 07:49:14 UTC, Johannes Pfau wrote:
> Am Thu, 02 Aug 2012 00:30:35 +0200
> schrieb "Stefan Frijters" <sfrijters@gmail.com>:
>
>> On Sunday, 15 July 2012 at 15:11:03 UTC, Sönke Ludwig wrote:
>> >
>> >>
>> >> Anyway, building a compiler on the raspberry pi worked for me, although
>> >> it took a long time to build. I created a new wiki page with build
>> >> instructions:
>> >> https://bitbucket.org/goshawk/gdc/wiki/Raspberry%20Pi
>> >>
>> >
>> > I've done some new attempts. After using a different OS image on a different SD card, everything worked much better (raspbian "Pisces"). I followed your instructions on the wiki page but had to change arm-linux-gnueabi to arm-linux-gnueabihf and later removed them altogether with the same effect.
>> >
>> > However, compilation got stuck at the same place as before. It couldn't find <bits/predefs.h> and other architecture specific files. Symlinking from /usr/include/arm-linux-gnueabihf/* to gcc/* helped a bit until it stopped with the same error as in the build log that I posted before.
>> >
>> > I will probably just try the debian image, although a system with hardfloat support would be pretty important in the long run. But the fact that it doesn't find the /sys/, /bits/ etc. headers sounds like it is just some stupid little build problem. But I'm much too unfamiliar with the GCC build process to make effective guesses for a solution.
>> 
>> Following the instructions at Johannes Pfau's link above I
>> managed to get the compiler up and running on the squeeze image
>> (not counting stupidity on my part which made the compilation
>> fail more than six hours into the process...). So thanks for
>> that! However, I am curious if anyone has made any progress
>> getting it to work on the raspbian image. I will try some things
>> tomorrow (though I'm a newbie, so I doubt I'll get very far on my
>> own) but with the 8-hour compilation cycles I would like to avoid
>> any stupid mistakes if possible. Any experiences or tips would be
>> helpful!
>> 
>> Regards,
>> 
>> Stefan
>> 
>
> I haven't tried raspbian yet, but it's always good to make sure all
> packages necessary for building gcc are installed (make sure to do
> this before calling the gcc configure script!):
> -----------
> sudo apt-get install build-essential git
> sudo apt-get build-dep gcc
> -----------
> also make sure to enable swap.
>
> Usually the configure flags described on GDC's main page work fine:
> -----------
> ../configure --enable-languages=d --disable-bootstrap \
>         --disable-shared --disable-nls --prefix=/opt/gdc \
>         --with-bugurl="https://bitbucket.org/goshawk/gdc/issues" \
>         --enable-checking=yes \
>         --disable-libgomp --disable-libmudflap
> -----------
>
> but you can also have a look at the flags the system gcc has been
> compiled with:
> -----------
> gcc -v
> -----------

Thank you for the pointers. I just got the results of my first attempt (it failed). I'm getting the same error as reported by Sönke Ludwig above, and after some googling it seems to be related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648889 . I'm now going to retry with 'env CFLAGS="-g -O2 -I/usr/include/arm-linux-gnueabihf" LDFLAGS="-L/usr/lib/arm-linux-gnueabihf" ../configure [etc]'. I put in the "-g -O2" because that is something the make mentioned being there before. I guess I'll know if it worked in the morning...

Cheers,

Stefan

Am Thu, 02 Aug 2012 20:15:47 +0200
schrieb "Stefan Frijters" <sfrijters@gmail.com>:

> Thank you for the pointers. I just got the results of my first attempt (it failed). I'm getting the same error as reported by Sönke Ludwig above, and after some googling it seems to be related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648889 . I'm now going to retry with 'env CFLAGS="-g -O2 -I/usr/include/arm-linux-gnueabihf" LDFLAGS="-L/usr/lib/arm-linux-gnueabihf" ../configure [etc]'. I put in the "-g -O2" because that is something the make mentioned being there before. I guess I'll know if it worked in the morning...
> 
> Cheers,
> 
> Stefan
> 

I didn't know the debian multiarch changes also affect non-multiarch installations. Adding -I/usr/include/arm-linux-gnueabihf to CFLAGS probably works (your link also suggests adding -B/usr/include/arm-linux-gnueabihf though). Adding -O2 -g shouldn't be necessary, the configure scripts should add it when appropriate.

Other solutions:
Patch your gcc sources with debian's multiarch patch (Not sure if those
work for gcc 4.8):
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-multiarch.diff?view=markup
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-multiarch-trunk.diff?view=markup

Use the official debian gcc sources (GCC 4.7) which should
include this patch:
sudo apt-get install gcc-4.7-source
installs the sources at /usr/src/gcc-4.7/gcc-4.7.1-dfsg.tar.xz

On Thursday, 2 August 2012 at 19:10:33 UTC, Johannes Pfau wrote:
> Am Thu, 02 Aug 2012 20:15:47 +0200
> schrieb "Stefan Frijters" <sfrijters@gmail.com>:
>
>> Thank you for the pointers. I just got the results of my first attempt (it failed). I'm getting the same error as reported by Sönke Ludwig above, and after some googling it seems to be related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648889 . I'm now going to retry with 'env CFLAGS="-g -O2 -I/usr/include/arm-linux-gnueabihf" LDFLAGS="-L/usr/lib/arm-linux-gnueabihf" ../configure [etc]'. I put in the "-g -O2" because that is something the make mentioned being there before. I guess I'll know if it worked in the morning...
>> 
>> Cheers,
>> 
>> Stefan
>> 
>
> I didn't know the debian multiarch changes also affect non-multiarch
> installations. Adding -I/usr/include/arm-linux-gnueabihf to CFLAGS
> probably works (your link also suggests adding
> -B/usr/include/arm-linux-gnueabihf though). Adding -O2 -g shouldn't be
> necessary, the configure scripts should add it when appropriate.
>
> Other solutions:
> Patch your gcc sources with debian's multiarch patch (Not sure if those
> work for gcc 4.8):
> http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-multiarch.diff?view=markup
> http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-multiarch-trunk.diff?view=markup
>
> Use the official debian gcc sources (GCC 4.7) which should
> include this patch:
> sudo apt-get install gcc-4.7-source
> installs the sources at /usr/src/gcc-4.7/gcc-4.7.1-dfsg.tar.xz

Thank you once more for the response. My new attempt as described
above failed as well, but for a different reason. However, it
seems I'm reinventing the wheel after all because after more
careful reading it seems I'm now running into the same problem as
Sönke Ludwig had earlier:

/home/pi/gcc-4.8-20120624/objdir/./gcc/xgcc
-B/home/pi/gcc-4.8-20120624/objdir/./gcc/
-B/opt/gdc/arm-linux-gnueabihf/bin/
-B/opt/gdc/arm-linux-gnueabihf/lib/ -isystem
/opt/gdc/arm-linux-gnueabihf/include -isystem
/opt/gdc/arm-linux-gnueabihf/sys-include    -g -O2
-I/usr/include/arm-linux-gnueabihf -O2  -g -O2
-I/usr/include/arm-linux-gnueabihf -DIN_GCC   -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include
-fPIC -fomit-frame-pointer -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -fomit-frame-pointer -I. -I.
-I../.././gcc -I../../../libgcc -I../../../libgcc/.
-I../../../libgcc/../gcc -I../../../libgcc/../include
-DHAVE_CC_TLS  -o _clear_cache.o -MT _clear_cache.o -MD -MP -MF
_clear_cache.dep -DL_clear_cache -c ../../../libgcc/libgcc2.c
In file included from ../.././gcc/tm.h:32:0,
                  from ../../../libgcc/libgcc2.c:31:
../../../libgcc/libgcc2.c: In function '__clear_cache':
../../../libgcc/../gcc/config/arm/linux-eabi.h:117:36: error:
'not_used' undeclared (first use in this function)
  #define CLEAR_INSN_CACHE(BEG, END) not_used
                                     ^
../../../libgcc/libgcc2.c:2068:3: note: in expansion of macro
'CLEAR_INSN_CACHE'
    CLEAR_INSN_CACHE (beg, end);
    ^
../../../libgcc/../gcc/config/arm/linux-eabi.h:117:36: note: each
undeclared identifier is reported only once for each function it
appears in
  #define CLEAR_INSN_CACHE(BEG, END) not_used
                                     ^
../../../libgcc/libgcc2.c:2068:3: note: in expansion of macro
'CLEAR_INSN_CACHE'
    CLEAR_INSN_CACHE (beg, end);
    ^
make[2]: *** [_clear_cache.o] Error 1
make[2]: Leaving directory
`/home/pi/gcc-4.8-20120624/objdir/arm-linux-gnueabihf/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/pi/gcc-4.8-20120624/objdir'
make: *** [all] Error 2

I took a brief look at the offending macro in linux-eabi.h and it
is prefaced by a comment:

/* Clear the instruction cache from `beg' to `end'.  This is
    implemented in lib1funcs.S, so ensure an error if this
definition
    is used.  */
#undef  CLEAR_INSN_CACHE
#define CLEAR_INSN_CACHE(BEG, END) not_used

So it seems that this crash is at least 'by design'. I will try
once more and see if I can get the multiarch patch applied.
However, at this point I have to admit I don't quite know what
I'm doing anymore, so if this fails I think I'll stick with my
squeeze image for now - even though the hard float support is
something I will need later for a hobby project I'm working on.
Again, thank you for your support.

I found some time to test some more configurations: the most recent version on the master branch combined with the 20120805 snapshot of gcc 4.8 failed with the same errors as reported above. Using gcc 4.7.1 (both a fresh copy and a patched copy from the debian repo) I run into a new error. The configure reports two errors (which I didn't notice first time around) which then leads to a compilation error later:

configure:4035: arm-linux-gnueabihf-gcc -V >&5
arm-linux-gnueabihf-gcc: error: unrecognized option '-V'
arm-linux-gnueabihf-gcc: fatal error: no input files
compilation terminated.
configure:4046: $? = 4
configure:4035: arm-linux-gnueabihf-gcc -qversion >&5
arm-linux-gnueabihf-gcc: error: unrecognized option '-qversion'
arm-linux-gnueabihf-gcc: fatal error: no input files
compilation terminated.

Leading to (during compilation):

checking for arm-linux-gnueabihf-gcc... /home/pi/gcc-4.7.1/objdir/./gcc/xgcc -B/home/pi/gcc-4.7.1/objdir/./gcc/ -B/opt/gdc/arm-linux-gnueabihf/bin/ -B/opt/gdc/arm-linux-gnueabihf/lib/ -isystem /opt/gdc/arm-linux-gnueabihf/include -isystem /opt/gdc/arm-linux-gnueabihf/sys-include
checking for suffix of object files... configure: error: in `/home/pi/gcc-4.7.1/objdir/arm-linux-gnueabihf/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `/home/pi/gcc-4.7.1/objdir'
make: *** [all] Error 2

Some googling has told me that these are definitely connected somehow, but I don't know how exactly as my knowledge of the process fails me here. So I guess I'm just throwing it out there in case it will be helpful for someone else!

Cheers,

Stefan

Am Fri, 10 Aug 2012 18:40:46 +0200
schrieb "Stefan Frijters" <sfrijters@gmail.com>:

> I found some time to test some more configurations: the most recent version on the master branch combined with the 20120805 snapshot of gcc 4.8 failed with the same errors as reported above. Using gcc 4.7.1 (both a fresh copy and a patched copy from the debian repo) I run into a new error. The configure reports two errors (which I didn't notice first time around) which then leads to a compilation error later:
> 
> configure:4035: arm-linux-gnueabihf-gcc -V >&5
> arm-linux-gnueabihf-gcc: error: unrecognized option '-V'
> arm-linux-gnueabihf-gcc: fatal error: no input files
> compilation terminated.
> configure:4046: $? = 4
> configure:4035: arm-linux-gnueabihf-gcc -qversion >&5
> arm-linux-gnueabihf-gcc: error: unrecognized option '-qversion'
> arm-linux-gnueabihf-gcc: fatal error: no input files
> compilation terminated.

You probably have to dig deeper in "config.log", as the above output are not really errors. The configure script works with different compilers, some use -V, some -qversion. GCC doesn't use those, it uses -v. There should be a successful test in config.log which checked for -v.

> 
> Leading to (during compilation):
> 
> checking for arm-linux-gnueabihf-gcc...
> /home/pi/gcc-4.7.1/objdir/./gcc/xgcc
> -B/home/pi/gcc-4.7.1/objdir/./gcc/
> -B/opt/gdc/arm-linux-gnueabihf/bin/
> -B/opt/gdc/arm-linux-gnueabihf/lib/ -isystem
> /opt/gdc/arm-linux-gnueabihf/include -isystem
> /opt/gdc/arm-linux-gnueabihf/sys-include
> checking for suffix of object files... configure: error: in
> `/home/pi/gcc-4.7.1/objdir/arm-linux-gnueabihf/libgcc':
> configure: error: cannot compute suffix of object files: cannot
> compile
> See `config.log' for more details.
> make[1]: *** [configure-target-libgcc] Error 1
> make[1]: Leaving directory `/home/pi/gcc-4.7.1/objdir'
> make: *** [all] Error 2
> 
Can you paste libgcc's config.log at some pastebin? I guess
it should be
at /home/pi/gcc-4.7.1/objdir/arm-linux-gnueabihf/libgcc/config.log

On Saturday, 11 August 2012 at 07:20:35 UTC, Johannes Pfau wrote:
> Am Fri, 10 Aug 2012 18:40:46 +0200
> schrieb "Stefan Frijters" <sfrijters@gmail.com>:
>
>> I found some time to test some more configurations: the most recent version on the master branch combined with the 20120805 snapshot of gcc 4.8 failed with the same errors as reported above. Using gcc 4.7.1 (both a fresh copy and a patched copy from the debian repo) I run into a new error. The configure reports two errors (which I didn't notice first time around) which then leads to a compilation error later:
>> 
>> *snip errors*
>
> Can you paste libgcc's config.log at some pastebin? I guess
> it should be
> at /home/pi/gcc-4.7.1/objdir/arm-linux-gnueabihf/libgcc/config.log

Ugh, I was in a hurry yesterday and while cleaning up some stuff (8GB SD card fills up mighty quickly when doing these compilations) I accidentally rm -rf'ed the wrong copy of the build, including the logs. So then I set it to compile again (still rushed) and now I found it's giving completely different errors. Moral of the story: I shouldn't try to do this sort of thing without ample time to check what I'm doing. As I managed to break some packages along the way as well while installing the dependencies of gcc I will now just take a step back, flash a fresh copy of raspbian and do the whole thing from scratch, based on the Debian gcc sources (4.7.1) and the gdc-4.7 branch of GDC.

Thank you for your patience!

Cheers,

Stefan

On Sunday, 12 August 2012 at 12:31:04 UTC, Stefan Frijters wrote:
> Ugh, I was in a hurry yesterday and while cleaning up some stuff (8GB SD card fills up mighty quickly when doing these compilations) I accidentally rm -rf'ed the wrong copy of the build, including the logs. So then I set it to compile again (still rushed) and now I found it's giving completely different errors. Moral of the story: I shouldn't try to do this sort of thing without ample time to check what I'm doing. As I managed to break some packages along the way as well while installing the dependencies of gcc I will now just take a step back, flash a fresh copy of raspbian and do the whole thing from scratch, based on the Debian gcc sources (4.7.1) and the gdc-4.7 branch of GDC.

Ok, went through the cycle again and found another failed build in the morning. But at least I'm back to the same error as before I blew things up. Steps taken:

apt-get install gcc-4.7-source lsb-release autogen
cd /usr/src/gcc-4.7
debian/rules patch | tee patch.log
cp -r src/ /home/pi/gcc-4.7.1-debian/
swapon /dev/sda2
cd /home/pi
git clone https://github.com/D-Programming-GDC/GDC.git
cd GDC
git checkout gdc-4.7
./update-gcc.sh /home/pi/gcc-4.7.1-debian/
cd ../gcc-4.7.1-debian
cat configure | grep libphobos # Patch indeed missing
patch -p1 -i ../GDC/gcc/d/patches/patch-toplev-4.7.x
cat configure | grep libphobos
mkdir objdir
cd objdir

gcc -v # To check for the current flags

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-8+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-8+rpi1)

Here, I matched some flags to go with this gcc and went on to configure:

../configure --enable-languages=d --disable-bootstrap --disable-shared --disable-nls --prefix=/opt/gdc --with-bugurl="https://bitbucket.org/goshawk/gdc/issues" --disable-libgomp --disable-libmudflap --enable-multiarch --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --enable-clocale=gnu --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=yes 2>&1 | tee configure.txt

Result of configure: http://pastebin.com/nznkk91w

DFLAGS="-fno-section-anchors" make 2>&1 | tee build.log

Result of make: http://pastebin.com/fW983aJ8

So now that I know where to look, the config.log of libgcc: http://pastebin.com/1dg8HkA1

The relevant errors seem to be

conftest.c:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP

This is something that is explicitly set in the configure command above to match what I saw in gcc -v. If I remove this, will this remove the advantage of having the hard floats available at all in Raspbian (unlike Squeeze)? Or will this be implicit anyway (and thus cause compilation to fail again) through the way the base gcc is compiled?

Cheers,

Stefan

Am Mon, 13 Aug 2012 11:27:39 +0200
schrieb "Stefan Frijters" <sfrijters@gmail.com>:

> The relevant errors seem to be
> 
> conftest.c:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP
> 
> This is something that is explicitly set in the configure command above to match what I saw in gcc -v. If I remove this, will this remove the advantage of having the hard floats available at all in Raspbian (unlike Squeeze)? Or will this be implicit anyway (and thus cause compilation to fail again) through the way the base gcc is compiled?

Not sure if it's implicit, but if your new compiler doesn't match the system ABI strange things will happen (especially related to floating point, using math functions from libc wouldn't work, ...)

Looks like gcc usually doesn't support -mfloat-abi=hard and --with-fpu=vfp, but the raspbian folks patched their gcc sources to support that. I'm not sure why they haven patched the gcc-source package though.

You probably have to ask the raspbian folks where you can get that
patch.
You could also try to use the gcc sources from the gcc package
(apt-get source gcc), but those sources are already patched for gdc
support, so the ./update-gcc.sh script could fail.

On Monday, 13 August 2012 at 17:41:24 UTC, Johannes Pfau wrote:
> Am Mon, 13 Aug 2012 11:27:39 +0200
> schrieb "Stefan Frijters" <sfrijters@gmail.com>:
>
>> The relevant errors seem to be
>> 
>> conftest.c:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP
>> 
>> This is something that is explicitly set in the configure command above to match what I saw in gcc -v. If I remove this, will this remove the advantage of having the hard floats available at all in Raspbian (unlike Squeeze)? Or will this be implicit anyway (and thus cause compilation to fail again) through the way the base gcc is compiled?
>
> Not sure if it's implicit, but if your new compiler doesn't match the
> system ABI strange things will happen (especially related to floating
> point, using math functions from libc wouldn't work, ...)
>
> Looks like gcc usually doesn't support -mfloat-abi=hard and
> --with-fpu=vfp, but the raspbian folks patched their gcc sources to
> support that. I'm not sure why they haven patched the gcc-source
> package though.
>
> You probably have to ask the raspbian folks where you can get that
> patch.
> You could also try to use the gcc sources from the gcc package
> (apt-get source gcc), but those sources are already patched for gdc
> support, so the ./update-gcc.sh script could fail.

Just a small update in this - I did as you suggested and went over the harass the folks at the Raspbian forum. It turns out that there's actually an ancient version available as a package, but it's gdc-4.4 and doesn't even support D2, so that doesn't help me any at the moment. Will still to try and get the nitty-gritty details on their patching strategy - it looked like their patches were in fact in the sources package as well.