Good day

I have an application that runs fine on a Raspberry PI that use dynamic library's.

I now compiled it for a desktop( Debian ), both PI and Desktop is 64 bit architecture. There is nothing special like setting up paths that I did for the PI.

The application start on the desktop load the first library but then fail with error 2 when it try and load the next library. All are in the /usr/lib/ directory.

I use echo $LD_LIBRARY_PATH to make sure it is setup correctly. The access writes for the one library that work is the same as the rest.

I made sure all lib's are 64 bit compiled.

I will appreciate it if someone have any suggestions that can help me.

RPI uses a 32 bit arm cpu and is definitely not 64bit architecture. So it can't run 64bit software.

Do you use RPi as your Desktop(debian)? Or some Intel/AMD processor/cpu.

Oops, how did I miss that one. I use an Intel processor.

I am trying to debug it now on my laptop in Debian using Eclipse. The app starts but then get the following error in debugging -

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Error while mapping shared library sections:
`/usr/lib/libsvproxy.so': not in executable format: File format not recognized

Most of todays Intel/AMD cpus are 64 bit wide. Know that Intel/AMD cpu's are x86/x86_64 architecture but RPi is a ARM architecture. You can't run a binary/library of one architecture on another. That's why you are getting the error message: '`/usr/lib/libsvproxy.so': not in executable format: File format not recognized'.

You can find the architecture of a binary/library by running:

The error I mentioned above is after I compiled it in another workshop space for 64 bit. See file details below.

The first one is the executable that then call the utility lib that works fine and the next lib svproxy the fail. I also tried to call 2 other libs after the utility lib instead of the svproxy lib but they also fail.

nomad: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xec4163de99bf86d092e9f46f06c9453a2a3dd1ed, not stripped

libutility.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xd53627734fdf99bc0053cff72f7fdbc5faec9efd, not stripped

libsvproxy.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x3610200d7744cda4eb8ea42a21e87141844f5244, not stripped

Okay. I didn't understand your question correctly. Now I do. May be the libsvproxy.so file is damaged.

I have rebuild it and still get the same error. It's the first time I struggle so much to get a system up and running

Read the preceding comments carefully(!) before you continue banging your head fruitlessly against this wall. Unlike Windows, which only runs on Intel x86 processors of certain vintages, Linux software can run on ... and can be run on ... many different types of CPUs. You must be certain that your CPU is of the correct type to run the libraries that you have selected to download. (Most Linux software is cross-platform to some degree, and so can be compiled to different architectures. You must make sure that you have downloaded a binary for the proper architecture type.

Incidentally, you must also be sure that you have re-run the /sbin/ldconfig command, which might (or, might not) require root-privileges. Linux relies on a "loader cache" to enable it to find libraries without actually having to search the filesystem to do it. The aforementioned command rebuilds that cache.

The library's I use is library's I wrote and compiled myself with Eclipse.

I now compiled everything in 32 bit and downloaded Debian 32 bit and loaded it on a virtual box. Still getting the same issue I did with the 64 bit library's and 64 bit machine. I also have tried the 64 bit library's on a 64 bit Debian on a Virtual box and have the exact same issue.

If I compile the code for arm for the PI it works 100%.

So I would try ldd <application> and file on all the used shared libraries and on the app.

I have done the ldd on the application and the library that fails, it do find all the files it need. I also did the file on the application and the library's and all library's are elf 32-bit lsb shared objects and dynamically linked. The application is elf 32-bit lsb executable dynamically linked uses shared libs.

I'm a bit confused, you stated before you made a 64bit compilation, and now you say that is a 32bit app (and libs). So "Error while mapping shared library sections:" looks like caused by incompatible libraries, but I'm still unsure

I first tried the 64-bit, I then compiled it for 32-bit because I know on the Raspberry pi in 32-bit it works although it is arm.

Below is the screen output off the ldd and file commands.

nomad@debian:~/Nomad$ file nomad
nomad: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x1ace5fabe71280d06fd419fd5d5cc17a631f9802, not stripped

nomad@debian:~/Nomad$ file /usr/lib/libutility.so
/usr/lib/libutility.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x2c11304b5ea2d848213330cef7e0c021550b4d4d, not stripped

nomad@debian:~/Nomad$ file /usr/lib/libsimisl.so
/usr/lib/libsimisl.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xa56bc81d72c49d30800edd2ff1c8b5e24bd6b7af, not stripped

nomad@debian:~/Nomad$ ldd /usr/lib/libsimisl.so
linux-gate.so.1 => (0xf76fc000)
libdbase.so => /usr/lib/libdbase.so (0xf76cf000)
libftcore.so => /usr/lib/libftcore.so (0xf7677000)
libsession.so => /usr/lib/libsession.so (0xf7670000)
libutility.so => /usr/lib/libutility.so (0xf7648000)
libc.so.6 => /lib32/libc.so.6 (0xf74e3000)
libdl.so.2 => /lib32/libdl.so.2 (0xf74de000)
librt.so.1 => /lib32/librt.so.1 (0xf74d5000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf74bb000)
/lib/ld-linux.so.2 (0xf76fd000)

probably I would try to run using strace, I have still no idea which library caused that.