Autor Thema: QNAP and ARM devices: libmediaclient.so cannot be preloaded after updating glibc  (Gelesen 13217 mal)

virtualdj

  • Newbie
  • *
  • Beiträge: 11
    • Profil anzeigen
Hi, I cross-post here what I've written on the QNAP forum (sorry for that) because I think that you're not actively monitoring that discussion.

TVHeadend application introduced several additions in the latest versions and I'm not able to compile it anymore with my old ARM VM that is using an old glibc (see for example my pending support ticket).

So my TVHeadend QPKG 0.9.1.1 distribution package has been upgraded to 0.9.2 with the newer glibc but this unfortunately broke the Sundtek libmediaclient on ARM.
This does not happen with x86_64, but I didn't change the libc in that case of course.

I haven't an ARM NAS to try myself directly, but I was able to replicate the problem within the ARM VM.
This is what it prints with older glibc (QPKG 0.9.1.1 WORKING):
root@debian-armel:~/test/old# LD_PRELOAD=/root/test/libmediaclient.so ./tvh-loader --library-path . ./tvheadend --config . --abort
2018-04-21 16:32:45.157 [   INFO] main: Log started
2018-04-21 16:32:45.283 [   INFO] http: Starting HTTP server 0.0.0.0:9981
2018-04-21 16:32:45.450 [   INFO] htsp: Starting HTSP server 0.0.0.0:9982
.. CUT ..
2018-04-21 16:32:46.274 [ NOTICE] START: HTS Tvheadend version 4.3-1152~g2baa719-dirty started, running as PID:1410 UID:0 GID:0, CWD:/root/test/old CNF:/root/test/old
Aborted
And this is with newer glibc (QPKG 0.9.2 FAILING):
root@debian-armel:~/test# LD_PRELOAD=/root/test/libmediaclient.so ./tvh-loader --library-path . ./tvheadend --config . --abort
ERROR: ld.so: object '/root/test/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
2018-04-21 16:31:20.125 [   INFO] main: Log started
2018-04-21 16:31:20.257 [   INFO] http: Starting HTTP server 0.0.0.0:9981
2018-04-21 16:31:20.347 [   INFO] htsp: Starting HTSP server 0.0.0.0:9982
.. CUT ..
2018-04-21 16:31:21.391 [ NOTICE] START: HTS Tvheadend version 4.3-1236~g518d57bee started, running as PID:1379 UID:0 GID:0, CWD:/root/test CNF:/root/test
Aborted

The library libmediaclient.so is the latest downloaded from your armsysvhf archive and it's the same between the two simulations (older/newer glibc).
As you can see, with the newer glibc it fails to preload with the error cannot open shared object file. Here's the library:
root@debian-armel:~/test# md5sum /root/test/libmediaclient.so
f5efb30c9169122960bb836f2e4149c5  /root/test/libmediaclient.so
root@debian-armel:~/test# file /root/test/libmediaclient.so
/root/test/libmediaclient.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped

The linux dynamic loader (ld.so renamed here as "tvh-loader" for my convenience) EABI seems compatibile too:
root@debian-armel:~/test# file tvh-loader
tvh-loader: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=4e62b2761d7a64fc51fd22235cff9e0ce5fccaa3, stripped

root@debian-armel:~/test# file old/tvh-loader
old/tvh-loader: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=277b871de46b49b3a538abbdb5d1cc0adb5440ec, stripped
The version of libc.so.6 is obviously different:
root@debian-armel:~/test# ./libc.so.6 | grep "Compiled"
Compiled by GNU CC version 6.3.0 20170516.

root@debian-armel:~/test# ./old/libc.so.6 | grep "Compiled"
Compiled by GNU CC version 4.4.5.
Compiled on a Linux 2.6.32 system on 2011-01-23.

I've also tried prepending LD_DEBUG=libs but there are not significant differences, while with LD_DEBUG=files there's this:
root@debian-armel:~/test# LD_DEBUG=files LD_PRELOAD=/root/test/libmediaclient.so ./tvh-loader --library-path . ./tvheadend --config . --abort   
      1536:     file=./tvheadend [0];  generating link map
      1536:
      1536:     WARNING: Unsupported flag value(s) of 0x8000000 in DT_FLAGS_1.
      1536:       dynamic: 0xb6d0f84c  base: 0xb5751000   size: 0x0180b660
      1536:         entry: 0xb58410c4  phdr: 0xb5751034  phnum:         10
      1536:
      1536:
      1536:     file=/root/test/libmediaclient.so [0];  needed by ./tvheadend [0]
ERROR: ld.so: object '/root/test/libmediaclient.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
      1536:
      1536:     file=libdvbcsa.so.1 [0];  needed by ./tvheadend [0]
      1536:     file=libdvbcsa.so.1 [0];  generating link map
      1536:       dynamic: 0xb574df08  base: 0xb572d000   size: 0x00021074
      1536:         entry: 0xb572db98  phdr: 0xb572d034  phnum:          6
      1536:
      1536:
      1536:     file=libssl.so.1.1 [0];  needed by ./tvheadend [0]
      1536:     file=libssl.so.1.1 [0];  generating link map
      1536:       dynamic: 0xb5728ee0  base: 0xb56cc000   size: 0x00060c7c
      1536:         entry: 0xb56da688  phdr: 0xb56cc034  phnum:          6
      1536:
      1536:
      .. CUT ..
     
root@debian-armel:~/test/old# LD_DEBUG=files LD_PRELOAD=/root/test/libmediaclient.so ./tvh-loader --library-path . ./tvheadend --config . --abort
      1566:     file=./tvheadend [0];  generating link map
      1566:       dynamic: 0xb6f0f270  base: 0xb638e000   size: 0x00bd8794
      1566:         entry: 0xb641c854  phdr: 0xb638e034  phnum:          9
      1566:
      1566:
      1566:     file=/root/test/libmediaclient.so [0];  needed by ./tvheadend [0]
      1566:     file=/root/test/libmediaclient.so [0];  generating link map
      1566:       dynamic: 0xb638b00c  base: 0xb6374000   size: 0x00017b68
      1566:         entry: 0xb63755b0  phdr: 0xb6374034  phnum:          5
      1566:
      1566:
      1566:     file=libssl.so.0.9.8 [0];  needed by ./tvheadend [0]
      1566:     file=libssl.so.0.9.8 [0];  generating link map
      1566:       dynamic: 0xb6370f4c  base: 0xb632a000   size: 0x00049cb8
      1566:         entry: 0xb6337d60  phdr: 0xb632a034  phnum:          5
      1566:
      1566:
      .. CUT ..

Have you got any suggestions on how to fix it? As I said, with the older glibc that preloads libmediaclient.so correctly I'm unable to compile the latest TVHeadend...  :(

Sundtek

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 8612
    • Profil anzeigen
Re:QNAP and ARM devices: libmediaclient.so cannot be preloaded after updating glibc
« Antwort #1 am: April 26, 2018, 02:29:24 Nachmittag »
Hi,

that's fine can you join the chat? I'm currently a bit busy so just wait for a while until I'm available.

We have new devices upcoming 4-8x Tuners which are also using the same driver package.

We can certainly add another driver build to our package :-)
Failure is a good thing! I'll fix it

virtualdj

  • Newbie
  • *
  • Beiträge: 11
    • Profil anzeigen
Re:QNAP and ARM devices: libmediaclient.so cannot be preloaded after updating glibc
« Antwort #2 am: April 26, 2018, 02:33:27 Nachmittag »
OK, I'm on the chat!

virtualdj

  • Newbie
  • *
  • Beiträge: 11
    • Profil anzeigen
Re:QNAP and ARM devices: libmediaclient.so cannot be preloaded after updating glibc
« Antwort #3 am: Mai 12, 2018, 04:58:00 Nachmittag »
From the latest tests it seems that the libmediaclient.so from armsysv works correctly with the TVHeadend loader (i.e. the tuner is visible), while the harmsysvhf does not.

There's a side, effect, though: users get the famous ERROR: ld.so: object 'libmediaclient.so' from LD_PRELOAD cannot be preloaded: ignored. message on the commands run before the loader, which are the QNAP binaries that do not use the updated libraries (such as echo, find, etc.).

EDIT: I cannot replicate this situation in my ARM VM (neither the armv5 nor armv7) and the library always preloads correctly, without any messages. But I would like to fix this small glitch too, or either suppress the error message.
« Letzte Änderung: Mai 12, 2018, 05:03:47 Nachmittag von virtualdj »

virtualdj

  • Newbie
  • *
  • Beiträge: 11
    • Profil anzeigen
Re:QNAP and ARM devices: libmediaclient.so cannot be preloaded after updating glibc
« Antwort #4 am: Mai 13, 2018, 11:22:30 Vormittag »
I still cannot understand why the system gives those errors. Here's the summary.

New TVHeadend version and dynamic loader for arm:
# file ./tvheadend
../tvheadend: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, BuildID[sha1]=92d8e0271ca790df2a030939e0dded2b4d2cff71, not stripped
# file ./ld.so
ld.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=4e62b2761d7a64fc51fd22235cff9e0ce5fccaa3, stripped

To use the Sundtek tuner by preloading the library with this TVHeadend, the only version that works armsysv, which is the following (EABI4):
# file ./libmediaclient.so
/share/CACHEDEV1_DATA/.qpkg/TVH_Dev_Sundtek/sundtek/opt/lib/libmediaclient.so: ELF 32-bit LSB shared object, ARM, EABI4 version 1 (SYSV), dynamically linked, stripped
... but it gives errors when using for example Busybox system commands like echo, etc.; this is the Busybox version:
# file /bin/busybox
/bin/busybox: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.1.1, BuildID[sha1]=77fd9f8a8a41b7511e636baa7842fd441a392944, stripped

The armsysvhf version of the library, instead, doesn't work with TVHeadend because it doesn't find /dev and it's the following:
# file libmediaclient.so
libmediaclient.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped

I'm pretty confused about this situation, because I though that EABI5 version 1 should work everywhere but this is not the case. Maybe the difference is the tag GNU/Linux instead of SYSV? I don't know...
I'll try to use LD_PRELOAD directly on the Linux loader instruction, instead of exporting the environment variable (which then applies also to other Busybox commands) to avoid the errors, but it's really a behaviour that I would like to understand. And Google doesn't seem to be my friend this time ???

Sundtek

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 8612
    • Profil anzeigen
Re:QNAP and ARM devices: libmediaclient.so cannot be preloaded after updating glibc
« Antwort #5 am: Mai 15, 2018, 07:26:44 Nachmittag »
we can have a further look at that on Friday (I'm currently busy with working on some new products here)
Failure is a good thing! I'll fix it