Bug 1531

Summary:	Prelinking is broken on powerpc64
Product:	[Yocto Project Subprojects] Cross-prelink	Reporter:	Matthew McClintock <msm-oss>
Component:	cross-prelink	Assignee:	Mark Hatle <mark.hatle>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	Medium	CC:	mark.hatle, msm-oss, sgw, yp.cp.watcher, yp.watcher
Version:	unspecified
Target Milestone:	1.2
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	---

Description Matthew McClintock 2011-09-27 09:35:36 UTC

I realize there are no test platforms for powerpc64 but this is the issue I am seeing below. This is with a multilib install so you can see prelinking is working for the 32bit stuff, the 'perl' below is compiled as a 64bit lib to demonstrate the problem. (This issue occurs on a pure 64bit build as well - it just fails earlier)

Yocto (Built by Poky 5.0) 1.0+snapshot-20110926 p5020ds ttyS0

p5020ds login: root
root@p5020ds:~# perl
perl: relocation error: /lib64/libpthread.so.0: symbol _rtld_global, version GLIBC_PRIVATE not defined in file ld64.so.1 with link time reference
root@p5020ds:~# 

Looking in my do_rootfs log I see the following:

saving cache in big endian encoding
Size before prelinking 15612.
/local/home/mattsm/git/poky/build_p5020ds_release/tmp/sysroots/x86_64-linux/usr/sbin/prelink: 
/lib64/libc.so.6 Could not trace symbol resolving
Size after prelinking 15880.

Where should I start looking?

Comment 1 Mark Hatle 2011-09-29 10:04:01 UTC

The first thing you will need to do is ensure that the rtld (ld.so) emulation is working properly.

Build a system that is -not- prelinked..  one the target you will want to run a series of commands and generate the same type of information that the cross prelinker generations.  Specifically:

LD_TRACE_LOADED_OBJECTS=1 LD_TRACE_PRELINKING=1 LD_WARN= <ld.so> <binary thats failing>

LD_TRACE_LOADED_OBJECTS=1 LD_BIND_NOW=1 LD_TRACE_PRELINKING=1 <ld.so> <binary thats failing>

Store the output of the both of the commands about..

On your cross development system find the prelinker and run:

PRELINK_SYSROOT=<sysroot path> RTLD_TRACE_PRELINKING=1 RTLD_WARN= <prelink-rtld> --root <binary thats failing>

PRELINK_SYSROOT=<sysroot path> RTLD_TRACE_PRELINKING=1 <prelink-rtld> --root <binary thats failing>

Compare the output between the two.  Ignoring the actual link addresses (real vs emulated) the rest of the information should be identical, including order of everything.  If it's not the bug is in the prelink-rtld.  This code is based on the code for ld.so... references to the location of the original code are in the various files in the cross prelink sources.

If the output is identical, then the bug is more then likely in the prelinker as well.  If that is the case, I would suggest you avoid the cross-prelink sources and try to run the prelink binary, natively on the target system, and see if you get failures.  

If you do then it's an upstream issue we can probably report to the upstream maintainer.. If it's unique to the cross-prelink version (or in the prelink-rtld) then we'll need to figure out what is causing the problem to occur with the patched cross-prelink version.

Comment 2 Matthew McClintock 2011-11-14 14:41:37 UTC

Same issue

*** This bug has been marked as a duplicate of bug 1331 ***