PaulHowarth/Blog/2008-05-21

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 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 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.

Recent