[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