Bug 2484 - When the baselib does not match the expected library path, prelinking is not done.
Summary: When the baselib does not match the expected library path, prelinking is not ...
Status: RESOLVED FIXED
Alias: None
Product: Cross-prelink
Classification: Yocto Project Subprojects
Component: poky integration (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium enhancement
Target Milestone: Future
Assignee: Mark Hatle
QA Contact:
URL:
Whiteboard:
: 5413 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-05-22 15:36 UTC by Mark Hatle
Modified: 2018-01-18 16:20 UTC (History)
6 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Yes (doc changes required)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Hatle 2012-05-22 15:36:09 UTC
baselib is variable within the OE environment.  For example on x86_64, it may be "/lib" or "/lib64".  The prelinker appears to be expecting it to always be "/lib64" and failing to prelink if it's "/lib".

Either the prelinker needs to be informed as to the baselib location, or it needs to be made more permissive of the ld.so location.
Comment 1 Song Liu 2012-06-26 17:53:08 UTC
Moving this to M3 as Mark does not have time for it now. Will take a look when we do M3 planning.
Comment 2 Mark Hatle 2014-02-27 15:42:02 UTC
*** Bug 5413 has been marked as a duplicate of this bug. ***
Comment 3 Mark Hatle 2014-02-27 15:44:12 UTC
Possible fix for the issue is to add an alternative set of base library paths within the prelinkers internal configuration (see ARM for an example).

Another possible way is to pass into the prelinker the valid base library paths, but this interface would require a way of saying which ELF types use which linkers.  That may prove to be more difficult for no reasonable benefit.

If the cross-prelinker could be modified at compile time to match the distribution, that would work -- but in the past we'd avoided it due to re-use of the binary components.
Comment 4 Mark Hatle 2015-04-28 18:08:18 UTC
Lowering importance to enhancement.

We've know about this for a while, but no real complaints.
Comment 5 Mark Hatle 2015-11-02 19:15:05 UTC
The prelinker has certain assumptions for the dynamic linker on the target.  If the assumption is not met, it will skip prelinking for that target.

Enabling multilib configuration or at a minimum defining:

baselib = "${BASE_LIB_tune-${DEFAULTTUNE}}"

should resolve the issue, with the expectation that the library path will meet the LSB/FHS expectations:

ARM - lib
ARM (AARCH64) - lib64

IA32 (i*86) - lib
IA32 (x32) - libx32
IA32 (x86_64) - lib64

MIPS (o32) - lib
MIPS64 (n32) - lib32
MIPS64 (n64) - lib64

Power (32-bit) - lib
Power (64-bit) - lib64

The prelinker has the following expectations for the ld.so:

arch-alpha.c:  .dynamic_linker = "/lib/ld-linux.so.2",
arch-arm.c:  .dynamic_linker = "/lib/ld-linux.so.3",
arch-arm.c:  .dynamic_linker_alt = "/lib/ld-linux-armhf.so.3",
arch-cris.c:  .dynamic_linker = "/lib/ld.so.1",
arch-i386.c:  .dynamic_linker = "/lib/ld-linux.so.2",
arch-ia64.c:  .dynamic_linker = "/lib/ld-linux-ia64.so.2",
arch-mips.c:  .dynamic_linker = "/lib/ld.so.1",
arch-mips.c:  .dynamic_linker_alt = "/lib32/ld.so.1",
arch-mips.c:  .dynamic_linker = "/lib/ld.so.1",
arch-mips.c:  .dynamic_linker_alt = "/lib64/ld.so.1",
arch-ppc64.c:  .dynamic_linker = "/lib64/ld64.so.1",
arch-ppc.c:  .dynamic_linker = "/lib/ld.so.1",
arch-s390.c:  .dynamic_linker = "/lib/ld.so.1",
arch-s390x.c:  .dynamic_linker = "/lib/ld64.so.1",
arch-sh.c:  .dynamic_linker = "/lib/ld-linux.so.2",
arch-sparc64.c:  .dynamic_linker = "/lib64/ld-linux.so.2",
arch-sparc.c:  .dynamic_linker = "/lib/ld-linux.so.2",
arch-x86_64.c:  .dynamic_linker = "/libx32/ld-linux-x32.so.2",
arch-x86_64.c:  .dynamic_linker = "/lib64/ld-linux-x86-64.so.2",