Sundtek Support Forum

This issue is now resolved with the latest drivers from last night. Big thanks to mrec for adding armhf support to the driver.
I'm now recording 1 show and watching 2 shows to test my new installation, and it works like a charm.

On a side note my bug report for the exit process issue in eglibc is now closed in debian, meaning it should refuse to load elf files with the wrong ABI instead of exiting the process from the next version.

I found the smoking gun - debian and ubuntu have added a check for vfp vs. softfp.

Apparently there is an arm attribute that tells whether an elf binary is compiled with vfp support. Some wise person thought it would be a good idea to exit the process instead of failing with wrong arch upon loading an elf.
I'll try to figure out how to make a bug report to both debian and ubuntu about this, since it is unacceptable that dlopen can exit an application. I mean, if you try to load a ppc elf on an x86 you will get an error, and not have your entire application closed.

Anywho, this means you will have to have 2 armsysv in the driver - one for softfp and one compiled with vfp support - even though you don't use fp in function calls.

I'll be happy to test out binaries on my trimslice, but I'm not willing to give access to it over ssh - sorry.
As for a qemu image, I've failed to find a kernel that will work with armhf and ubuntu/debian.

I'm on irc as ElmerFudd, but I'm trying to debug the issue within glibc. I'm having a hard time getting my head around the code, but I think I'm getting the hang of if.
So far I found out that both ubuntu and debian uses eglibc and not glibc. Using the LD_DEBUG flag and strace I've narrowed the code down to elf/dl-load.c so far.

I'll find time tomorrow to figure out where in eglibc it exits any application that tries to load libmediaclient, using the tried-and-proven printf method.
I think it is a bug in eglibc, to be honest. If you have some pointers as to debug (e)glibc it would be greatly appreciated.
I'm idling on irc

I've had it running quite fine when the first unofficial debian armhf port came along (November 2011).

But something has changed in debian I believe, with my new fresh install. Firstly, it failed to detect arm-sysv, since the binary that was supposed to detect it recuired libc.so.6 and a few other libs to be in /lib, which has changed in debian.
A few symlinks later I got it installed, but it will not preload libmediaclient.so.

I've built a small executable that I could strace, and found that the program exists immediately after loading the so :

---- program ----
#include <dlfcn.h>
#include <stdio.h>

int main()
{
  dlopen("/opt/lib/libmediaclient.so",RTLD_LAZY);
  printf("Opened\n");
  return 0;
}
---- program ----

Compiled with gcc test.c -ldl -o test

Never prints Opened, the return code is 1, if it helps.

---- strace snippet ----
open("/opt/lib/libmediaclient.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0004\31\0\0004\0\0\0"..., 512) = 512
lseek(3, 58456, SEEK_SET)               = 58456
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1000) = 1000
lseek(3, 58201, SEEK_SET)               = 58201
read(3, "A/\0\0\0aeabi\0\1%\0\0\0\5ARM9TDMI\0\6\2\10\1\t\1"..., 48) = 48
exit_group(1)                           = ?
---- strace snippet ----

The driver works fine on the old broken debian from november. What could possibly cause this? - If it was dependency issues then I believe it would have printed it, and definitely not exit on dlopen.
Do you have any clues as to what could have caused this, and how to fix it?

It fails the same way with the newest driver as well as with the one used on the old debian install.