prelink issue with ppc64?

prelink issue with ppc64?

[Kumar Gala]

If prelink gets a chance to properly run I get a rootfs that does:

/sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference

if 'baselib' is set to /lib we get:

/local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker

if 'baselib' is set to /lib64 we get:

Assigned virtual address space slots for libraries:
/lib64/ld64.so.1                                             00000080f4910000-00000080f49473d0
/lib64/libc.so.6                                             00000080f4950000-00000080f4afe090
/lib64/libdl.so.2                                            00000080f4b10000-00000080f4b23520
/lib64/libcrypt.so.1                                         00000080f4b10000-00000080f4b57708
/lib64/libutil.so.1                                          00000080f4b10000-00000080f4b234a0
Would prelink /lib64/ld-2.13.so
Would prelink /lib64/libc-2.13.so

Not sure what prelink is doing but it seems to breaking things.  Any ideas?

---

I'm also concerned that we use /etc/prelink.conf when invoking prelink.

- k

Re: prelink issue with ppc64?

[Mark Hatle]

On 8/3/11 12:35 AM, Kumar Gala wrote:
> If prelink gets a chance to properly run I get a rootfs that does:
> 
> /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference
> 
> if 'baselib' is set to /lib we get:
> 
> /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker
> 
> if 'baselib' is set to /lib64 we get:
> 
> Assigned virtual address space slots for libraries:
> /lib64/ld64.so.1                                             00000080f4910000-00000080f49473d0
> /lib64/libc.so.6                                             00000080f4950000-00000080f4afe090
> /lib64/libdl.so.2                                            00000080f4b10000-00000080f4b23520
> /lib64/libcrypt.so.1                                         00000080f4b10000-00000080f4b57708
> /lib64/libutil.so.1                                          00000080f4b10000-00000080f4b234a0
> Would prelink /lib64/ld-2.13.so
> Would prelink /lib64/libc-2.13.so
> 
> Not sure what prelink is doing but it seems to breaking things.  Any ideas?
> 
> ---
> 
> I'm also concerned that we use /etc/prelink.conf when invoking prelink.

Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is
the one inside of the image -- NOT the system version.

I would suspect that the cross-prelinker rtld emulation is likely setup for the
LSB style library paths and may be causing some of the problems.

I'd suggest simply disabling prelink and getting everything to work first.. once
it does we can work through any prelinker issues.  (Prelink on PPC64 hasn't been
tested within the oe-core environment.. so it could very well have issues beyond
the ld.so path.)

--Mark

> - k
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: prelink issue with ppc64?

[Kumar Gala]

On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote:

> On 8/3/11 12:35 AM, Kumar Gala wrote:
>> If prelink gets a chance to properly run I get a rootfs that does:
>> 
>> /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference
>> 
>> if 'baselib' is set to /lib we get:
>> 
>> /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker
>> 
>> if 'baselib' is set to /lib64 we get:
>> 
>> Assigned virtual address space slots for libraries:
>> /lib64/ld64.so.1                                             00000080f4910000-00000080f49473d0
>> /lib64/libc.so.6                                             00000080f4950000-00000080f4afe090
>> /lib64/libdl.so.2                                            00000080f4b10000-00000080f4b23520
>> /lib64/libcrypt.so.1                                         00000080f4b10000-00000080f4b57708
>> /lib64/libutil.so.1                                          00000080f4b10000-00000080f4b234a0
>> Would prelink /lib64/ld-2.13.so
>> Would prelink /lib64/libc-2.13.so
>> 
>> Not sure what prelink is doing but it seems to breaking things.  Any ideas?
>> 
>> ---
>> 
>> I'm also concerned that we use /etc/prelink.conf when invoking prelink.
> 
> Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is
> the one inside of the image -- NOT the system version.

Is this because of psuedo or something else?

> I would suspect that the cross-prelinker rtld emulation is likely setup for the
> LSB style library paths and may be causing some of the problems.
> 
> I'd suggest simply disabling prelink and getting everything to work first.. once
> it does we can work through any prelinker issues.  (Prelink on PPC64 hasn't been
> tested within the oe-core environment.. so it could very well have issues beyond
> the ld.so path.)

Everything else is working, so prelink is what fails for me (at least for a simple minimal) build.

any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing?  When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not.

- k

Re: prelink issue with ppc64?

[Mark Hatle]

On 8/3/11 9:53 AM, Kumar Gala wrote:
> 
> On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote:
> 
>> On 8/3/11 12:35 AM, Kumar Gala wrote:
>>> If prelink gets a chance to properly run I get a rootfs that does:
>>>
>>> /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference
>>>
>>> if 'baselib' is set to /lib we get:
>>>
>>> /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker
>>>
>>> if 'baselib' is set to /lib64 we get:
>>>
>>> Assigned virtual address space slots for libraries:
>>> /lib64/ld64.so.1                                             00000080f4910000-00000080f49473d0
>>> /lib64/libc.so.6                                             00000080f4950000-00000080f4afe090
>>> /lib64/libdl.so.2                                            00000080f4b10000-00000080f4b23520
>>> /lib64/libcrypt.so.1                                         00000080f4b10000-00000080f4b57708
>>> /lib64/libutil.so.1                                          00000080f4b10000-00000080f4b234a0
>>> Would prelink /lib64/ld-2.13.so
>>> Would prelink /lib64/libc-2.13.so
>>>
>>> Not sure what prelink is doing but it seems to breaking things.  Any ideas?
>>>
>>> ---
>>>
>>> I'm also concerned that we use /etc/prelink.conf when invoking prelink.
>>
>> Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is
>> the one inside of the image -- NOT the system version.
> 
> Is this because of psuedo or something else?

In the cross prelinker, we pass in the --root=<image>.  This instructs the
cross-prelinker to prefix <image> to most paths.

>> I would suspect that the cross-prelinker rtld emulation is likely setup for the
>> LSB style library paths and may be causing some of the problems.

You can run the cross-prelinker's rtld emulation by running the prelink-rtld
program located in build/tmp-eglibc/work/x86_64-linux/usr/sbin/prelink-rtld

Passing --root=<path> will setup the sysroot path for reference, adding in
--target-paths will allow you to pass further arguments as referenced on the
sysroot.

So prelink-rtld --root=/foo/bar/build/sysroot/image --target-paths /sbin/init

Should give you back an ldd like syntax within the sysroot, for /sbin/init.
(without --target-paths, you need to specify the full path to the /sbin/init..
this is useful when running the rtld against items outside of the image.)

>>
>> I'd suggest simply disabling prelink and getting everything to work first.. once
>> it does we can work through any prelinker issues.  (Prelink on PPC64 hasn't been
>> tested within the oe-core environment.. so it could very well have issues beyond
>> the ld.so path.)
> 
> Everything else is working, so prelink is what fails for me (at least for a simple minimal) build.
> 
> any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing?  When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not.

I'm the prelink maintainer for Yocto, however I know more about the way the
cross-prelinker functionality works then how the ELF specific prelink functions
work.  I've been relying on the upstream prelink project to manage the
individual architecture/ABI prelink standards.

My suggestion is to disable cross-prelinking, and revert to the upstream prelink
project -- run the binary on the target and see if it fails in the same way.  If
it does, then we know it's a deeper problem then the cross prelink integration.

You can pull down the git repository:  git://git.yoctoproject.org/prelink-cross.git

The "master" branch is identical to the upstream SVN branch.  The
"cross_prelink" branch is the current state of integration.

--Mark

> - k
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: prelink issue with ppc64?

[Kumar Gala]

On Aug 3, 2011, at 10:09 AM, Mark Hatle wrote:

> On 8/3/11 9:53 AM, Kumar Gala wrote:
>> 
>> On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote:
>> 
>>> On 8/3/11 12:35 AM, Kumar Gala wrote:
>>>> If prelink gets a chance to properly run I get a rootfs that does:
>>>> 
>>>> /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference
>>>> 
>>>> if 'baselib' is set to /lib we get:
>>>> 
>>>> /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker
>>>> 
>>>> if 'baselib' is set to /lib64 we get:
>>>> 
>>>> Assigned virtual address space slots for libraries:
>>>> /lib64/ld64.so.1                                             00000080f4910000-00000080f49473d0
>>>> /lib64/libc.so.6                                             00000080f4950000-00000080f4afe090
>>>> /lib64/libdl.so.2                                            00000080f4b10000-00000080f4b23520
>>>> /lib64/libcrypt.so.1                                         00000080f4b10000-00000080f4b57708
>>>> /lib64/libutil.so.1                                          00000080f4b10000-00000080f4b234a0
>>>> Would prelink /lib64/ld-2.13.so
>>>> Would prelink /lib64/libc-2.13.so
>>>> 
>>>> Not sure what prelink is doing but it seems to breaking things.  Any ideas?
>>>> 
>>>> ---
>>>> 
>>>> I'm also concerned that we use /etc/prelink.conf when invoking prelink.
>>> 
>>> Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is
>>> the one inside of the image -- NOT the system version.
>> 
>> Is this because of psuedo or something else?
> 
> In the cross prelinker, we pass in the --root=<image>.  This instructs the
> cross-prelinker to prefix <image> to most paths.
> 
>>> I would suspect that the cross-prelinker rtld emulation is likely setup for the
>>> LSB style library paths and may be causing some of the problems.
> 
> You can run the cross-prelinker's rtld emulation by running the prelink-rtld
> program located in build/tmp-eglibc/work/x86_64-linux/usr/sbin/prelink-rtld
> 
> Passing --root=<path> will setup the sysroot path for reference, adding in
> --target-paths will allow you to pass further arguments as referenced on the
> sysroot.
> 
> So prelink-rtld --root=/foo/bar/build/sysroot/image --target-paths /sbin/init
> 
> Should give you back an ldd like syntax within the sysroot, for /sbin/init.
> (without --target-paths, you need to specify the full path to the /sbin/init..
> this is useful when running the rtld against items outside of the image.)
> 
>>> 
>>> I'd suggest simply disabling prelink and getting everything to work first.. once
>>> it does we can work through any prelinker issues.  (Prelink on PPC64 hasn't been
>>> tested within the oe-core environment.. so it could very well have issues beyond
>>> the ld.so path.)
>> 
>> Everything else is working, so prelink is what fails for me (at least for a simple minimal) build.
>> 
>> any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing?  When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not.
> 
> I'm the prelink maintainer for Yocto, however I know more about the way the
> cross-prelinker functionality works then how the ELF specific prelink functions
> work.  I've been relying on the upstream prelink project to manage the
> individual architecture/ABI prelink standards.
> 
> My suggestion is to disable cross-prelinking, and revert to the upstream prelink
> project -- run the binary on the target and see if it fails in the same way.  If
> it does, then we know it's a deeper problem then the cross prelink integration.
> 
> You can pull down the git repository:  git://git.yoctoproject.org/prelink-cross.git
> 
> The "master" branch is identical to the upstream SVN branch.  The
> "cross_prelink" branch is the current state of integration.

So running prelink on target seems ok.  I used the version from prelink_git.bb.

- k

Re: prelink issue with ppc64?

[Kumar Gala]

On Aug 4, 2011, at 12:37 AM, Kumar Gala wrote:

> 
> On Aug 3, 2011, at 10:09 AM, Mark Hatle wrote:
> 
>> On 8/3/11 9:53 AM, Kumar Gala wrote:
>>> 
>>> On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote:
>>> 
>>>> On 8/3/11 12:35 AM, Kumar Gala wrote:
>>>>> If prelink gets a chance to properly run I get a rootfs that does:
>>>>> 
>>>>> /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference
>>>>> 
>>>>> if 'baselib' is set to /lib we get:
>>>>> 
>>>>> /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker
>>>>> 
>>>>> if 'baselib' is set to /lib64 we get:
>>>>> 
>>>>> Assigned virtual address space slots for libraries:
>>>>> /lib64/ld64.so.1                                             00000080f4910000-00000080f49473d0
>>>>> /lib64/libc.so.6                                             00000080f4950000-00000080f4afe090
>>>>> /lib64/libdl.so.2                                            00000080f4b10000-00000080f4b23520
>>>>> /lib64/libcrypt.so.1                                         00000080f4b10000-00000080f4b57708
>>>>> /lib64/libutil.so.1                                          00000080f4b10000-00000080f4b234a0
>>>>> Would prelink /lib64/ld-2.13.so
>>>>> Would prelink /lib64/libc-2.13.so
>>>>> 
>>>>> Not sure what prelink is doing but it seems to breaking things.  Any ideas?
>>>>> 
>>>>> ---
>>>>> 
>>>>> I'm also concerned that we use /etc/prelink.conf when invoking prelink.
>>>> 
>>>> Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is
>>>> the one inside of the image -- NOT the system version.
>>> 
>>> Is this because of psuedo or something else?
>> 
>> In the cross prelinker, we pass in the --root=<image>.  This instructs the
>> cross-prelinker to prefix <image> to most paths.
>> 
>>>> I would suspect that the cross-prelinker rtld emulation is likely setup for the
>>>> LSB style library paths and may be causing some of the problems.
>> 
>> You can run the cross-prelinker's rtld emulation by running the prelink-rtld
>> program located in build/tmp-eglibc/work/x86_64-linux/usr/sbin/prelink-rtld
>> 
>> Passing --root=<path> will setup the sysroot path for reference, adding in
>> --target-paths will allow you to pass further arguments as referenced on the
>> sysroot.
>> 
>> So prelink-rtld --root=/foo/bar/build/sysroot/image --target-paths /sbin/init
>> 
>> Should give you back an ldd like syntax within the sysroot, for /sbin/init.
>> (without --target-paths, you need to specify the full path to the /sbin/init..
>> this is useful when running the rtld against items outside of the image.)
>> 
>>>> 
>>>> I'd suggest simply disabling prelink and getting everything to work first.. once
>>>> it does we can work through any prelinker issues.  (Prelink on PPC64 hasn't been
>>>> tested within the oe-core environment.. so it could very well have issues beyond
>>>> the ld.so path.)
>>> 
>>> Everything else is working, so prelink is what fails for me (at least for a simple minimal) build.
>>> 
>>> any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing?  When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not.
>> 
>> I'm the prelink maintainer for Yocto, however I know more about the way the
>> cross-prelinker functionality works then how the ELF specific prelink functions
>> work.  I've been relying on the upstream prelink project to manage the
>> individual architecture/ABI prelink standards.
>> 
>> My suggestion is to disable cross-prelinking, and revert to the upstream prelink
>> project -- run the binary on the target and see if it fails in the same way.  If
>> it does, then we know it's a deeper problem then the cross prelink integration.
>> 
>> You can pull down the git repository:  git://git.yoctoproject.org/prelink-cross.git
>> 
>> The "master" branch is identical to the upstream SVN branch.  The
>> "cross_prelink" branch is the current state of integration.
> 
> So running prelink on target seems ok.  I used the version from prelink_git.bb.
> 
> - k

I get the following output when running cross_prelink by hand:

prelink: /lib64/libc.so.6: Recorded 1 dependencies, now seeing -1

I noticed this as well (in dmesg):

prelink-rtld[14492]: segfault at 289986a94 ip 0000000000408de2 sp 00007fff65ad3c10 error 4 in prelink-rtld[400000+e000]

- k

Re: prelink issue with ppc64?

[Mark Hatle]

On 8/4/11 12:37 AM, Kumar Gala wrote:
> 
> On Aug 3, 2011, at 10:09 AM, Mark Hatle wrote:
> 
>> On 8/3/11 9:53 AM, Kumar Gala wrote:
>>>
>>> On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote:
>>>
>>>> On 8/3/11 12:35 AM, Kumar Gala wrote:
>>>>> If prelink gets a chance to properly run I get a rootfs that does:
>>>>>
>>>>> /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference
>>>>>
>>>>> if 'baselib' is set to /lib we get:
>>>>>
>>>>> /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker
>>>>>
>>>>> if 'baselib' is set to /lib64 we get:
>>>>>
>>>>> Assigned virtual address space slots for libraries:
>>>>> /lib64/ld64.so.1                                             00000080f4910000-00000080f49473d0
>>>>> /lib64/libc.so.6                                             00000080f4950000-00000080f4afe090
>>>>> /lib64/libdl.so.2                                            00000080f4b10000-00000080f4b23520
>>>>> /lib64/libcrypt.so.1                                         00000080f4b10000-00000080f4b57708
>>>>> /lib64/libutil.so.1                                          00000080f4b10000-00000080f4b234a0
>>>>> Would prelink /lib64/ld-2.13.so
>>>>> Would prelink /lib64/libc-2.13.so
>>>>>
>>>>> Not sure what prelink is doing but it seems to breaking things.  Any ideas?
>>>>>
>>>>> ---
>>>>>
>>>>> I'm also concerned that we use /etc/prelink.conf when invoking prelink.
>>>>
>>>> Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is
>>>> the one inside of the image -- NOT the system version.
>>>
>>> Is this because of psuedo or something else?
>>
>> In the cross prelinker, we pass in the --root=<image>.  This instructs the
>> cross-prelinker to prefix <image> to most paths.
>>
>>>> I would suspect that the cross-prelinker rtld emulation is likely setup for the
>>>> LSB style library paths and may be causing some of the problems.
>>
>> You can run the cross-prelinker's rtld emulation by running the prelink-rtld
>> program located in build/tmp-eglibc/work/x86_64-linux/usr/sbin/prelink-rtld
>>
>> Passing --root=<path> will setup the sysroot path for reference, adding in
>> --target-paths will allow you to pass further arguments as referenced on the
>> sysroot.
>>
>> So prelink-rtld --root=/foo/bar/build/sysroot/image --target-paths /sbin/init
>>
>> Should give you back an ldd like syntax within the sysroot, for /sbin/init.
>> (without --target-paths, you need to specify the full path to the /sbin/init..
>> this is useful when running the rtld against items outside of the image.)
>>
>>>>
>>>> I'd suggest simply disabling prelink and getting everything to work first.. once
>>>> it does we can work through any prelinker issues.  (Prelink on PPC64 hasn't been
>>>> tested within the oe-core environment.. so it could very well have issues beyond
>>>> the ld.so path.)
>>>
>>> Everything else is working, so prelink is what fails for me (at least for a simple minimal) build.
>>>
>>> any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing?  When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not.
>>
>> I'm the prelink maintainer for Yocto, however I know more about the way the
>> cross-prelinker functionality works then how the ELF specific prelink functions
>> work.  I've been relying on the upstream prelink project to manage the
>> individual architecture/ABI prelink standards.
>>
>> My suggestion is to disable cross-prelinking, and revert to the upstream prelink
>> project -- run the binary on the target and see if it fails in the same way.  If
>> it does, then we know it's a deeper problem then the cross prelink integration.
>>
>> You can pull down the git repository:  git://git.yoctoproject.org/prelink-cross.git
>>
>> The "master" branch is identical to the upstream SVN branch.  The
>> "cross_prelink" branch is the current state of integration.
> 
> So running prelink on target seems ok.  I used the version from prelink_git.bb.

The prelink_git versions should be the cross-prelink version.  The only
difference MIGHT be the rtld emulation, but I'm not sure.

Any chance you can diff the output between the cross prelink and the on-target
prelink?  The other thing is to run the prelinker (on both systems) with the -v.
 This should give a more verbose set of prelinker information.  It would be
interesting if there are any differences between the two.

--Mark

> - k
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: prelink issue with ppc64?

[Mark Hatle]

On 8/4/11 9:03 AM, Kumar Gala wrote:
> 
> On Aug 4, 2011, at 12:37 AM, Kumar Gala wrote:
> 
>>
>> On Aug 3, 2011, at 10:09 AM, Mark Hatle wrote:
>>
>>> On 8/3/11 9:53 AM, Kumar Gala wrote:
>>>>
>>>> On Aug 3, 2011, at 9:37 AM, Mark Hatle wrote:
>>>>
>>>>> On 8/3/11 12:35 AM, Kumar Gala wrote:
>>>>>> If prelink gets a chance to properly run I get a rootfs that does:
>>>>>>
>>>>>> /sbin/init: relocation error: /lib64/libc.so.6: symbol _rtld_global_ro, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference
>>>>>>
>>>>>> if 'baselib' is set to /lib we get:
>>>>>>
>>>>>> /local/home/galak/git/poky/build-p5020/tmp/sysroots/x86_64-linux/usr/sbin/prelink: /sbin/init.sysvinit: Using /lib/ld64.so.1, not /lib64/ld64.so.1 as dynamic linker
>>>>>>
>>>>>> if 'baselib' is set to /lib64 we get:
>>>>>>
>>>>>> Assigned virtual address space slots for libraries:
>>>>>> /lib64/ld64.so.1                                             00000080f4910000-00000080f49473d0
>>>>>> /lib64/libc.so.6                                             00000080f4950000-00000080f4afe090
>>>>>> /lib64/libdl.so.2                                            00000080f4b10000-00000080f4b23520
>>>>>> /lib64/libcrypt.so.1                                         00000080f4b10000-00000080f4b57708
>>>>>> /lib64/libutil.so.1                                          00000080f4b10000-00000080f4b234a0
>>>>>> Would prelink /lib64/ld-2.13.so
>>>>>> Would prelink /lib64/libc-2.13.so
>>>>>>
>>>>>> Not sure what prelink is doing but it seems to breaking things.  Any ideas?
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> I'm also concerned that we use /etc/prelink.conf when invoking prelink.
>>>>>
>>>>> Prelinker is being run within the rootfs, so the /etc/prelink.conf being used is
>>>>> the one inside of the image -- NOT the system version.
>>>>
>>>> Is this because of psuedo or something else?
>>>
>>> In the cross prelinker, we pass in the --root=<image>.  This instructs the
>>> cross-prelinker to prefix <image> to most paths.
>>>
>>>>> I would suspect that the cross-prelinker rtld emulation is likely setup for the
>>>>> LSB style library paths and may be causing some of the problems.
>>>
>>> You can run the cross-prelinker's rtld emulation by running the prelink-rtld
>>> program located in build/tmp-eglibc/work/x86_64-linux/usr/sbin/prelink-rtld
>>>
>>> Passing --root=<path> will setup the sysroot path for reference, adding in
>>> --target-paths will allow you to pass further arguments as referenced on the
>>> sysroot.
>>>
>>> So prelink-rtld --root=/foo/bar/build/sysroot/image --target-paths /sbin/init
>>>
>>> Should give you back an ldd like syntax within the sysroot, for /sbin/init.
>>> (without --target-paths, you need to specify the full path to the /sbin/init..
>>> this is useful when running the rtld against items outside of the image.)
>>>
>>>>>
>>>>> I'd suggest simply disabling prelink and getting everything to work first.. once
>>>>> it does we can work through any prelinker issues.  (Prelink on PPC64 hasn't been
>>>>> tested within the oe-core environment.. so it could very well have issues beyond
>>>>> the ld.so path.)
>>>>
>>>> Everything else is working, so prelink is what fails for me (at least for a simple minimal) build.
>>>>
>>>> any suggestions on how to try and debug further, who might be more familiar with prelink and what its doing?  When I ran readelf -a on ld-2.13.so after prelink was getting weird results, not sure if thats normal or not.
>>>
>>> I'm the prelink maintainer for Yocto, however I know more about the way the
>>> cross-prelinker functionality works then how the ELF specific prelink functions
>>> work.  I've been relying on the upstream prelink project to manage the
>>> individual architecture/ABI prelink standards.
>>>
>>> My suggestion is to disable cross-prelinking, and revert to the upstream prelink
>>> project -- run the binary on the target and see if it fails in the same way.  If
>>> it does, then we know it's a deeper problem then the cross prelink integration.
>>>
>>> You can pull down the git repository:  git://git.yoctoproject.org/prelink-cross.git
>>>
>>> The "master" branch is identical to the upstream SVN branch.  The
>>> "cross_prelink" branch is the current state of integration.
>>
>> So running prelink on target seems ok.  I used the version from prelink_git.bb.
>>
>> - k
> 
> I get the following output when running cross_prelink by hand:
> 
> prelink: /lib64/libc.so.6: Recorded 1 dependencies, now seeing -1
> 
> I noticed this as well (in dmesg):
> 
> prelink-rtld[14492]: segfault at 289986a94 ip 0000000000408de2 sp 00007fff65ad3c10 error 4 in prelink-rtld[400000+e000]

That could explain it..  interesting that prelink didn't see the failure.

I'd suggest running w/ -v and see if that will tell you what it was processing
at the time.  Also collect a core and run me a back trace.  (You should create a
bug on bugzilla.yoctoproject.org.. add that info and assign it to me..  I'll try
to reproduce it or at least trace through the code and see what may have lead to
the failure.)

--Mark

> - k