[Top] [All Lists]

Re: Cobalt Qube / Egcs?

To: Greg <>,
Subject: Re: Cobalt Qube / Egcs?
Date: Tue, 17 Nov 1998 10:38:20 +0100
In-reply-to: <>; from Greg on Mon, Nov 16, 1998 at 05:27:02PM -0500
References: <> <>
On Mon, Nov 16, 1998 at 05:27:02PM -0500, Greg wrote:

> make[1]: Leaving directory `/home/redhat/BUILD/binutils-2.8.1/libiberty'
> make[1]: Entering directory `/home/redhat/BUILD/binutils-2.8.1/libiberty'
> make[2]: Entering directory `/home/redhat/BUILD/binutils-2.8.1/libiberty'
> make[2]: Leaving directory `/home/redhat/BUILD/binutils-2.8.1/libiberty'
> /home/redhat/BUILD/binutils-2.8.1/ -c -m 644 libiberty.a
> /tmp/binutils-root/usr/lib/libiberty.a.n
> ( cd /tmp/binutils-root/usr/lib ;
> /home/redhat/BUILD/binutils-2.8.1/binutils/ranlib
> /tmp/binutils-root/usr/lib/libiberty.a.n )
> /home/redhat/BUILD/binutils-2.8.1/binutils/ranlib: error in loading shared
> libraries
> /usr/lib/ undefined symbol: __ucmpdi2

This means that the old apparently has been linked against a
dynamic libgcc, a corrupt libgcc or maybe not linked against libgcc at
all.  If you're still using Cobalt's development tools - this might also
be the result of a modification - not bug - of their development environment.
In any case that report is the first of it's kind.

Which compiler did you use?  Did you upgrade it?  Since the kernel of the
Qube is 2.0 based it's a bad idea to use the unmodified srpm from

Actually the binutils' installation command sequence is buggy as well,
they should use LD_LIBRARY_PATH but don't if I haven't missed anything ...

Could you run

  objdump --private-headers /usr/bin/ranlib
  objdump --private-headers /usr/lib/

and send me the output?


<Prev in Thread] Current Thread [Next in Thread>