Did the "uname" change on ppc64 in Rawhide?

[Paul Howarth]

Mary Ellen Foster wrote:
> I'm trying to figure out why a package that built for F8 and F9 failed
> on Rawhide. Here are the logs for the failed Rawhide bid:
> 
>     http://koji.fedoraproject.org/koji/taskinfo?taskID=622220
> 
> In this build, "configure" dies with:
>     checking build system type...
>     Invalid configuration `ppc64-redhat-linux-gnu': machine
> `ppc64-redhat' not recognized
>     configure: error: /bin/sh ./config.sub ppc64-redhat-linux-gnu failed
> 
> Whereas on F8 and F9 on PPC64, building the identical SRPM works fine
> (http://koji.fedoraproject.org/koji/taskinfo?taskID=622181 and
> http://koji.fedoraproject.org/koji/taskinfo?taskID=622176) and the
> corresponding output from "configure" in both cases is:
>     checking build system type...
>     powerpc64-redhat-linux-gnu
>     [ ... continue configuring ... ]
> 
> Any suggestions what's going on here?

Dunno, but I came across this yesterday too. A package that built 
everywhere apart from ppc64 (and had built previously on F9) failed on 
ppc64:

http://koji.fedoraproject.org/koji/taskinfo?taskID=620258

The configure script doesn't bomb out entirely but it decides that its 
libtool doesn't know how to build shared libraries...:

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


And that then leads to the eventual failure:

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

which should have been:

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,libxml.so.1 -o .libs/libxml.so.1.8.17


Paul.