Beiträge anzeigen

Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.

Themen - virtualdj

Seiten: [1]
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 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 WORKING):
root@debian-armel:~/test/old# LD_PRELOAD=/root/test/ ./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
2018-04-21 16:32:45.450 [   INFO] htsp: Starting HTSP server
.. 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
And this is with newer glibc (QPKG 0.9.2 FAILING):
root@debian-armel:~/test# LD_PRELOAD=/root/test/ ./tvh-loader --library-path . ./tvheadend --config . --abort
ERROR: object '/root/test/' 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
2018-04-21 16:31:20.347 [   INFO] htsp: Starting HTSP server
.. 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

The library 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/
f5efb30c9169122960bb836f2e4149c5  /root/test/
root@debian-armel:~/test# file /root/test/
/root/test/ ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, stripped

The linux dynamic loader ( 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 is obviously different:
root@debian-armel:~/test# ./ | grep "Compiled"
Compiled by GNU CC version 6.3.0 20170516.

root@debian-armel:~/test# ./old/ | 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/ ./tvh-loader --library-path . ./tvheadend --config . --abort   
      1536:     file=./tvheadend [0];  generating link map
      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:     file=/root/test/ [0];  needed by ./tvheadend [0]
ERROR: object '/root/test/' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
      1536: [0];  needed by ./tvheadend [0]
      1536: [0];  generating link map
      1536:       dynamic: 0xb574df08  base: 0xb572d000   size: 0x00021074
      1536:         entry: 0xb572db98  phdr: 0xb572d034  phnum:          6
      1536: [0];  needed by ./tvheadend [0]
      1536: [0];  generating link map
      1536:       dynamic: 0xb5728ee0  base: 0xb56cc000   size: 0x00060c7c
      1536:         entry: 0xb56da688  phdr: 0xb56cc034  phnum:          6
      .. CUT ..
root@debian-armel:~/test/old# LD_DEBUG=files LD_PRELOAD=/root/test/ ./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:     file=/root/test/ [0];  needed by ./tvheadend [0]
      1566:     file=/root/test/ [0];  generating link map
      1566:       dynamic: 0xb638b00c  base: 0xb6374000   size: 0x00017b68
      1566:         entry: 0xb63755b0  phdr: 0xb6374034  phnum:          5
      1566: [0];  needed by ./tvheadend [0]
      1566: [0];  generating link map
      1566:       dynamic: 0xb6370f4c  base: 0xb632a000   size: 0x00049cb8
      1566:         entry: 0xb6337d60  phdr: 0xb632a034  phnum:          5
      .. CUT ..

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

Drivers / QNAP 64-bit drivers development question
« am: April 25, 2015, 04:46:19 Nachmittag »
Hi, I'm the same virtualdj user of the QNAP forum.
If you follow the main TVHeadend thread on the QNAP forums you may have known that TVHeadend application is now a fully 64-bit application.

So, thanks to QNAP that provided me a 64-bit NAS to test, I'm trying to develop a further version of the Sundtek QPKG to support TVHeadend in 64-bit mode. In fact, at the moment the only possible way is running TVHeadend 32-bit with the 32-bit flavour of the Sundtek drivers.

Now I understand because you asked me to update the script to support DVBLink package!

At first I tried installing the latest TVH_Dev_Sundtek QPKG and I found I cannot run mediaclient or the other bins.
[/share/CACHEDEV1_DATA/.qpkg/TVH_Dev_Sundtek/opt/bin] # mediaclient
mediaclient: error while loading shared libraries: wrong ELF class: ELFCLASS32

That's due to QNAP which does not supply all the complete 64-bit libraries:
[/share/CACHEDEV1_DATA/.qpkg/TVH_Dev_Sundtek/opt/bin] # ldd mediasrv =>  (0x00007fff1cdfe000) => not found => /lib64/ (0x00007fd4cfff9000) => not found => /lib64/ (0x00007fd4cfc76000)
        /lib64/ (0x00007fd4d0216000)
[/share/CACHEDEV1_DATA/.qpkg/TVH_Dev_Sundtek/opt/bin] # ls /lib64/***

So, to run mediaclient or mediasrv both and are needed, hence you used LD_LIBRARY_PATH to borrow them from the DVBLink package.
I also had to ship those libraries (and actually the complete libc) with TVHeadend as it didn't run without them. We can use the same principle with TVHeadend, but I don't like this very much. ;)

So I'm asking: what do you think if we build a QPKG specifically for 64-bit with the two libraries shipped with the QPKG, so that mediaclient can use them and TVH_Dev_Suntek will became standalone again?

I'm asking here because I can of course create a script that sets LD_LIBRARY_PATH before running mediaclient or mediasrv, but I prefer to not use LD_LIBRARY_PATH if possible.
So, do you think you can build the mediaclient, mediasrv and files (and others as well) compiled with:
In the future-version QPKG, I can create a libc folder inside the opt directory and place the libraries there and then the binaries should work from every path. Of course, if there is no libc folder, they should work as usual, looking for libraries in the system.

I tried with patchelf and it's working correctly with '$ORIGIN/../libc', at least for the binary files.
While preloading the libraries on 64-bit NAS gives me always this error:
[~] # LD_PRELOAD=/opt/lib/ ls
ERROR: object '/opt/lib/' from LD_PRELOAD cannot be preloaded: ignored.
The same on the 32-bit QNAP doesn't give any error:
[~] # LD_PRELOAD=/opt/lib/ ls
I cannot explain this behaviour, maybe it's due to the missing libraries too? We'll see!

Seiten: [1]