Unable to execute a file

Hi all,

I'm stuck with executing Twonky media server on the mini2440. I don't
understand why.
I downloaded Linux ARM little endian glibc 2.2.5 version here:
http://www.twonkyforum.com/downloads/6.0.34/

Then I unziped the file on the mini to the sdcard. Trying to lauch
mediaserver, here is what I get:

[root@FriendlyARM local]# ls -l /sdcard/twonkymedia
-rwxrwxrwx    1 root     root         2768 Sep  7 19:17 Linux-HowTo.txt
-rwxrwxrwx    1 root     root        57677 Sep  7 19:17 RevisionHistory
drwxrwxrwx    2 root     root         4096 Sep  7 19:17 cgi-bin
-rwxrwxrwx    1 root     root          193 Sep  7 19:17
initial_keystore.dat
drwxrwxrwx    2 root     root         4096 Sep  7 19:17 plugins
-rwxrwxrwx    1 root     root          421 Sep  7 19:17 radio.m3u
drwxrwxrwx    4 root     root        12288 Sep  7 19:17 resources
-rwxrwxrwx    1 root     root         4788 Sep  7 19:17 twonkymedia
-rwxrwxrwx    1 root     root          153 Sep  7 19:17
twonkymedia-server-defau
lt.ini
-rwxrwxrwx    1 root     root         3775 Sep  7 19:17 twonkymedia.sh
-rwxrwxrwx    1 root     root      1646664 Sep  7 19:17 twonkymediaserver
[root@FriendlyARM local]# /sdcard/twonkymedia/twonkymedia.sh

TwonkyMedia server
------------------
Syntax:
  /sdcard/twonkymedia/twonkymedia.sh {start|stop|restart|reload|status}

[root@FriendlyARM local]# /sdcard/twonkymedia/twonkymedia.sh start
Starting /sdcard/twonkymedia/twonkymedia ...
/sdcard/twonkymedia/twonkymedia.sh:
 line 154: /sdcard/twonkymedia/twonkymedia: not found

[root@FriendlyARM local]# /sdcard/twonkymedia/twonkymedia
-/bin/sh: /sdcard/twonkymedia/twonkymedia: not found
[root@FriendlyARM local]#


I don't understand the "not found" answer as the file exists and I have
execute rights.

I have to precise that I use the stock configuration, so FriendlyARM rootfs
with 2.6.32.2 kernel.

Can anyone help and explain my mistake?

Thanks

"not found" means in your case the program cannot be launched due to
missing libraries for example. Run a "readelf -d <your program>" and search
for lines with "(NEEDED)" in: the listed library must exist on your target.
Or start your program with the "strace" tool.

I didn't know the readelf command. Here is the result :

Dynamic section at offset 0xc38 contains 21 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000c (INIT)                       0x8604
 0x0000000d (FINI)                       0x8b9c
 0x00000004 (HASH)                       0x8130
 0x00000005 (STRTAB)                     0x8398
 0x00000006 (SYMTAB)                     0x81e8
 0x0000000a (STRSZ)                      268 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x10d1c
 0x00000002 (PLTRELSZ)                   192 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x8544
 0x00000011 (REL)                        0x853c
 0x00000012 (RELSZ)                      8 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x84dc
 0x6fffffff (VERNEEDNUM)                 2
 0x6ffffff0 (VERSYM)                     0x84a4
 0x00000000 (NULL)                       0x0

And if I look at the /lib folder

[root@FriendlyARM /]# ls -l /lib/libc*
-rwxr-xr-x    1 root     root      1189276 Mar 26  2009 /lib/libc-2.8.so
lrwxrwxrwx    1 root     root           11 Jan  8  2010 /lib/libc.so.6 ->
libc-2
.8.so
-rwxr-xr-x    1 root     root       181740 Mar 26  2009 /lib/libcidn-2.8.so
lrwxrwxrwx    1 root     root           14 Jan  8  2010 /lib/libcidn.so.1
-> lib
cidn-2.8.so
-rwxr-xr-x    1 root     root        38324 Mar 26  2009
/lib/libcrypt-2.8.so
lrwxrwxrwx    1 root     root           15 Jan  8  2010 /lib/libcrypt.so.1
-> li
bcrypt-2.8.so
[root@FriendlyARM /]# ls -l /lib/libpth*
-rwxr-xr-x    1 root     root        84248 Mar 26  2009
/lib/libpthread-2.8.so
lrwxrwxrwx    1 root     root           17 Jan  8  2010
/lib/libpthread.so.0 ->
libpthread-2.8.so
[root@FriendlyARM /]#

So the libraries seems to be present.
Also there is no strace tool on the mini, and I don't know how to use it

your help is appreciated

Maybe you can run 

 $ LD_DEBUG=all /sdcard/twonkymedia/twonkymedia

to get more information what is going wrong.

Hi Juergen

Thank you for your support. I tried your command but I think the problem is
elsewhere:

[root@FriendlyARM /]# $ LD_DEBUG=all /sdcard/twonkymedia/twonkymedia
sh: $: not found
[root@FriendlyARM /]# $LD_DEBUG=all /sdcard/twonkymedia/twonkymedia
sh: =all: not found
[root@FriendlyARM /]# $PATH
sh: /sbin:/usr/sbin:/bin:/usr/bin: not found
[root@FriendlyARM /]#

As you can see, the "not found" statement is always present, even when I
try to display the content of $PATH variable.

I'm not so familiar with linux, I have to say that this problem is out of
my knowledge.

Try this:

$ LD_DEBUG=all /lib/ld-<your-lib-rev>.so /sdcard/twonkymedia/twonkymedia

"ld-<your-lib-rev>.so" is the loader for dynamically linled programs. Here
on my Mini6410 rootfs it is "/lib/ld-2.13.so".

Nothing more :

[root@FriendlyARM /]# ls -l /lib/ld*
-rwxr-xr-x    1 root     root       121560 Mar 26  2009 /lib/ld-2.8.so
lrwxrwxrwx    1 root     root            9 Jan  8  2010 /lib/ld-linux.so.3
-> ld
-2.8.so
[root@FriendlyARM /]# $ LD_DEBUG=all /lib/ld-2.8.so
/sdcard/twonkymedia/twonkymedia
-/bin/sh: $: not found
[root@FriendlyARM /]# $ LD_DEBUG=all /lib/ld-linux.so.3
/sdcard/twonkymedia/twonkymedia
-/bin/sh: $: not found
[root@FriendlyARM /]# $LD_DEBUG=all /lib/ld-2.8.so
/sdcard/twonkymedia/twonkymedia
-/bin/sh: =all: not found
[root@FriendlyARM /]#

It's like $ is taken as an executable file which of course doesn't exist...

Ups, '$' is the prompt. I'm using it to show one should use the rest of the
line as a command to enter. Don't add it to the command. The command is
"LD_DEBUG=all /lib/ld-<your-lib-rev>.so /sdcard/twonkymedia/twonkymedia",
independent of the prompt sign you (or your system) are/is using.

Oh sorry, I thought there was something like this, like for assigning a
value to an environment variable like $PAHT, that's why I also test it
without space. As you are always root on the stock mini2440 root fs, the
character is "#" so it did not catch my attention.
I'll test it properly this evening.

Thank you for the explanation

There is nothing like a fixed prompt sign in our world. Neither '$' nor '#'
is fixed for root. Its just a matter of taste what character you setup in
your environment.

I forgot it was possible to change rhe prompt, I always used the original
prompt in my Linux distros (mainly Fedora, Knoppix). Now, thanks to your
explanation, I got some results:

[root@FriendlyARM /]# LD_DEBUG=all /lib/ld-2.8.so
/sdcard/twonkymedia/twonkymedia
       773:     file=/sdcard/twonkymedia/twonkymedia [0];  generating link
map
       773:       dynamic: 0x00010c38  base: 0x00000000   size: 0x00008d98
       773:         entry: 0x0000874c  phdr: 0x00008034  phnum:          6
       773:
       773:
       773:     file=libpthread.so.0 [0];  needed by
/sdcard/twonkymedia/twonkymedia [0]
       773:     find library=libpthread.so.0 [0]; searching
       773:      search cache=/etc/ld.so.cache
       773:      search
path=/lib/tls/v4l/half:/lib/tls/v4l:/lib/tls/half:/lib/tls:/lib/v4l/half:/lib/v4
l:/lib/half:/lib:/usr/lib/tls/v4l/half:/usr/lib/tls/v4l:/usr/lib/tls/half:/usr/l
ib/tls:/usr/lib/v4l/half:/usr/lib/v4l:/usr/lib/half:/usr/lib
           (system search path)
       773:       trying file=/lib/tls/v4l/half/libpthread.so.0
       773:       trying file=/lib/tls/v4l/libpthread.so.0
       773:       trying file=/lib/tls/half/libpthread.so.0
       773:       trying file=/lib/tls/libpthread.so.0
       773:       trying file=/lib/v4l/half/libpthread.so.0
       773:       trying file=/lib/v4l/libpthread.so.0
       773:       trying file=/lib/half/libpthread.so.0
       773:       trying file=/lib/libpthread.so.0
       773:
       773:     file=libpthread.so.0 [0];  generating link map
       773:       dynamic: 0x4001cef0  base: 0x40001000   size: 0x0001e204
       773:         entry: 0x4000538c  phdr: 0x40001034  phnum:          9
       773:
       773:
       773:     file=libc.so.6 [0];  needed by
/sdcard/twonkymedia/twonkymedia [0]
       773:     find library=libc.so.6 [0]; searching
       773:      search cache=/etc/ld.so.cache
       773:      search
path=/lib:/usr/lib/tls/v4l/half:/usr/lib/tls/v4l:/usr/lib/tls/half:/usr/lib/tls:
/usr/lib/v4l/half:/usr/lib/v4l:/usr/lib/half:/usr/lib
 (system search path)
       773:       trying file=/lib/libc.so.6
       773:
       773:     file=libc.so.6 [0];  generating link map
       773:       dynamic: 0x40147f18  base: 0x40020000   size: 0x0012b238
       773:         entry: 0x400351dc  phdr: 0x40020034  phnum:         10
       773:
       773:     checking for version `GLIBC_2.0' in file
/lib/libpthread.so.0 [0] required by file /sdcard/twonkymedia/twonkymedia
[0]
Segmentation fault
[root@FriendlyARM /]#

So we can see there is a segmentation fault in /lib/libpthread.so.0
Maybe replacing this library with the one of a cross compiler like
codeSourcery could be an idea?

Do not assemble the required libraries from different sources. Use the
binariey libraries from one toolchain only. This is what buildsystems like
openembedded/buildroot/PTXdist do: Everything that will be part of the root
filesystem will be built with one toolchain (compiler/linker/libs). You
should follow the same approach.

I agree with you, but I use the original rootfs from friendlyarm, so I
don't know what toolchain they used. I think it is the one which is in the
download section, and I think it comes from codeSourcery. I will use this
one as it is provided by FriendlyARM.
Anyway, do you think it can solvethe problem?

> Anyway, do you think it can solve the problem?

Yes it will. It makes your system consistent. Copying binaries from here
and there may work...but mostly not.

If you want a reliable system you should think about using a buildsystem.

That's the next step I would like to explore: building a whole root fs by
myself to understand more linux architecture. As I have understood,
buildroot, openembedded and PTXDist are tools to avoid doing everything by
hand each time you want to generate a rootfs, but I would like to try one
time to understand the full process instead of reading an internet page,
applying what is written and leaving the tool do all the job.

I wanted to copy all the original FriendlyARM rootfs on an NFS server to be
able to analyse it, and compare it easyly with another one, such as
pengutronix one. But I wasn't able to connect to my network hard drive,
doing the same method which works on my workstation.

I also have to find how to find the most suitable linux distro, find and
understand the differences between openembedded, buildroot, PTXDist and so
on.

For the moment I keep the original stock rootfs because is is complete,
with all drivers for GPIOs, ADC, screen and so on.

Hi Juergen,

I'm back with this topic. I've just tried with a fresh emDebian Lenny Grip
installation. I have the same troubles than before. Using LD_DEBUG reports
the same segmentation fault issue checking for GLIBC_2.0 in
/lib/libpthread.so.0.

This time, I have not modified the libraries, it is juste the fresh
original installation. Should I understand I have to cross compile glibc
and install it on the mini?

The twonkymedia package mentions "Linux ARM little endian glibc 2.2.5", is
there something I missed?
The revision is now 6.0.37 (http://www.twonkyforum.com/downloads/6.0.37/)
and the error is still present.

Thanks again for your help!

Sorry, I have no idea what the seg fault really means.

Ok, one last question:
I'm not so familiar with ARM architecture versions. Mini2440 uses ARMv4t
architecture. I thought that maybe the program I try to use is compiled for
ARMv5t architecture. Could it be the cause of the error?

In a more general way, I think it is not possible to use a software
compiled for ARMv5t on an ARMv4t processor, but ARMv4t compiled software
should run on ARMv5t processor, am-I right?

Thaks for your explanations

If it is compiled for ARMv5, it should give you an "illegal instruction",
but not a "segmentation fault".

Maybe you can check it with the help of the "readelf" tool. This example is
from my host, where I built my board support packages:

[jb@isonoe]> readelf -A platform-mini2440/root/bin/busybox
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "4T"
  Tag_CPU_arch: v4T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_VFP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align8_needed: Yes
  Tag_ABI_align8_preserved: Yes, except leaf SP
  Tag_ABI_enum_size: int
  Tag_unknown_44: 1 (0x1)

In contrast:

[jb@isonoe]> readelf -A platform-mini6410/root/bin/busybox
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM1176JZF-S"
  Tag_CPU_arch: v6KZ
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_VFP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align8_needed: Yes
  Tag_ABI_align8_preserved: Yes, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_unknown_44: 1 (0x1)
  Tag_Virtualization_use: Allowed

And yes, an ARMv4 program should run without any problems on an ARMv5 CPU.
(like an i386 or i486 program should still run on a modern Pentium)