Guile Fails when building beagleboard-demo-image (SOLUTION)

When building the beagleboard-demo-image using bitbake it always
failed on the guile-native package with the following error:

NOTE: make
make all-recursive
make[1]: Entering directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5'
Making all in oop
make[2]: Entering directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5/oop'
Making all in goops
make[3]: Entering directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5/oop/goops'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5/oop/goops'
make[3]: Entering directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5/oop'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5/oop'
make[2]: Leaving directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5/oop'
Making all in libguile
make[2]: Entering directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5/libguile'
make all-am
make[3]: Entering directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5/libguile'
/bin/sh ../i686-linux-libtool --tag=CC --mode=compile ccache gcc -
DHAVE_CONFIG_H -I.. -I.. -I.. -isystem/home/jeremy/oe/tmp/staging/
i686-linux/usr/include -isystem/home/jeremy/oe/tmp/staging/i686-linux/
usr/include -pthread -isystem/home/jeremy/oe/tmp/staging/i686-linux/
usr/include -O2 -Wall -Wmissing-prototypes -Werror -MT libguile_la-
async.lo -MD -MP -MF .deps/libguile_la-async.Tpo -c -o libguile_la-
async.lo `test -f 'async.c' || echo './'`async.c
i686-linux-libtool: compile: ccache gcc -DHAVE_CONFIG_H -I.. -I.. -
I.. -isystem/home/jeremy/oe/tmp/staging/i686-linux/usr/include -
isystem/home/jeremy/oe/tmp/staging/i686-linux/usr/include -pthread -
isystem/home/jeremy/oe/tmp/staging/i686-linux/usr/include -O2 -Wall -
Wmissing-prototypes -Werror -MT libguile_la-async.lo -MD -MP -MF .deps/
libguile_la-async.Tpo -c async.c -fPIC -DPIC -o .libs/libguile_la-
async.o
cc1: warnings being treated as errors
async.c: In function 'scm_i_queue_async_cell':
async.c:250: error: ignoring return value of 'write', declared with
attribute warn_unused_result
make[3]: *** [libguile_la-async.lo] Error 1
make[3]: Leaving directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5/libguile'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jeremy/oe/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5'
make: *** [all] Error 2
FATAL: oe_runmake failed

After searching around for awhile, and reading the output several
times, I found that the problem is that this error is actually a
warning being treated like a fatal error due to the -Werror flag being
used to compile it.

To fix this you can either fix the code causing the warning (async.c:
250) or remove the -Werror flag from the Makefile. Either case,
you'll find the files in $OE_HOME/tmp/work/i686-linux/guile-
native-1.8.5-r0/guile-1.8.5/ (this might be slightly different for
you)

I modified a few Makefiles under that directory:
* Makefile
* oop/Makefile
* oop/goops/Makefile

You probably only have to modify the 3rd one, but I was trying to be
thorough. Simply open the file and remove "-Werror" from it. Now go
back and run the bitbake command again WITHOUT running a clean first.
Good luck.

It would also be good to go back and read this page, if you haven't
already:
http://wiki.openembedded.net/index.php/Getting_Started

If you're feeling ambitious, it looks like the offending file has been
fixed and you could try to patch it manually:
http://www.mail-archive.com/bug-guile@gnu.org/msg04646.html

I hit one other issue while doing a clean compile of the Angstrom distribution. This one in libxml2 - a undefined reference for gzopen64. This requires a simple patch to libxml.h, at least that is how i resolved it. If any body else has encountered the same issue i can post the patch.