New: Name collision of rpath token expansion and internal variables
https://bugs.busybox.net/show_bug.cgi?id=7172
Summary: Name collision of rpath token expansion and internal
variables
Product: buildroot
Version: 2014.05
Platform: PC
OS/Version: Linux
Status: NEW
Severity: major
Priority: P5
Component: Other
AssignedTo: unassigned at buildroot.uclibc.org
ReportedBy: minimod at morethan.org
CC: buildroot at uclibc.org
Estimated Hours: 0.0
Ref: man ld.so
Example:
In menu -> tool chain -> Target Linker Options (BR2_TARGET_LDFLAGS) to:
-Wl,-rpath='$ORIGIN/../lib'
(A relative path from executable to pathname of its required libraries. The example in ld.so manual.).
Build BusyBox (which honors BR_TARGET_LDFLAGS, not everything does).
Use: readelf -dl on the resulting binary and find an entry similar to:
0x0000000f (RPATH) Library rpath: [outputRIGIN/../lib]
Where the $O of $ORIGIN has been expanded to an internal value by the time the content of BR2_TARGET_LDFLAGS is seen by the compiler.
This was when using the Buildroot generation of a toolchain. Other toolchain selections not tested.
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
https://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #1 from Samuel Martin <[email protected]> 2014-06-08 07:03:28 UTC --- Mike,
(In reply to comment #0)
Quoted 8 lines
Ref: man ld.so
Example:
In menu -> tool chain -> Target Linker Options (BR2_TARGET_LDFLAGS) to:
-Wl,-rpath='$ORIGIN/../lib'
(A relative path from executable to pathname of its required libraries. The example in ld.so manual.).
Quoted 7 lines
Build BusyBox (which honors
BR_TARGET_LDFLAGS, not everything does).Use: readelf -dl on the resulting binary and find an entry similar to:
0x0000000f(RPATH) Library rpath: [outputRIGIN/../lib]Where the $O of $ORIGIN has been expanded to an internal value by the time the content of
BR2_TARGET_LDFLAGSis seen by the compiler.
Unfortunately, there is no trivial solution. This bug comes from the interaction between Buildroot and the packages' build-systems (especially those based on autotools).
I mean there no easy way to correctly escape "$ORIGIN" in makefiles (form Buildroot and the package itself) or/and in sh scripts.
Quoted 3 lines
This was when using the Buildroot generation of a toolchain. Other toolchain selections not tested.
The toolchain has nothing to do with this issue.
From the couple of experiments I run, the only reliable solution to correctly set RPATH is using chrpath or patchelf at the end of the build.
Regards,
Samuel
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
Quoted 23 lines · On Sun, 8 Jun 2014 07:03:29 +0000 (UTC) bugzilla at busybox.net wrote:
https://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #1 from Samuel Martin <[email protected]> 2014-06-08 07:03:28 UTC --- Mike,
(In reply to comment #0)
Quoted 8 lines
Ref: man ld.so
Example:
In menu -> tool chain -> Target Linker Options (BR2_TARGET_LDFLAGS)
to: -Wl,-rpath='$ORIGIN/../lib'
(A relative path from executable to pathname of its required libraries. The example in ld.so manual.).Quoted 8 lines
Build BusyBox (which honors
BR_TARGET_LDFLAGS, not everything does).Use: readelf -dl on the resulting binary and find an entry similar
to:0x0000000f(RPATH) Library rpath:
[outputRIGIN/../lib]Where the $O of $ORIGIN has been expanded to an internal value by the time the content of
BR2_TARGET_LDFLAGSis seen by the compiler.
Quoted 7 lines
Unfortunately, there is no trivial solution. This bug comes from the interaction between Buildroot and the packages' build-systems (especially those based on autotools).
I mean there no easy way to correctly escape "$ORIGIN" in makefiles (form Buildroot and the package itself) or/and in sh scripts.
Grumble.
But I half-way expected that finding.
;)
Quoted 11 lines
Quoted 3 lines
This was when using the Buildroot generation of a toolchain. Other toolchain selections not tested.
The toolchain has nothing to do with this issue.
From the couple of experiments I run, the only reliable solution to correctly set RPATH is using chrpath or patchelf at the end of the build.
That (patchelf ref:
http://anonscm.debian.org/gitweb/?p=collab-maint/patchelf.git;a=summary
http://nixos.org/patchelf.html)
was going to be my 'temporary' work-around.
Along with a post-build script to munge things as required.
Not so temporary now I guess.
- - - -
There is an alternative, for people who only need a very few binaries built - -
Set 'Target Linker Options' to a long string, longer than they will need, and after build hex-edit the binaries to the required string.
But that gets tiring real soon. ;)
And some packages are ignoring 'Target Linker Options' anyway. So even with this method, people would still need patchelf.
- - - -
Hmm...
I guess I should add a selection to build host-patchelf to BR. Someone else out there might need it, even if they don't need ld.so token expansion in runpath and/or rpath.
Thanks for taking the time to check this out.
Might have to mark it as: "Can't be fixed" in the bug tracker.
Mike
Quoted 5 lines
Regards,
Samuel
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
Quoted 50 lines · Mike Zick
Quoted 23 lines · On Sun, 8 Jun 2014 07:03:29 +0000 (UTC) bugzilla at busybox.net wrote:
https://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #1 from Samuel Martin <[email protected]> 2014-06-08 07:03:28 UTC --- Mike,
(In reply to comment #0)
Quoted 8 lines
Ref: man ld.so
Example:
In menu -> tool chain -> Target Linker Options (BR2_TARGET_LDFLAGS)
to: -Wl,-rpath='$ORIGIN/../lib'
(A relative path from executable to pathname of its required libraries. The example in ld.so manual.).Quoted 8 lines
Build BusyBox (which honors
BR_TARGET_LDFLAGS, not everything does).Use: readelf -dl on the resulting binary and find an entry similar
to:0x0000000f(RPATH) Library rpath:
[outputRIGIN/../lib]Where the $O of $ORIGIN has been expanded to an internal value by the time the content of
BR2_TARGET_LDFLAGSis seen by the compiler.Quoted 7 lines
Unfortunately, there is no trivial solution. This bug comes from the interaction between Buildroot and the packages' build-systems (especially those based on autotools).
I mean there no easy way to correctly escape "$ORIGIN" in makefiles (form Buildroot and the package itself) or/and in sh scripts.
Grumble.
But I half-way expected that finding.
;)Quoted 11 lines
Quoted 3 lines
This was when using the Buildroot generation of a toolchain. Other toolchain selections not tested.
The toolchain has nothing to do with this issue.
From the couple of experiments I run, the only reliable solution to correctly set RPATH is using chrpath or patchelf at the end of the build.
Quoted 4 lines
That (patchelf ref:
http://anonscm.debian.org/gitweb/?p=collab-maint/patchelf.git;a=summary
http://nixos.org/patchelf.html)
was going to be my 'temporary' work-around.
I thought about:
http://nixos.org/patchelf.html
https://github.com/NixOS/patchelf
Quoted 19 lines
Along with a post-build script to munge things as required.
Not so temporary now I guess.
- - - -
There is an alternative, for people who only need a very few binaries built - -
Set 'Target Linker Options' to a long string, longer than they will need, and after build hex-edit the binaries to the required string.But that gets tiring real soon. ;)
And some packages are ignoring 'Target Linker Options' anyway. So even with this method, people would still need patchelf.- - - -
Quoted 8 lines
Hmm...
I guess I should add a selection to build host-patchelf to BR. Someone else out there might need it, even if they don't need ld.so token expansion in runpath and/or rpath.Thanks for taking the time to check this out.
Might have to mark it as: "Can't be fixed" in the bug tracker.
BTW, why do you need to tweak RPATH in the target fs? What is your use-case? (just curious ;-])
Buildroot builds and installs everything consistently, so libraries get installed in /lib and /usr/lib, and binaries do not have any RPATH.
Usually, one needs RPATH when some binaries needs libraries that are not installed in the default locations.
Some others solutions are:
1) set the LD_LIBRARY_PATH in the binary environment;
2) add the additional paths in some $(TARGET_DIR)/etc/ld.so.conf.d/*.conf files.
Regards,
Signature · 1 line
Samuel
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
Quoted 16 lines · On Sun, 8 Jun 2014 13:24:13 +0200 Samuel Martin <[email protected]> wrote:
Quoted 8 lines
Hmm...
I guess I should add a selection to build host-patchelf to BR. Someone else out there might need it, even if they don't need ld.so token expansion in runpath and/or rpath.Thanks for taking the time to check this out.
Might have to mark it as: "Can't be fixed" in the bug tracker.BTW, why do you need to tweak RPATH in the target fs? What is your use-case? (just curious ;-])
Buildroot builds and installs everything consistently, so libraries get installed in /lib and
/usr/lib, and binaries do not have any RPATH.
Quoted 7 lines
Usually, one needs RPATH when some binaries needs libraries that are not installed in the default locations.
Some others solutions are:
1) set theLD_LIBRARY_PATHin the binary environment;
2) add the additional paths in some $(TARGET_DIR)/etc/ld.so.conf.d/*.conf files.
After-market feature supplements for consumer devices. In this case, the Amazon Kindle e-book readers:
http://www.mobileread.com/forums/forumdisplay.php?f=150 (as: knc1) Specifically, the project-of-the-moment:
https://bitbucket.org/twobob/kual-system
See: ARMhf on the Kindle(s) at the first link above.
Requirements (limitations, opportunities to stretch mind, etc):
* Do not disturb Amazon/Lab126 system image.
** Limited storage space for changes
** Causes end-users no end of grief when a vendor update is issued ** No Kernel / u-boot updates allowed - outside of end-user skills
* End-user additions to reside in user accessible storage (same storage used by books)
** Its FAT32 (no sym-links)
** Supplement the vendors old (pre-GPLv3) soft-float system and applications with a modern hard-float system and applications. (devices more recent than the Kindle Keyboard are Cortex-A{8,9}).
The Buildroot related issue-of-the-moment:
BR2_TARGET_LDFLAGS="-Wl,--dynamic-linker=/mnt/us/extensions/system/lib/ld-linux-armhf.so.3,-rpath=/mnt/us/extensions/system/lib,--enable-new-dtags"
But:
BR2_TARGET_LDFLAGS="-Wl,--dynamic-linker=/mnt/us/extensions/system/lib/ld-linux-armhf.so.3,-rpath=${ORIGIN}/../lib/${CPU},--enable-new-dtags"
Might well be useful in our simplified FHS extension layout.
- - - -
If you own a Kindle (grayscale) e-book reader - give some of our stuff a try. (Hint: Start with the KUAL application launcher.)
We (the Mobileread developer community) have done everything from change the battery graphic to a percentage display;
upto and including speaker independent voice recognition reader control.
A real "busman's holiday" for embedded firmware developers. ;)
Mike
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
Dear Mike Zick,
Quoted 2 lines · Mike Zick
On Sun, 8 Jun 2014 13:24:13 +0200
Samuel Martin <[email protected]> wrote:
Sorry to interrupt the thread, but I'm wondering: if a bug was posted in the bug tracker, wouldn't it be better to have the discussion in the bug tracker? Otherwise, the next time we'll look at the bug tracker, we'll wonder what happened with this bug, and we may have troubles finding the discussion you're currently having.
Or at least attempt to summarize the mailing list thread in the bug tracker at some point.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #2 from Thomas De Schampheleire <[email protected]> 2014-06-08 14:04:55 UTC --- Not tested, but as $ORIGIN seems to be interpreted by make as ${O}RIGIN, then I guess using $$ORIGIN would work correctly, or if you prefer $${ORIGIN}.
This moves the responsibility of the correct escaping to the user, but as Samuel said there is no easy solution.
Once cleared out, we should document this in the manual though...
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #3 from Mike Z <[email protected]> 2014-06-08 14:21:43 UTC --- (In reply to comment #2)
Quoted 8 lines
Not tested, but as $ORIGIN seems to be interpreted by make as ${O}RIGIN, then I guess using $$ORIGIN would work correctly, or if you prefer $${ORIGIN}.
This moves the responsibility of the correct escaping to the user, but as Samuel said there is no easy solution.
Once cleared out, we should document this in the manual though...
Sounds worth trying, will test and post (here) the results.
It is a rare use case, needing to get the ld.so tokens in BR_TARGET_LDFLAGS to show up in the compiler command line as intended, but a valid one.
At the moment, the busybox package honors the setting of the "Target Linker Options" set in the config UI and the Lua package doesn't. So those will be my test cases.
(and maybe fix the Lua package at the same time.)
Mike
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #4 from Mike Z <[email protected]> 2014-06-08 15:56:21 UTC --- These results do not make any sense to me:
Single escaped: ${ORIGIN}/../lib
0x0000000f (RPATH) Library rpath: [/../lib]
0x0000001d (RUNPATH) Library runpath: [/../lib]
Double escaped: $${ORIGIN}/../lib
0x0000000f (RPATH) Library rpath: [/../lib]
0x0000001d (RUNPATH) Library runpath: [/../lib]
Triple escaped: $$${ORIGIN}/../lib
0x0000000f (RPATH) Library rpath: [../lib]
0x0000001d (RUNPATH) Library runpath: [../lib]
At this rate, adding enough '$' characters might delete all of BR. ;)
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #5 from Thomas De Schampheleire <[email protected]> 2014-06-08 16:03:34 UTC --- Is what you wrote here correct? (No copy paste error?) Case one and two are identical?
Have you tried four dollar signs? Depending on how things are parsed it may be needed...
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #6 from Mike Z <[email protected]> 2014-06-08 16:28:17 UTC --- (In reply to comment #5)
Quoted 5 lines
Is what you wrote here correct? (No copy paste error?) Case one and two are identical?
Have you tried four dollar signs? Depending on how things are parsed it may be needed...
Yup - not what I expected either.*
Will recheck for cockpit error here and the $$$$ case.
Mike
* I have noticed that menuconfig does not always detect (and save) a configuration
change that only involves editing a string field.
I'll "less .config" before each test next time.
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #7 from Samuel Martin <[email protected]> 2014-06-08 16:48:49 UTC --- (In reply to comment #6)
Quoted 10 lines
(In reply to comment #5)
Quoted 5 lines
Is what you wrote here correct? (No copy paste error?) Case one and two are identical?
Have you tried four dollar signs? Depending on how things are parsed it may be needed...Yup - not what I expected either.*
Will recheck for cockpit error here and the $$$$ case.
Well, I've already spent hours trying to figure out the right escape sequence... in vain :-(
I even ended up with some mad sequences of '$' and '\'.
[1] is just an example of the dirty things I tried! My advice: don't go there ;-).
To me, escaping '$' is a dead end (or at least, really hard, except fo CMake-based packages) because of:
- the make/shell escape character is '$' vs. '\';
- the unpredictable (or hard-to-predict) level/number of make/shell nested, even for packages using the autotools (Makefile + libtool + ... + custom commands).
That's why I end up thinking that a solution based on chrpath or patchelf is the only sane way of handling the '$ORIGIN' support in RPATH (for both target and host packages).
BTW, this is part of the "relocatable SDK" item, which is somewhere in my todo list. I have a couple of branches (maybe more than just a couple) in my github in which I test things from time to time, and that one day, I should gather and post a real RFC.
[1]
https://github.com/tSed/buildroot/commit/7d53fe664afd3c98b3609994c5bf2addf2f4f692
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #8 from Mike Z <[email protected]> 2014-06-08 18:18:26 UTC --- (In reply to comment #7)
Quoted 30 lines
(In reply to comment #6)
Quoted 10 lines
(In reply to comment #5)
Quoted 5 lines
Is what you wrote here correct? (No copy paste error?) Case one and two are identical?
Have you tried four dollar signs? Depending on how things are parsed it may be needed...Yup - not what I expected either.*
Will recheck for cockpit error here and the $$$$ case.
Well, I've already spent hours trying to figure out the right escape sequence... in vain :-(
I even ended up with some mad sequences of '$' and '\'.
[1] is just an example of the dirty things I tried! My advice: don't go there ;-).To me, escaping '$' is a dead end (or at least, really hard, except fo CMake-based packages) because of:
- the make/shell escape character is '$' vs. '\';
- the unpredictable (or hard-to-predict) level/number of make/shell nested, even for packages using the autotools (Makefile+ libtool + ... + custom commands).That's why I end up thinking that a solution based on chrpath or patchelf is the only sane way of handling the '$ORIGIN' support in RPATH (for both target and host packages).
Quoted 8 lines
BTW, this is part of the "relocatable SDK" item, which is somewhere in my todo list. I have a couple of branches (maybe more than just a couple) in my github in which I test things from time to time, and that one day, I should gather and post a real RFC.
[1]
https://github.com/tSed/buildroot/commit/7d53fe664afd3c98b3609994c5bf2addf2f4f692
Agreed - add host-patchelf to the packages and let some's post-build script deal with this.
If your working on a relocatable toolchain - note that your going to have to diddle glibc and its support binaries also.
- - -
But as requested earlier - the additional tests for the record:
The earlier ${ORIGIN} and &&{ORIGIN} cases **ARE** the same result.
Four $ case: $$$${ORIGIN}/../lib
0x0000000f (RPATH) Library rpath: [27445{ORIGIN}/../lib]
0x0000001d (RUNPATH) Library runpath:
[27445{ORIGIN}/../lib]
These are out-of-tree builds -
'/home/mszick/kA8/.' is the contents of $O
Single $ case: $ORIGIN/../lib
0x0000000f (RPATH) Library rpath:
[/home/mszick/kA8/.RIGIN/../lib]
0x0000001d (RUNPATH) Library runpath:
[/home/mszick/kA8/.RIGIN/../lib]
Double $ case $$ORIGIN/../lib
0x0000000f (RPATH) Library rpath: [/../lib]
0x0000001d (RUNPATH) Library runpath: [/../lib]
Triple $ case $$$ORIGIN/../lib
0x0000000f (RPATH) Library rpath:
[home/mszick/kA8/.RIGIN/../lib]
0x0000001d (RUNPATH) Library runpath:
[home/mszick/kA8/.RIGIN/../lib]
Quad $ case $$$$ORIGIN/../lib
0x0000000f (RPATH) Library rpath: [3092ORIGIN/../lib]
0x0000001d (RUNPATH) Library runpath: [3092ORIGIN/../lib]
The only pattern I see here is odd/even $ count.
PS:
rpath and runpath can be relative paths (in glibc-2.19 at least). but the path is resolved relative to cwd, not executable's location.
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #9 from Mike Z <[email protected]> 2014-06-08 18:20:29 UTC --- Ah,
That should be ${ORIGIN} and $${ORIGIN} are the same result. Really.
Mike
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #10 from Mike Z <[email protected]> 2014-06-10 12:40:57 UTC --- Today's (non-)progress summary:
Two issues:
First, the "Target Linker Options" string field in the configuration tree:
This field is probably of too general a use to mark it "Broken".
Now:
But a note in the help text and in the manual that the internal handling of any ld.so tokens ($ORIGIN, $PLATFORM, etc.) in the string will not be handled as expected.
Later:
This will probably require that we capture the output of printf in a variable rather than set it by assignment in critical locations of the infrastructure.
I.E: BR_SOMETHING = printf "%s" '$' 'ORIGIN' or even: BR_SOMETHING = printf "%q" '$' 'ORIGIN'
and possibly the equivalent Make command of that shell command.
I agree with adding the note(s) now because this will probably take a long time to resolve.
Second, the BR_TARGET_LDFLAGS handling:
The result of this handling appears to be a per-package situation.
The cases so far:
*) Not recognized
*) Correctly recognized and handled
*) Added (first) in a rpath or runpath that includes the trusted directories.
In my (non-developer) mind, this is a matter of "normal package maintenance" and to be fixed as found.
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #11 from Mike Z <[email protected]> 2014-06-11 21:36:58 UTC --- Printing the shell significant character(s) into a variable is confirmed to work at the manual entry shell level.
The Cliff's Notes example:
bin # export INT=printf '%s' '/mnt/us/extensions/system/lib/ld-linux-armhf.so.3' bin # echo $INT /mnt/us/extensions/system/lib/ld-linux-armhf.so.3 core2quad bin # patchelf --set-interpreter $INT busybox
bin # export LIB=printf '%s' '$' 'ORIGIN/../lib' '$' 'ORIGIN/../usr/lib' bin # echo $LIB
$ORIGIN/../lib:$ORIGIN/../usr/lib
bin # patchelf --set-rpath $LIB busybox
====
bin # readelf -dl busybox
- - - -
Dynamic section at offset 0x13a180 contains 24 entries:
Tag Type Name/Value
0x0000001d (RUNPATH) Library runpath:
[$ORIGIN/../lib:$ORIGIN/../usr/lib]
====
[root at kindle root]# echo $PATH /mnt/us/extensions/system/bin:/usr/local/bin:/bin:/usr/bin:/usr/sbin:/sbin:/usr/local/python/bin
[root at kindle root]# LD_DEBUG=libs busybox
27571: find library=libc.so.6 [0]; searching
- - - -
27571: calling init: /mnt/us/extensions/system/bin/../lib/libc.so.6- - - -
BusyBox v1.22.1 (2014-06-11 02:23:01 CDT) multi-call binary. BusyBox is copyrighted by many authors between 1998-2012. etc.
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
Thomas De Schampheleire <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2014.08
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
Thomas De Schampheleire <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2014.08 |---
--- Comment #12 from Thomas De Schampheleire <[email protected]> 2014-06-22 13:52:49 UTC --- (sorry incorrect bug for milestone)
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #13 from Thomas De Schampheleire <[email protected]> 2014-06-29 13:14:26 UTC --- Mike,
Would you care to send patches to the mailing list to implement these changes? In a first step, the 'Now' comment, and then the alternative you proposed. Having the changes on the mailing list will facilitate the discussion and review, as few developers look at the bug comments.
Thanks, Thomas
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
Quoted 8 lines · On Sun, 29 Jun 2014 13:14:27 +0000 (UTC) bugzilla at busybox.net wrote:
https://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #13 from Thomas De Schampheleire <[email protected]> 2014-06-29 13:14:26 UTC --- Mike,
Would you care to send patches to the mailing list to implement these changes? In a first step, the 'Now' comment,
The 'Now" comment is just a text message edit -
that is within my paygrade to handle. ;)
And maybe an addition to the "known bugs" in the manual. I think this one will be around for a long time.
Quoted 4 lines
and then the alternative
you proposed. Having the changes on the mailing list will facilitate the discussion and review, as few developers look at the bug comments.
The "fix" (work-a-round) of assigning the output of a:
"printf '%s' '$' 'ORIGIN' ... "
I was using, was in a post image build script (outside of Buildroot). (I no longer need an '$ORIGIN' - changed my planning to not need it.)
I don't know the "Make" equivalent, nor where in the infrastructure the change needs to be made.
Something way outside of my paygrade I am afraid.
That will have to wait for someone very familiar with the BR infrastructure to have a long lasting attack of boredom and free time.
Mike
Quoted 2 lines
Thanks, Thomas
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
--- Comment #14 from Mike Z <[email protected]> 2014-07-07 13:06:43 UTC --- Ah, phooey, forgot to reply to the bug discussion thread.
The 'shell' code work around example can be found here:
http://www.mobileread.com/forums/showthread.php?p=2848930&postcount=18
I do not have the required knowledge of Buildroot infrastructure to find where / how to incorporate that into the system properly.
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
Thomas De Schampheleire <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |2014.08
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
Thomas De Schampheleire <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |yann.morin.1998 at free.fr
--- Comment #15 from Thomas De Schampheleire <[email protected]> 2014-07-30 20:15:23 UTC --- Yann,
You submitted a patch to update the documentation and add patchelf, but
currently these patches are marked as Changes Requested.
Any chance they could still be submitted for 2014.08?
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
Yann E. MORIN <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at buildroot.uclibc |yann.morin.1998 at free.fr
|.org |
--- Comment #16 from Yann E. MORIN <[email protected]> 2014-07-30 22:41:42 UTC --- Thomas,
Yes, I'll respin them.
Thanks for the reminder.
Regards,
Yann E. MORIN.
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=7172
Thomas De Schampheleire <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED--- Comment #17 from Thomas De Schampheleire <[email protected]> 2014-08-01 17:22:43 UTC --- Bug closed after documentation and workaround commits:
http://git.buildroot.org/buildroot/commit/?id=a930d9cef6bdcf8de7d086ea66d977530200b8e0
http://git.buildroot.org/buildroot/commit/?id=8f570cd765d52da56b4cebd4e5149ab8ebceec7f
Signature · 3 lines
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.