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.
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. I used objdump to look at the .rela.data section. The first entries to strings made sense as additions of the data address, got length, offset and addend. The next values in the reloc table do not match this pattern. Let me know if this rings any bells. - Jate S. -----Original Message----- From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] Sent: Sun 7/29/2007 6:23 PM To: uClinux development list Subject: Re: [uClinux-dev] Shared library issues on m68knommu and gcc 4.1.1 I missed your initial message. I did the m68k shared library work so I ought to understand this, although it was quite a few years ago now and memory fades... > My earlier understanding was incorrect. The problem (so far) is not in > the GOT. It is definitely in the relocation table. [...] > I feel like I'm driving with no map. Am I totally incorrect? I think so, at least what you've said seemed to make sense and matches what I remember. This stuff is very rusty to me, we've not used ColdFire parts for a number of years :-( Actually, lots of years. > Is this the right list to be talking to? I should think so. > Does anyone with experience (snapgear guys) have any recommendations? My method for debugging these problems involved hex dumps of the compiler generated code (objdump -D is good) and a hex calculator to link everything together. The "library is younger" message comes from a date check between the flat headers of the executable and libc. Try flthdr -p to see what values are really present in the two executables. This check doesn't have anything to do with relocations so if something is going awry mid way through, I'd be suspecting memory corruption. Regards, Pauli -- Dr Paul Dale Software Grunt Secure Computing(r) your trusted source for enterprise security(tm) www.securecomputing.com <http://www.securecomputing.com/> _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************
<<winmail.dat>>
_______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
