Quote:
Originally Posted by NiLuJe
So, yeah, as the venerable chrpath's manpage mentions, messing with ELF sections is... well, messy  .
Meaning, if possible, rebuild the broken stuff, or play with env vars; patchelf only as a last resort if you like working binaries  .
|
Well, I never said it was **easy** to use and have the binary survive the experience.

There was a reason I had to change the native add-ons path from:
/mnt/us/extensions/system/{lib, usr/lib}
to:
/mnt/us/esys/{lib, usr,lib}
In 5.3.4 the loader (from glibc 2.12 IIRC) has a problem:
Code:
# I am going to break this into multiple lines, it was a single line:
5711: search path=/mnt/us/tls/v7l/neon/vfp: \
/mnt/us/tls/v7l/neon: \
/mnt/us/tls/v7l/vfp: \
/mnt/us/tls/v7l: \
/mnt/us/tls/neon/vfp: \
/mnt/us/tls/neon: \
/mnt/us/tls/vfp: \
/mnt/us/tls: \
/mnt/us/v7l/neon/vfp: \
/mnt/us/v7l/neon: \
/mnt/us/v7l/vfp: \
/mnt/us/v7l: \
/mnt/us/neon/vfp: \
/mnt/us/neon: \
/mnt/us/vfp: \
##
## Whoot!! here it is (all the above are wrong.
## The system lib paths are **after** DT_RUNPATH)
##
/mnt/us (RUNPATH from file ./patchedelf)
##
## But anyway - its harmless in this case (but might not be in yours)
##
5711: trying file=/mnt/us/tls/v7l/neon/vfp/libstdc++.so.6
5711: trying file=/mnt/us/tls/v7l/neon/libstdc++.so.6
5711: trying file=/mnt/us/tls/v7l/vfp/libstdc++.so.6
5711: trying file=/mnt/us/tls/v7l/libstdc++.so.6
5711: trying file=/mnt/us/tls/neon/vfp/libstdc++.so.6
5711: trying file=/mnt/us/tls/neon/libstdc++.so.6
5711: trying file=/mnt/us/tls/vfp/libstdc++.so.6
5711: trying file=/mnt/us/tls/libstdc++.so.6
5711: trying file=/mnt/us/v7l/neon/vfp/libstdc++.so.6
5711: trying file=/mnt/us/v7l/neon/libstdc++.so.6
5711: trying file=/mnt/us/v7l/vfp/libstdc++.so.6
5711: trying file=/mnt/us/v7l/libstdc++.so.6
5711: trying file=/mnt/us/neon/vfp/libstdc++.so.6
5711: trying file=/mnt/us/neon/libstdc++.so.6
5711: trying file=/mnt/us/vfp/libstdc++.so.6
##
## All of the above was searched, just trying to self-destruct
## Now we get on with the documented behaviour:
##
5711: trying file=/mnt/us/libstdc++.so.6 ## DT_RUNPATH
5711: search cache=/etc/ld.so.cache ## system cache
5711: trying file=/usr/lib/libstdc++.so.6 ## system default tree
5711:
##
## Note: ***AFTER*** the first 'needed' library is searched for, ld.so gets it correct:
## I.E: It must be forgetting the 'not found' multi-lib paths to speed things up.
## Anyway - search multi-lib paths, DT_RUNPATH, system-cache, system single-lib paths is just wrong.
##
5711: find library=libgcc_s.so.1 [0]; searching
5711: search path=/mnt/us (RUNPATH from file ./patchedelf)
5711: trying file=/mnt/us/libgcc_s.so.1
5711: search cache=/etc/ld.so.cache
5711: trying file=/lib/libgcc_s.so.1
- - - - -
To duplicate, I did a:
Code:
[root@kindle us]# cd /mnt/us
[root@kindle us]# cp -a patchelf patchedelf
[root@kindle us]# ./patchelf --set-rpath '${ORIGIN}' patchedelf
[root@kindle us]# LD_DEBUG=libs ./patchedelf --help 1>stdout.txt 2>stderr.txt
And then clipped the above out of stderr.txt
@NiLuJe: your ARM version of patchelf works just as well as the Intel version I tried a year ago in my ARMhf on Kindle thread.
= = = = =
Now back to the kTerm fun-and-games, this time with the 0.7 (current) version.