[uClibc]Re: 32bit PIC m68k-elf, was BINFMT_FLAT bad magic, elf2flt 'input file contains no relocation info' m68k

Brad Clements bkc at murkworks.com
Tue Jan 14 16:29:41 UTC 2003


On 13 Jan 2003 at 23:24, Syed Faisal Akber wrote:

> With the tool-chain you are using ALWAYS use -msep-data, this ensures that
> the "data" section of file is relocatable.
> 
> ONLY use -Wl,-elf2flt at the final link stage, never at any intermediate
> link stage, such as library generation.

> Be sure to check the directory /usr/local/m68k-elf/lib and make sure that
> it is a directory that contains the uclibc libraries and other libraries.
> This is the source of your last problems.

Thanks for the suggestions, I've checked m68k-elf/lib and indeed, it had some "other" 
libs that were not the current uClib versions I am building to match my current kernel.

However, I'm running into offset limit problems, when compiling Python/typeobject.c, 
like this:

gcc -c -DNDEBUG -g -O0 -Wall -Wstrict-prototypes -msep-data -I. -I/usr/local/src/python-cvs/python/dist/src/Include -DPy_BUILD_CORE -o Objects/typeobject.o /usr/local/src/python-cvs/python/dist/src/Objects/typeobject.c


(I disabled optimization as another check)

The assembler phase dies with "value out of range" on statements like this (well into 
the source file, ie: at line 21806 in a 29719 line .s file):

        bsr call_maybe at PLTPC

For some reason the toolchain I'm using seems to be using only 16-bit PIC, but in 
reading the archives I thought that the elf tools had been converted to 32-bit code 
generation some time ago.

I'm not a 68k guru, so I can't be certain if that's what is happening here.

perhaps it is using 32-bit branches and this is out of the 32-bit branch range?

I'm going to try re-arranging the source..

-- 
Brad Clements,                bkc at murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
http://www.wecanstopspam.org/                   AOL-IM: BKClements




More information about the uClibc mailing list