Skip to contentSkip to conversation

hardcoded rpath in Qt 5.4.0 qtbase-native uic binary

meta-qt5 In review Andre McCurdy 2 participants 4 messages Jan 16, 2015 – Mar 11, 2015

lore
Share & tools
lore
#0 lore raw

The Qt 5.4.0 qtbase-native uic binary seems to get built with a hardcoded RUNPATH, which causes problems when qtbase-native from sstate is later reused by a different build. The issue has been there since 5.4.0 alpha1 (5.3.2 is OK).

--

Build Configuration:

BB_VERSION        = "1.25.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "LinuxMint-17.1"
TARGET_SYS        = "i586-rdk-linux"
MACHINE           = "vbox32"
DISTRO            = "rdk"
DISTRO_VERSION    = "2.0"
TUNE_FEATURES     = "m32 core2"
TARGET_FPU        = ""
meta-bsp-vbox     = "(detachedfrom253724d):253724dfeace58edbb40025fa8e4b5ace2c90164"
meta-rdk          = "(detachedfrom724d5c0):724d5c0030e3d2a53aad1929393ba2c00122ab91"
meta-qt5          = "(detachedfromec50df6):ec50df68b80f9704f135dd4c9f384a5596ec77cb"

meta-metrological = "(nobranch):abbd111fee3ae1ade2fc2997ccda0eb9782da761" meta-multimedia
meta-filesystems
meta-oe
meta-python
meta-networking
meta-ruby = "(detachedfrom7bbacd0):7bbacd0023fa1111da94ba0b2aafd7d872301ffe"
meta = "(detachedfromb61a2ac):b61a2acc321489c3427f0afa3059486dc144a13b"

$ readelf -d tmp/sysroots/x86_64-linux/usr/bin/qt5/uic

Dynamic section at offset 0x80c60 contains 27 entries:
Tag Type Name/Value

 0x0000000000000003 (PLTGOT)             0x481fe8
 0x0000000000000002 (PLTRELSZ)           4368 (bytes)
 0x0000000000000017 (JMPREL)             0x4033a0
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000007 (RELA)               0x4031a8
 0x0000000000000008 (RELASZ)             504 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000006 (SYMTAB)             0x400298
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000005 (STRTAB)             0x401570
 0x000000000000000a (STRSZ)              6625 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x402f58
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Core.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x4044b0
 0x000000000000000d (FINI)               0x4571cc
 0x000000000000001a (FINI_ARRAY)         0x480ce8
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x0000000000000019 (INIT_ARRAY)         0x480cf0
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001d (RUNPATH)            Library runpath: [/home/andre/rdk/rdk-master/build-vbox32/tmp/sysroots/x86_64-linux/usr/lib:/home/andre/rdk/rdk-master/build-vbox32/tmp/sysroots/x86_64-linux/lib]
 0x000000006ffffff0 (VERSYM)             0x402f90
 0x000000006ffffffe (VERNEED)            0x403124
 0x000000006fffffff (VERNEEDNUM)         2
 0x0000000000000000 (NULL)               0x0
#1 lore raw
Quoted 5 lines · Andre McCurdy

The Qt 5.4.0 qtbase-native uic binary seems to get built with a hardcoded RUNPATH, which causes problems when qtbase-native from sstate is later reused by a different build. The issue has been there since 5.4.0 alpha1 (5.3.2 is OK).

I'm still seeing this issue with Qt 5.4.1 and it seems to be related to using gold as the linker (ie adding ld-is-gold to DISTRO_FEATURES).

With Qt 5.4.x, including ld-is-gold in DISTRO_FEATURES causes uic (and other qtbase-native binaries) to be linked with "-fuse-ld=gold", which causes these binaries to have runtime library paths defined via "RUNPATH" instead of "RPATH".

Since chrpath.bbclass only fixes absolute paths in "RPATH", the absolute paths specified via "RUNPATH" in the installed binaries don't get fixed.

Quoted 58 lines

--

Build Configuration:

BB_VERSION        = "1.25.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "LinuxMint-17.1"
TARGET_SYS        = "i586-rdk-linux"
MACHINE           = "vbox32"
DISTRO            = "rdk"
DISTRO_VERSION    = "2.0"
TUNE_FEATURES     = "m32 core2"
TARGET_FPU        = ""
meta-bsp-vbox     = "(detachedfrom253724d):253724dfeace58edbb40025fa8e4b5ace2c90164"
meta-rdk          = "(detachedfrom724d5c0):724d5c0030e3d2a53aad1929393ba2c00122ab91"
meta-qt5          = "(detachedfromec50df6):ec50df68b80f9704f135dd4c9f384a5596ec77cb"

meta-metrological = "(nobranch):abbd111fee3ae1ade2fc2997ccda0eb9782da761" meta-multimedia
meta-filesystems
meta-oe
meta-python
meta-networking
meta-ruby = "(detachedfrom7bbacd0):7bbacd0023fa1111da94ba0b2aafd7d872301ffe"
meta = "(detachedfromb61a2ac):b61a2acc321489c3427f0afa3059486dc144a13b"

$ readelf -d tmp/sysroots/x86_64-linux/usr/bin/qt5/uic

Dynamic section at offset 0x80c60 contains 27 entries:
Tag Type Name/Value

 0x0000000000000003 (PLTGOT)             0x481fe8
 0x0000000000000002 (PLTRELSZ)           4368 (bytes)
 0x0000000000000017 (JMPREL)             0x4033a0
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000007 (RELA)               0x4031a8
 0x0000000000000008 (RELASZ)             504 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000006 (SYMTAB)             0x400298
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000005 (STRTAB)             0x401570
 0x000000000000000a (STRSZ)              6625 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x402f58
 0x0000000000000001 (NEEDED)             Shared library: [libQt5Core.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x4044b0
 0x000000000000000d (FINI)               0x4571cc
 0x000000000000001a (FINI_ARRAY)         0x480ce8
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x0000000000000019 (INIT_ARRAY)         0x480cf0
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001d (RUNPATH)            Library runpath: [/home/andre/rdk/rdk-master/build-vbox32/tmp/sysroots/x86_64-linux/usr/lib:/home/andre/rdk/rdk-master/build-vbox32/tmp/sysroots/x86_64-linux/lib]
 0x000000006ffffff0 (VERSYM)             0x402f90
 0x000000006ffffffe (VERNEED)            0x403124
 0x000000006fffffff (VERNEEDNUM)         2
 0x0000000000000000 (NULL)               0x0
#2 lore raw

PATCH 1/1 chrpath.bbclass: handle RUNPATH as well as RPATH

Binaries linked with gold may contain a RUNPATH instead of an RPATH. Update chrpath.bbclass process_file_linux() to handle both cases.

---
 meta/classes/chrpath.bbclass | 2 ++
 1 file changed, 2 insertions(+)
meta/classes/chrpath.bbclass +2 -0
index 77b1937..7a5d960 100644
@@ -10,6 +10,8 @@ def process_file_linux(cmd, fpath, rootdir, baseprefix, tmpdir, d):
     if p.returncode != 0:
         return
 
+    # Handle RUNPATH as well as RPATH
+    err = err.replace("RUNPATH=","RPATH=")
     # Throw away everything other than the rpath list
     curr_rpath = err.partition("RPATH=")[2]
     #bb.note("Current rpath for %s is %s" % (fpath, curr_rpath.strip()))
Signature · 1 line
1.9.1
#3 lore raw

Re: [PATCH] chrpath.bbclass: handle RUNPATH as well as RPATH

Quoted 6 lines · Andre McCurdy

Binaries linked with gold may contain a RUNPATH instead of an RPATH. Update chrpath.bbclass process_file_linux() to handle both cases.

This is ok. RPATH is deprecated, gold is forward looking by default, may be we should add --enable-new-dtags to binutils configuration in OE

Quoted 26 lines

---
meta/classes/chrpath.bbclass | 2 ++

1 file changed, 2 insertions(+)
meta/classes/chrpath.bbclass +2 -0
index 77b1937..7a5d960 100644
@@ -10,6 +10,8 @@ def process_file_linux(cmd, fpath, rootdir, baseprefix, tmpdir, d):
    if p.returncode != 0:
        return
 
+    # Handle RUNPATH as well as RPATH
+    err = err.replace("RUNPATH=","RPATH=")
    # Throw away everything other than the rpath list
    curr_rpath = err.partition("RPATH=")[2]
    #bb.note("Current rpath for %s is %s" % (fpath, curr_rpath.strip()))
Signature · 7 lines
1.9.1

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core