[Buildroot] [Bug 7172] New: Name collision of rpath token expansion and internal variables

[Buildroot] [Bug 7172] New: Name collision of rpath token expansion and internal variables

[bugzilla at busybox.net]

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.

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #1 from Samuel Martin <s.martin49@gmail.com> 2014-06-08 07:03:28 UTC ---
Mike,

(In reply to comment #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.

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.

> 
> 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

-- 
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

[Mike Zick]

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 <s.martin49@gmail.com> 2014-06-08
> 07:03:28 UTC --- Mike,
> 
> (In reply to comment #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.
> 
> 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.
;)

> > 
> > 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
> 
> Regards,
> 
> Samuel
> 

[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables

[Samuel Martin]

On Sun, Jun 8, 2014 at 12:38 PM, Mike Zick <minimod@morethan.org> wrote:
> 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 <s.martin49@gmail.com> 2014-06-08
>> 07:03:28 UTC --- Mike,
>>
>> (In reply to comment #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.
>>
>> 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.
> ;)
>
>> >
>> > 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.

I thought about:
http://nixos.org/patchelf.html
https://github.com/NixOS/patchelf

>
> 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.
>

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,

-- 
Samuel

[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables

[Mike Zick]

On Sun, 8 Jun 2014 13:24:13 +0200
Samuel Martin <s.martin49@gmail.com> wrote:

> > 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.
>

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

[Thomas Petazzoni]

Dear Mike Zick,

On Sun, 8 Jun 2014 07:57:48 -0500, Mike Zick wrote:
> On Sun, 8 Jun 2014 13:24:13 +0200
> Samuel Martin <s.martin49@gmail.com> 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
-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #2 from Thomas De Schampheleire <patrickdepinguin@gmail.com> 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...

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #3 from Mike Z <minimod@morethan.org> 2014-06-08 14:21:43 UTC ---
(In reply to comment #2)
> 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

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #4 from Mike Z <minimod@morethan.org> 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.
;)

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #5 from Thomas De Schampheleire <patrickdepinguin@gmail.com> 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...

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #6 from Mike Z <minimod@morethan.org> 2014-06-08 16:28:17 UTC ---
(In reply to comment #5)
> 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.

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #7 from Samuel Martin <s.martin49@gmail.com> 2014-06-08 16:48:49 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > 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

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #8 from Mike Z <minimod@morethan.org> 2014-06-08 18:18:26 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > 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

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.

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #9 from Mike Z <minimod@morethan.org> 2014-06-08 18:20:29 UTC ---
Ah,
That should be ${ORIGIN} and $${ORIGIN} are the same result.
Really.

Mike

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #10 from Mike Z <minimod@morethan.org> 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.

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #11 from Mike Z <minimod@morethan.org> 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.

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

Thomas De Schampheleire <patrickdepinguin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2014.08

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

Thomas De Schampheleire <patrickdepinguin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|2014.08                     |---

--- Comment #12 from Thomas De Schampheleire <patrickdepinguin@gmail.com> 2014-06-22 13:52:49 UTC ---
(sorry incorrect bug for milestone)

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #13 from Thomas De Schampheleire <patrickdepinguin@gmail.com> 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

-- 
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

[Mike Zick]

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
> <patrickdepinguin@gmail.com> 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.

> 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
> Thanks, Thomas
> 

[Buildroot] [Bug 7172] Name collision of rpath token expansion and internal variables

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

--- Comment #14 from Mike Z <minimod@morethan.org> 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.

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

Thomas De Schampheleire <patrickdepinguin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2014.08

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

Thomas De Schampheleire <patrickdepinguin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yann.morin.1998 at free.fr

--- Comment #15 from Thomas De Schampheleire <patrickdepinguin@gmail.com> 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?

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

Yann E. MORIN <yann.morin.1998@free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at buildroot.uclibc |yann.morin.1998 at free.fr
                   |.org                        |

--- Comment #16 from Yann E. MORIN <yann.morin.1998@free.fr> 2014-07-30 22:41:42 UTC ---
Thomas,

Yes, I'll respin them.
Thanks for the reminder.

Regards,
Yann E. MORIN.

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7172

Thomas De Schampheleire <patrickdepinguin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #17 from Thomas De Schampheleire <patrickdepinguin@gmail.com> 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

-- 
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.