Some apps failing after 5.6.5 update

[knc1]

Originally Posted by Micky Wicky

- - - -
libjpeg attached.
Kterm does not use it, so if it still fails, the problem is with the libpng symlinks.
- - - -

Specifically, this one:

libpng12.so.0 -> libpng12.so.0.39.0

see references in tail of above post (last post of prior page, sorry about that).

[NiLuJe]

And FWIW, USBNet bundles most of the relevant elfutils tools, shipped with the eu- prefix (i.e., eu-readelf, eu-objdump, etc.).

As for patchelf, I think @knc1 posted binaries somewhere at one point . Barring that, it's trivial to build, ping me if that's an issue.

(That's of course if you wanted to do the work on-device. If you do that from outside, any decent Linux system will do ).

[knc1]

Oops - I did something wrong, that one is broken.

or my copy of patchelf did something wrong
the kterm file is now listed as "not a dynamic executable"
???????

[knc1]

@niluje: I never built an ARM patchelf - but it should be fairly easy to do.

If your build system supports C++ anyway. ;(

objdump -x /usr/local/bin/patchelf | grep 'NEEDED'
  NEEDED               libstdc++.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6

My attempts above at fixing kterm only breaks things.

[NiLuJe]

Let's see how that one behaves .

[knc1]

Still working on a way to test that.....
But in the meantime:
https://github.com/xlab/matchbox-keyboard/issues

= = = =

And another part of my self-induced problem(s) was that the most recent kTerm is 0.7 not 0.4
Phooey!

As kid goes off to re-install a complete set of everything on one of the Kindles here.

[normanr]

I used ubuntu utopic's patchelf to --set-rpath '$ORIGIN' matchbox-keyboard (--print-rpath returned a blank), and copied libpng12.so.0 from #14 to the same directory as kterm. Now KUAL logs just show 'Segmentation fault' when kterm runs ;-(

btw, using patchelf from #20 on the kindle (as part of kterm.sh) produces the same matchbox-keyboard as utopic's.

[NiLuJe]

Well, that failed spectacularly fast.

22:00:26 [4008d896] execve("kterm/bin/matchbox-keyboard", ["kterm/bin/matchbox-keyboard"], ["HISTFILESIZE=1000", "INPUTRC=/etc/inputrc", "SSH_CLIENT=192.168.2.1 40922 22", "USER=root", "HOSTNAME=kindle", "HOME=/tmp/root", "SSH_TTY=/dev/pts/0", "PAGER=less", "PS1=[\\u@\\h \\W]\\$ ", "LOGNAME=root", "TERM=xterm", "PATH=/usr/local/bin:/bin:/usr/bi"..., "DISPLAY=:0.0", "HISTSIZE=12000", "LANG=en_US.utf8", "SHELL=/bin/sh", "PWD=/tmp/root", "LC_ALL=en_US.utf8", "SSH_CONNECTION=192.168.2.1 40922"..., "KINDLE_TZ=GMT+01:00", "EDITOR=nano", "SHLVL=1", "OLDPWD=/tmp/root", "ZDOTDIR=/mnt/us/usbnet/etc/zsh", "LESSCOLOR=yes", "HOSTTYPE=armv7l", "COLORTERM=yes", "MANPAGER=less", "WORDCHARS=*?_[]~=&;!#$%^(){}", "LS_COLORS=no=00:fi=00:di=34:ow=3"..., "_=/usr/bin/strace"]) = 0
22:00:26 [40010d56] brk(NULL)           = 0x19000
22:00:26 [400021cc] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x6194} ---

Beat that! ;p.

EDIT:

TL;DR: Don't use '$ORIGIN' as-is, it blows up. Use the real absolute path, that doesn't.
And, according to the docs, use patchelf post-strip, some binutils versions don't like what patchelf does when stripping, and generate borked binaries.
EDIT: ... or not, I was working from an already-patchelf'ed binary. Doing that with the original binary segfaults >_w".

EDIT²:

'$ORIGIN/.' appears to work, on the other hand. The classic usage being something like '$ORIGIN/../lib', FWIW, which plays nicely with a classic *nix directory tree.
EDIT: ... or not, I was working from an already-patchelf'ed binary. Doing that with the original binary segfaults >_w".

EDIT^3:

'${ORIGIN}' works, though. Ah, the mysteries of ld ;o).
EDIT: ... or not, I was working from an already-patchelf'ed binary. Doing that with the original binary segfaults >_w".

NB: See next post.

[NiLuJe]

The takeway seems to be: don't use $ORIGIN at another time than link-time, or shit happens? And when you do that, maybe the magic -z,origin does is key?

EDIT:.... Nope, the takeaway seems to be that patchelf sometimes breaks stuff, depending on how much mess it has to make of the ELF headers to fit new stuff into .

Looking at the GH issues, we don't seem to be the only ones hitting these kinds of issues (that, and arm support is not even guaranteed by the author to begin with), so, yay?.

Setting a couple of bogus rpath w/ different lengths seems to shake things loose and leave you with a working? binary in the end, but the first (few?) set-rpath call(s) on a binary with NO existing RPATH/RUNPATH entries is ... not always sane.
Potential issues may not be limited to this, though, so, YMMV.

[normanr]

I also confirmed via usbnet that running LD_LIBRARY_PATH=$PWD ./kterm works fine.

Edit: Also so does just prefixing the kterm entry in kterm.sh with LD_LIBRARY_PATH :-)

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

[knc1]

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:

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

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

[NiLuJe]

@knc1: AFAIK, that's just one iteration of multilib hacks^Wsupport trying to be smart, it's been a while, but I'm pretty sure that's by design, and that nothing will every override those multilib search paths, at the very least for base libaries?
Granted, the way they get appendend to potentially user-specified base search-paths is freaky (and potentially hilariously dangerous, but that's always been a potential issue with custom searchpaths) ^^.

The issue with patchelf is that it just plain breaks binaries sometimes by reordering/resizing ELF sections in a way that makes binutils and/or the dynamic loader sad.
When it works, it works as well as it should, but in this specific instance, it breaks (at least) matchbox with certain rpath strings, unless you try again with a different string to force another resize/reorder (cf. what happens with --debug, I did a first set-rpath pass w/ $ORIGIN, and another w/ /mnt/us/foo; doing this in two passes works, doing either of those in one pass doesn't [segfault], as well as doing it in the reverse order).

[knc1]

I think what I ended up doing with the ARMhf project thread was pass the loader at build time a loooong rpath string, and that way, patchelf had enough string room without resizing any sections.

There is a reason you can't tell builtroot to always include '${ORIGIN}' because $O is the output directory/path when building out-of-tree and **ANYTHING** that starts with capital O gets trampled on.

[NiLuJe]

@knc1: Yeah, that sounds right, but at that rate, better to simply pass the linker the proper rpath at link-time and be done with it (which is how I handle that kind of stuff in my builds).
Sure, you lose a bit of flexibility, but it's not like we really need it anyway .