linux-mips-fnet
[Top] [All Lists]

Re[2]: Big Endian Linux/MIPS kernel linking problem

To: linux-mips@fnet.fr
Subject: Re[2]: Big Endian Linux/MIPS kernel linking problem
From: BHOUGH@mailgw.sanders.lockheed.com
Date: Thu, 21 Dec 1995 09:49:44 -0500
          

> 
>                I downloaded the latest binaries off the FTP site.  
>           Thanks again to all involved - you know who you are  8-)
>           
>                On to the next problem.
>           
>                Here's a strange one...
>           
>                Mike and I are trying to compile the kernel before the 
>           Christmas break here.  So I tried it yesterday and got some 
>           linking errors.  Here's a sample:
>           
>      mips-linuxelf-ld  -r -o kernel.o ksyms.o sched.o dma.o fork.o 
exec_domain.
o 
>      panic.o printk.o sys.o module.o exit.o signal.o itimer.o info.o time.o 
>      softirq.o resource.o
>      signal.o(.text+0x3f4): relocation truncated to fit: R_MIPS_GOT16 .text
>      signal.o(.text+0x62c): relocation truncated to fit: R_MIPS_GOT16 .text
>      itimer.o(.text+0x1e8): relocation truncated to fit: R_MIPS_GOT16 .text
>      itimer.o(.text+0x208): relocation truncated to fit: R_MIPS_GOT16 .text
>      itimer.o(.text+0x274): relocation truncated to fit: R_MIPS_GOT16 .text
>      itimer.o(.text+0x3bc): relocation truncated to fit: R_MIPS_GOT16 .text
>      itimer.o(.text+0x3dc): relocation truncated to fit: R_MIPS_GOT16 .text
>      itimer.o(.text+0x404): relocation truncated to fit: R_MIPS_GOT16 .text
>      itimer.o(.text+0x634): relocation truncated to fit: R_MIPS_GOT16 .text
>      resource.o(.text+0x230): relocation truncated to fit: R_MIPS_GOT16 .text
>      resource.o(.text+0x300): relocation truncated to fit: R_MIPS_GOT16 .text
>      resource.o(.text+0x3c4): relocation truncated to fit: R_MIPS_GOT16 .text
>      resource.o(.text+0x44c): relocation truncated to fit: R_MIPS_GOT16 .text
>      make[1]: *** [kernel.o] Error 1
>      make[1]: Leaving directory `/usr/local/src/linux-1.3.39/kernel'
>      make: *** [linuxsubdirs] Error 2
>           
>                Any ideas anyone?   We're expecting a storm tonight and 
>           tomorrow, so we might not be in 'till Thursday - lots of 
>           snow!
>           
>                Anyhow, is it something to do with environment 
>           variables configuring the 'ld' tool with object file types?  
>           I've been reading the GNU manual on ld, but haven't found 
>           anything definite yet.  Could it be the segment page size is 
>           wrong? 

This is a liker bug.  GNU ld can't handle PIC and all the stuff involved.
Add -mno-abicalls -fno-pic -G0 to the options to build the kernel with the
ELF compiler.

The options -mabicalls -fpic are required for user code to be used for
shared libraries or with shared libraries, that's why they are on by
default.  To make it unnecessary to add these option for every compile
I've disabled them in my GCC 2.7.2 patch.  You can reenable them by
adding -DWITH_SHARED_LIBS to CFLAGS while compiling GCC.

Adding the missing PIC & DSO support to GNU ld is nontrivial; someone
in Japan is currently working on it.  I'll add his stuff to my binutils
patches as soon as I've tested them successfully.  Since the MIPS ELF
stuff in binutils is very reliable otherwise I think it's better not to
add something that hasn't yet production quality.

For a kernel all this is pretty uninteresting; we don't need PIC code
for the kernel.  Non-pic code even performs better.

   Ralf

          Thanks once again Ralf.  Worked like a charm.  We ran into a small 
snag after that - undefined symbols in minix.o (I decided to try the minix fs 
first) under /fs/minix.  These were references to memcpy, which are redefned 
calls to memcpy_tofs and memcpy_fromfs in the files file.c and inode.c 
          The fix for this was a "#include <asm/string.h>" statement after the 
asm/system.h and asm/segment includes.
          Next step is to link in the serial port driver in our Star II's prom 
monitor to the console output routine in printk.c and try a 'smoke test'.  
Hopefully we'll get to do it today or tomorrow, if not we'll get back to you in 
Jan. with the results (no work here from 23rd to 1st).

                                                            Brannen

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