#acl PaulHowarth:read,write,admin,revert,delete All:read

=== Wednesday 21st May 2008 ===

==== Fedora Project ====

Having a few spare minutes on my hands, I decided to fix some of the compiler warnings generated
during the build of the old `libxml` package, particularly the ''implicit function declaration''
ones, which may result in the benefits of `FORTIFY_SOURCE` being lost. There is talk of adding
`-Werror-implicit-function-declaration` to the default compiler flags at some point, at which point
this sort of fix will become necessary rather than just desirable.

Having created the necessary patch and done local `mock` builds for Rawhide (i386 and x86_64),
I committed the changes into CVS and requested a build. To my surprise, the build on the ppc64
architecture failed.  Suspecting some subtle problem with my patch, I tried a scratch build
of the un-patched package and that failed in the same way:
{{{
gcc -shared  SAX.lo entities.lo encoding.lo error.lo parser.lo parserold.lo HTMLparser.lo HTMLtree.lo debugXML.lo tree.lo xpath.lo xmlIO.lo xmlmemory.lo nanohttp.lo nanoftp.lo valid.lo xlink.lo uri.lo -Wl,-soname -Wl, -o .libs/
/usr/bin/ld: cannot open output file .libs/
: Is a directory
collect2: ld returned 1 exit status
}}}
Comparing the build logs with the successful ppc build showed that `libtool` was a problem since it didn't
recognize the host type:
{{{
checking host system type... Invalid configuration `ppc64-redhat-linux-gnu': machine `ppc64-redhat' not recognized
checking build system type... Invalid configuration `ppc64-redhat-linux-gnu': machine `ppc64-redhat' not recognized
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
... (snip) ...
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... no
checking if libtool supports shared libraries... no
}}}
A [[http://www.redhat.com/archives/fedora-devel-list/2008-May/msg01577.html|thread on fedora-devel-list]]
revealed that this problem was caused by a recent change in the `redhat-rpm-config` package in Rawhide to
address [[RedHatBugzilla:211069|Bug #211069]], whereby the traditional behaviour of the `%configure` macro
of overwriting a package's own `config.sub` and `config.guess` scripts with the ones from `redhat-rpm-config`
was ceased since it caused issues for cross-compilation. So now `libxml` was being built with its own
versions of `config.sub` and `config.guess`, which date back to early 2002 and have never heard of the ppc64
architecture.

The fix wasn't difficult really:
{{{
--- libxml-1.8.17/config.guess	2002-01-23 22:49:14.000000000 +0000
+++ libxml-1.8.17/config.guess	2008-05-21 10:53:14.000000000 +0100
@@ -811,6 +811,9 @@
 	rm -f $dummy.c $dummy
 	echo powerpc-unknown-linux-gnu${LIBC}
 	exit 0 ;;
+    ppc64:Linux:*:*)
+	echo powerpc64-unknown-linux-gnu
+	exit ;;
     alpha:Linux:*:*)
 	cat <<EOF >$dummy.s
 	  .data
--- libxml-1.8.17/config.sub	2002-01-23 22:49:14.000000000 +0000
+++ libxml-1.8.17/config.sub	2008-05-21 11:25:57.000000000 +0100
@@ -721,6 +721,10 @@
 	        ;;
 	ppc-*)	basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'`
 		;;
+	ppc64)  basic_machine=powerpc64-unknown
+		;;
+	ppc64-*) basic_machine=powerpc64-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
 	ppcle | powerpclittle | ppc-le | powerpc-little)
 		basic_machine=powerpcle-unknown
 	        ;;
}}}
And with that patch, `libxml` built happily in Rawhide once again.
It's possible I'll have to revisit this at some point to cater for secondary
architectures like sparc and ia64; we'll see.
----