Subject: Re: Compiling egcs... help.

From: [email-masked] (James J. Farmer)
Date: Mon, 23 Nov 1998 22:05:49 GMT

In a message sent at Sun, 22 Nov 1998 18:11:18 +0000,
     Chris Sawer ([email-masked]) said:

> Indeed - there is (luckily) another way to get this to work and that is to
> compile ld statically. (BTW, you need to do the same with "ar"). Stefan
> Hanske <[email-masked]> explained this to me a while ago:

 [snip]

> Hope this helps,

Thanks!  That all sounds rather possible...  however, I have hit another
problem.  I deleted my binutils source tree yesterday when I ran out of
disc space (despite having installed next to nothing in my 700Mb!).  Anyway,
"no problem", I thought, "I'll just download it again and re-build it."  And
so I downloaded Binutils 2.9.1.0.15 along with the appropriate patch, just
like I did before, applied the patch, ran the configure file, typed "make"...
and all went seemingly to plan until it started to compile the stuff in
the "binutils" directory, when this happened...

  make[1]: Entering directory `/root/binutils-2.9.1.0.15/binutils'
  /bin/sh ./libtool --mode=link gcc -g -O2  -o size  size.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a 
  gcc -g -O2 -o size size.o bucomm.o version.o filemode.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a
  ../bfd/.libs/libbfd.a: could not read symbols: Archive has no index; run ranlib to add one
  make[1]: *** [size] Error 1
  make[1]: Leaving directory `/root/binutils-2.9.1.0.15/binutils'
  make: *** [all-binutils] Error 2

Oo-er - it worked before!  Anyway, I've tried running ranlib on the offending
file about twenty zillion times but it never stops me from getting this
same error...  I've tried using the targets "arm-linux" and "arm-linuxaout"
but no joy.  And I'm afraid that once again I've exceeded my knowledge of
Linux...  my best guess is that something that was installed when I last
built binutils is for some reason not working with binutils itself, which
seems a touch daft but it was the only thing I could think of.  The only
other changes to my system since my last successful build are that I've
installed Chimera, Afterstep and Freeciv, none of which I can in a month
of Sundays imagine causing problems like this.

I hate to off-load my problems onto you people, but...  I'm stuck.  I'm
very very stuck.  I'm very very stuck indeed.

All suggestions gratefully received...

James.
--
*****************************************************************************
*                                Doctor Who:                                *
*                          The Internet Adventures                          *
*                 http://www.users.zetnet.co.uk/jjf/drwho/ia/               *
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: "Adam 'WeirdArms' Wiggins" <[email-masked]>
Date: Tue, 24 Nov 1998 19:03:59 +1100 (EST)

>   make: *** [all-binutils] Error 2
	I got this problem every now and then but running ranlib on the
file fixed it. You using the right ranlib?

	Cheers Adam

---

From: Hwa Jin Bae <[email-masked]>
Date: Tue, 24 Nov 1998 09:36:33 -0800

I've seen an error like this building another GNU package lately.
Try running make with RANLIB specified, e.g. " make
RANLIB=arm-linux-ranlib" or something like that.  That seemed to fix the
problem, but it depends on various configuration scripts using RANLIB
instead of hard coding ranlib name.

Good luck!

-- 
Hwa Jin Bae
PSO Systems Inc
mailto:[email-masked]
http://www.pso.com

---

From: [email-masked] (James J. Farmer)
Date: Wed, 25 Nov 1998 22:44:31 GMT

In a message sent at Tue, 24 Nov 1998 09:36:33 -0800,

> instead of hard coding ranlib name.

Thanks...  I tried "make RANLIB=/usr/arm-linux/bin/ranlib" and I saw that
file referenced several times in the compiler output so I guess it gets
used...  unfortunately, it didn't fix the problem.  But thanks for trying
anyway.

I then tried using the ranlib in /usr/arm-unknown-linuxaout/bin/ranlib on
the offending library...  still no joy.  All the versions of ranlib I have
seem to update the datestamp on the file so presumably they do something,
but what is obviously not enough to appease the compiler.

*sigh*  All I want for Christmas is my two front teeth and a version of
Linux in which everything compiles first time with no problems.  ;)

James Farmer.
--
*****************************************************************************
* "He is shedding buckets of         * "With half the race gone, there is   *
*   adrenalin in that car."          *   half the race still to go."        *
*                    - Murray Walker *                      - Murray Walker *
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Fri, 27 Nov 1998 20:33:40 +0100

>but what is obviously not enough to appease the compiler.

You have to use the right version of ranlib for the compiler in question.  I 
forget exactly what it is you're trying to do, but basically:

/usr/arm-*-linux/bin/* are your Linux/ARM ELF tools
/usr/arm-*-linuxaout/bin/* are your Linux/ARM a.out tools
/usr/bin/* are the "native" tools for whatever system you're using

If everything is installed correctly and you configured with the right 
--prefix, --build, --host and CC settings, the right versions of the other 
tools should get picked up automatically.  If this isn't happening then you 
probably need to try to figure out why rather than battling on by setting 
RANLIB manually.

p.

---

From: [email-masked] (James J. Farmer)
Date: Sat, 28 Nov 1998 10:07:18 GMT

In a message sent at Fri, 27 Nov 1998 20:33:40 +0100,

> /usr/bin/* are the "native" tools for whatever system you're using

*nod*  I basically tried all the different versions of Ranlib I could find
because I was getting desparate.

> probably need to try to figure out why rather than battling on by setting 

That sounds sensible...  however, I've tried every version of ranlib I can
find and none of them work, so I'm not sure it's the problem...

What I'm actually trying to do is compile EGCS on and for Arm Linux
installed on a StrongARM Risc PC so I can use ELF.  I patched Binutils
and did the following:

  ./configure arm-linux --prefix=/usr
  make
  make install

And all was well.  Then I tried to compile EGCS as per the instructions on
your webpage, and it gave me the error:

  /usr/arm-unknown-linuxaout/bin/ld: final link failed: Memory exhausted

Chris Sawer very helpfully suggested that I needed to link ld statically,
and detailed a way I could create a workable version of ld (and ar) using
binutils - but unfortunately I'd deleted the binutils source tree and so
I'd have to download it and recompile it.  This is where things started
to go wrong...  I downloaded the tree and patched it, then did

  ./configure arm-linux --prefix=/usr

And all seemed well.  But then when I tried "make", I was left looking at
(several pages of error-free output deleted):

And no matter how many times I run ranlib (any version of ranlib I can find)
on that 'libbfd.a' file, it makes not a blind bit of difference.

I'm not too sure why I'm reiterating all this, actually.  Ah well,

James.

---

From: Philip Blundell <[email-masked]>
Date: Sun, 29 Nov 1998 11:58:09 +0100

>  ./configure arm-linux --prefix=/usr

Installing that binutils will have overwritten your a.out tools in /usr/bin 
with the ELF versions, but your compiler and all your libraries will still 
be a.out.  This isn't disaster for gcc because it looks in the more specific 
directories first but anything else looking for tools is liable to get the 
wrong ones.

>  ../bfd/.libs/libbfd.a: could not read symbols: Archive has no index; run ran

I suspect what happened is that libtool picked up the ELF version of ar rather 
than the a.out one that you still need at this stage.  Look through the `make' 
output and check if this is the case; if it is, you may need to hack 
config.make or something to make it use the right one.

If you're still stuck then I guess you need to look at the offending library 
and see if you can work out what's wrong with it (things like "is it zero 
length" would be a good starting point...)

p.