[uClinux-dev] Shared library issues on m68knommu and gcc 4.1.1

[Greg Ungerer]

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: uclinux-dev-bounces at uclinux.org
> [mailto:uclinux-dev-bounces at uclinux.org] 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 Paul_Dale at au.securecomputing.com 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:     gerg at snapgear.com
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