Hi,
Thanks ans sorry for a late reply..
Here are the differents between b128 and b145.
# b128:
ldd libapr-0.so.0.9.17
libsendfile.so.1 => /lib/libsendfile.so.1
librt.so.1 => /lib/librt.so.1
libm.so.2 => /lib/libm.so.2
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libresolv.so.2 => /lib/libresolv.so.2
libpthread.so.1 => /lib/libpthread.so.1
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1
libsmbios.so.1 => /usr/lib/libsmbios.so.1
# b145:
ldd libapr-0.so.0.9.17
./libapr-0.so.0.9.17: unknown capability: 0 libsendfile.so.1 =>
/lib/libsendfile.so.1
librt.so.1 => /lib/librt.so.1
libm.so.2 => /lib/libm.so.2
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libresolv.so.2 => /lib/libresolv.so.2
libpthread.so.1 => /lib/libpthread.so.1
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
So there are missing /lib/libscf.so.1 /lib/libuutil.so.1
/lib/libgen.so.1 /usr/lib/libsmbios.so.1 libraries.
I will try to figure out which build introduced a regression.
On Tue, Oct 12, 2010 at 6:00 PM, Rod Evans <[email protected]> wrote:
> On 10/12/10 2:03 AM, Piotr Jasiukajtis wrote:
>
>> elfdump -H libapr-0.so.0 says nothing:
>>
>> # elfdump -H ./libapr-0.so.0 ; echo $?
>> 0
>
> It's a rather unhappy object. elfdump(1) reveals lots of errors
> in regards inconsistent symbol tables, and an inconsistent .dynamic
> section:
>
> % elfdump -d libapr\-0.so.0.9.17
>
> Dynamic Section: .dynamic
> index tag value
> [0] NEEDED 0x2847 libsendfile.so.1
> ....
> [14] CHECKSUM 0x4d35
> libapr-0.so.0.9.17: object lacks [ SHT_SUNW_verneed ] section required by
> DT_VERNEED dynamic entry
> [15] VERNEED 0x64f0
> [16] VERNEEDNUM 0x8
> ....
> [23] FEATURE_1 0x1 [ PARINIT ]
> libapr-0.so.0.9.17: object lacks [ SHT_SUNW_cap ] section required by
> DT_SUNW_CAP dynamic entry
> [24] SUNW_CAP 0xb4
> ....
> [28] NULL 0
>
> Here, the .dynamic section has recorded the existence of a capabilities
> section (SUNW_cap), but there's no .SUNW_cap section in the section header
> table. Normally you'd find something like this:
>
> Section Header[1]: sh_name: .SUNW_cap
> sh_addr: 0xb4 sh_flags: [ SHF_ALLOC ]
> sh_size: 0x10 sh_type: [ SHT_SUNW_cap ]
> sh_offset: 0xb4 sh_entsize: 0x8
> sh_link: 0 sh_info: 0
> sh_addralign: 0x4
>
> Hmm, but perhaps there was a capabilities entry at one point? There's
> a program header that suggests such:
>
> Program Header[0]:
> p_vaddr: 0 p_flags: [ PF_R ]
> p_paddr: 0 p_type: [ PT_SUNWCAP ]
> p_filesz: 0 p_memsz: 0
> p_offset: 0 p_align: 0x4
>
> And the first section of the file is:
>
> Section Header[1]: sh_name: .hash
> sh_addr: 0xc4 sh_flags: [ SHF_ALLOC ]
> sh_size: 0x13bc sh_type: [ SHT_HASH ]
> sh_offset: 0xc4 sh_entsize: 0x4 (1263 entries)
> sh_link: 2 sh_info: 0
> sh_addralign: 0x4
>
> Which suggests something might have existed at 0xb4:
>
> % od -x libapr\-0.so.0.9.17 +0xd4 | head
> 00000d4 0003 0000 0004 0000 0007 0000 0000 0000
>
> The reason ld.so.1 (and hence ldd) is complaining is because the
> PT_SUNWCAP indicates the capabilities exist at 0x0, the base address
> of the loaded object. Hence ld.so.1/ldd are looking at the ELF
> header and trying to determine capabilities. A "fixed" ld.so.1/ldd
> would reveal:
>
> ./libapr-0.so.0.9.17: unknown capability: 0x464c457f
>
>
> mcs(1) can sometimes tell you who built the object, but all I see is:
>
> acomp: Sun C 5.8 Patch 121016-02 2006/03/31
> as: Sun Compiler Common 11 Patch 120759-08 2006/08/08
>
> I don't see any record from ld(1). You'd normally see something like:
>
> acomp: Sun C 5.9 SunOS_sparc Patch 124867-11 2009/04/30
> ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.477
>
>
> So, I don't know if you had a broken ld(1) build this file, a different
> link-editor build it, or someone has been doctoring the file after it
> was built.
>
> BTW, we filed and have a fix in the works for
>
> 6990845 unknown capabilities tags are poorly diagnosed
>
> which corrects the poor "unknown capability: 0" diagnostic are seeing.
>
> But, I can't explain how the object was constructed, so if you have any
> clues of the original compilation environment this came from, we might
> be able to determine what's gone wrong.
>
> --
> Rod
>
--
Piotr Jasiukajtis | estibi | SCA OS0072
http://estseg.blogspot.com
_______________________________________________
tools-linking mailing list
[email protected]
