Subject: Compiling egcs... help.

From: [email-masked] (James J. Farmer)
Date: Sat, 21 Nov 1998 14:55:56 GMT

I do hate to trouble you people with little problems like this, but I'm afraid
I'm got myself just a little bit stuck and I was hoping somebody might be
able to give me a nudge in the right direction.

I've been trying to compile egcs, following the instructions on Philip
Blundell's webpage.  I compiled and installed binutils as instructed for the
"arm-linux" target, then tried to compile the first bits of gcc by going
into the "gcc" directory and typing 'make LANGUAGES="c"'.  No problems
and all is well...  then I type 'make install' and after the computer does
lots and lots of stuff, it gives an error message:

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

Now, in my (extremely limited) knowledge of these things, I understand
this is due to a memory mapping limitation of the aout binary format...  I
checked the FAQ and it says that to cure this you should use ELF.

However, surely I'd need to be able to compile egcs before I could use ELF,
so egcs not compiling without ELF would seem a catch-22 situation?
Obviously this can't be right, so I get the feeling that I'm doing something
really really dumb...  but I'm not all that clued-in on Linux so I can't
imagine what it might be.  Does anyone have any thoughts?

And if it's something _really_ silly, I apologise in advance for wasting
your time.

James.
 
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Chris Sawer <[email-masked]>
Date: Sun, 22 Nov 1998 18:11:18 +0000

In message <[email-masked]>
          [email-masked] (James J. Farmer) wrote:

<snip>

> Now, in my (extremely limited) knowledge of these things, I understand this
> is due to a memory mapping limitation of the aout binary format...  I
> Obviously this can't be right, so I get the feeling that I'm doing
> something really really dumb...  but I'm not all that clued-in on Linux so
> I can't imagine what it might be.  Does anyone have any thoughts?

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:

<Start quote>

Seems you've not linked ld itself statically. I hope you've still got the 
source tree with the compiled binutils ready on your HD, if not, you have 
to compile everything again. Let the binutils compile up to the end, and 
remove ld/ld.new (I think that's the name, seek for an  executable that's 
named something similar). Type make again and when 'make' enters the 
ld-subdir and writes the command line used to link ld together, hit 
<CRTL>C (yes, stop the process), go into subdir ld, copy the commandline 
that make wrote earlier on the screen into a new bash prompt and add 
-static or -Wl,-Bstatic before hitting return. The new executable should 
be significantly larger than the old one. The last check is 'ldd 
./ld.new' which should return 'statically linked'. If that's OK, install 
it. If not, consult gcc's man page for a flag that forces it to produce 
statically linked binaries.

The problem is that if the linker ld depends on any shared library, it 
will be loaded at runtime and reduce the memory available to the binary 
due to it's existance in memory (the kernel/library refuses to get it 
overwritten by  the programs data, that's why ld won't get more than 12MB 
of mem if it's not statically linked).

<End quote>

Hope this helps,

Chris

-- 
         Chris Sawer - Worthing, Sussex, England    ICQ: 15010147
    E-Mail: [email-masked]    PGP public key available on request
http://members.xoom.com/chrissawer/  <-- ArmLinux Binaries, Hints and Tips
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Sun, 22 Nov 1998 22:09:02 +0100

>checked the FAQ and it says that to cure this you should use ELF.

A statically linked a.out binary of ld will work as well.  Can someone provide 
either this or an ELF one that will work on the RiscPC?

p.