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?

Thanks,

MEF

--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 2008-05-21 at 10:30 +0100, 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?

Wild guess: Very likely, the package you are trying to build is shipping
a very outdated "config.guess" and/or which doesn't recognize the
triplet (Read: Outdated upstream sources)

Either replace (patch) the versions of config.guess/config.sub inside of
the tarball with more recent ones, or (better) convince upstream to
update their config.guess/config.sub.

Ralf




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Mary Ellen Foster wrote, at 05/21/2008 06:30 PM +9:00:

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?


Similar exaple:
https://bugzilla.redhat.com/show_bug.cgi?id=434906#c19
https://bugzilla.redhat.com/show_bug.cgi?id=434906#c20

This is because redhat-rpm-config dehavior changed on F-10:
* Wed May 07 2008 Jon Masters <jcm@redhat.com> - 9.0.3-1
- Remove overwritten config.guess|sub files (testing).

This affects %configure macro. On F-8/9 %configure replaces
config.{sub,guess} in the tarball with /usr/lib/rpm/config.{sub,guess}
while on F-10 it does not.

Regards,
Mamoru

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 2008-05-21 at 10:40 +0100, Paul Howarth wrote:
> 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:

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

The culprit is upstreams shipping outdated config.guess/config.sub's.

AFAICT, until recently, rpmbuild replaced config.guess/config.sub during
builts, and now has been changed to use the original files upstreams
ship.

Ralf


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Ralf Corsepius wrote:

On Wed, 2008-05-21 at 10:30 +0100, 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?


Wild guess: Very likely, the package you are trying to build is shipping
a very outdated "config.guess" and/or which doesn't recognize the
triplet (Read: Outdated upstream sources)

Either replace (patch) the versions of config.guess/config.sub inside of
the tarball with more recent ones, or (better) convince upstream to
update their config.guess/config.sub.


Ah, I see. I guess I'll have to do it myself then since there is no
active upstream for my compat-type package.


Paul.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Ralf Corsepius wrote:

On Wed, 2008-05-21 at 10:40 +0100, Paul Howarth wrote:

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:



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:


The culprit is upstreams shipping outdated config.guess/config.sub's.

AFAICT, until recently, rpmbuild replaced config.guess/config.sub during
builts, and now has been changed to use the original files upstreams
ship.


Thanks for the info. I see the history behind this in
http://bugzilla.redhat.com/211069 and understand why it was done. It's
easily enough fixed for ppc64 in my (ancient) package, though I suspect
I'm going to need to fix it again for the various secondary
architectures at some point.


Paul.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

2008/5/21 Paul Howarth <paul@city-fan.org>:
> Thanks for the info. I see the history behind this in
> http://bugzilla.redhat.com/211069 and understand why it was done. It's
> easily enough fixed for ppc64 in my (ancient) package, though I suspect I'm
> going to need to fix it again for the various secondary architectures at
> some point.

Thankfully, the issue has already (!!!) been fixed upstream for the
package I was concerned about --
http://gollem.science.uva.nl/bugzilla/show_bug.cgi?id=357
I wonder how many other packages will be bitten by this change in
rpmbuild; I guess that's the point of Rawhide, though.

MEF

--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list