Hi Jate,
Jate Sujjavanich wrote:
On Daniel Jacobowitz's suggestion, I tried the Code Sourcery GNU
toolchain for Coldfire version 4.2 lite edition located at:
http://www.codesourcery.com/gnu_toolchains/coldfire
After fixing several bugs (due to incompatibilities with the newer
toolchain), I was able to startup uClinux with shared libraries.
What did you have to change?
Anything not fixed in the latest uClinux-dist patches?
When I tried the only thing that struck me as odd (and that I
had to fix) was the location of the compilers limits.h file.
On all the other cross toolchains I have generated (not just
for m68knommu, but arm, sh, etc) the gcc limits.h got installed
into the directory which is returned from:
m68k-uclinux-gcc -print-file-name=include.
But in the Code Sourcery 4.2 kit it can only be found in
`m68k-uclinux-gcc -print-file-name=include`/../include-fixed.
So I just copied that one, into the normal include diretcory.
Everything built fine after that.
Daniel, are you out there, any idea why this is?
Regards
Greg
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David McCullough
Sent: Monday, July 30, 2007 8:55 PM
To: uClinux development list
Subject: Re: [uClinux-dev] Shared library issues on m68knommu and gcc
4.1.1
Jivin [EMAIL PROTECTED] lays it down ...
I am getting the "lib 0 younger than lib 1" in the relocation code
for the reloc table for uClibc (shared lib 1). The code works until
it reaches a value of "0x00000001" which is interpreted as address 1
in library 0. Library 0 is younger than 1, as it should be.
I understand now.
Some of my theories are as follows. Maybe the linker is inserting a
0x00000001 into the reloc table when it shouldn't be. Or maybe it
should be, and 0x00000001 is a new flag in the newer toolchain.
It certainly has the feel of a tool chain flag. I have a vague
recollection of such being used in the constructor/destructor chains.
What if you modify the kernel relocator to stop on these values? (are
there legitimate relocations *after* them?)
Or skip them?
Does the program then work?
I don't see how 0x00000001 can be a legitimate relocation address.
Code is word aligned and that definitely points into code space. I
don't remember relocations less than 32 bit being needed on the
ColdFire.
Could be the constructore or destructor count, there is usually only
one in a normal app.
Check that you elf2flt.ld has the correct CTORS/DTORS constructs and
that there is not padding getting inserted between symbols etc.
Let me know if this rings any bells.
It doesn't :-(
There were some weird zero values near the start of the GOT that I
never figured out but I thought I'd dealt with the relocations properly.
Cheers,
Davidm
--
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
