2

I have cross compiled c++ code for raspberry pi.

Below is process I followed:

1) Cloned the official toolchain from raspberry pi github. Set the environment variable of arm-linux-gnueabihf-c++ (in .bashrc file).

2) Typed this command for generating binary for ARM architecture:

arm-linux-gnueabihf-c++ ./test.cpp -L. -lfoo -o test

3) Binary is successfully generated now. I tried to run the binary with below commands but had no luck with it.

LD_PRELOAD=/home/pi/Downloads/linux-sdk-demo-arm/libfoo.so ./test
LD_LIBRARY_PATH=/home/pi/Downloads/linux-sdk-demo-arm ./test

I even set the environment variable in .bashrc file but having no luck.

It gives the below errors respectively:

ERROR: ld.so: object './libfoo.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.<br/>
./test: error while loading shared libraries: libfoo.so: cannot open shared object file: No such file or directory

and

./test: error while loading shared libraries: libfoo.so: cannot open shared object file: No such file or directory

I'm sure the libfoo.so file is there at the right path but it can not find it. Here's the directory structure:

-rw-rw-r-- 1 pi pi  15263 Jan  9 17:23 cp5200api.h
-rw-rw-r-- 1 pi pi   1110 Mar  6 12:17 dtype.h
-rwxrwxrwx 1 pi pi 152751 Mar  9 13:43 libfoo.so
-rw-rw-r-- 1 pi pi    512 Mar 12 08:42 Makefile
-rw-rw-r-- 1 pi pi   1285 Mar  8 20:13 notplugged
-rw-rw-r-- 1 pi pi   1285 Mar  8 20:13 plugged
-rwxr-xr-x 1 pi pi  13228 Mar 12 08:42 test
-rw-rw-r-- 1 pi pi   2204 Mar  6 15:22 test.cpp
  • foo.so looks suspicious... Normally libraries are called libfoo.so under linux – Uwe Plonus Mar 14 '18 at 10:54
  • For naming convention i have written it as foo.so but in real its libfoo.so. Edited the question – Aniket Pawar Mar 14 '18 at 10:55
2
+50

One thing that doesn't look right is that your LD_PRELOAD contains an absolute path, while the error message complains about a relative path, ./libfoo.so. Make sure you use the absolute path in LD_PRELOAD.

If you're actually using LD_LIBRARY_PATH, you should check whether you've built test against libfoo.so, and not something else. Run

ldd ./test

and check out the library name that your program expects. Chances are, it corresponds to its SONAME which you can find with

objdump -p libfoo.so | grep SONAME

SONAME is typically slightly different, e.g. libfoo.so.0, and renaming (or symlinking) your library to that name will help.

Edit

Since the above doesn't seem to help, here's one more thing I would try. Add the full path containing libfoo.so to /etc/ld.so.conf. Then run

sudo ldconfig -v

Check the output for lines concerning libfoo.so, maybe there will be something useful.

Alternatively, try copying libfoo.so to one of the standard library locations, like /usr/local/lib, and again, run sudo ldconfig -v.

  • ldd ./test does show that libfoo.so does not found but i am sure that library is in the current directory. Also i tried everything including running executable,LD_PRELOAD and LD_LIBRARY_PATH with full path but having no luck – Aniket Pawar Mar 15 '18 at 5:49
  • objdump -p libfoo.so | grep libfoo outputs libfoo.so: file format elf32-littlearm – Aniket Pawar Mar 15 '18 at 5:56
  • @Aniket SONAME is not a placeholder for libfoo, it's an actual parameter of a shared library in Linux. You should therefore run grep SONAME, and make sure to make it uppercase. – Dmitry Grigoryev Mar 15 '18 at 12:13
  • it outputs nothing @grigoryev – Aniket Pawar Mar 15 '18 at 12:17
  • 2
    This answer is on the right track. It's odd that libfoo.so lacks a soname, but that isn't mandatory. Try more ldd commands including with the library search path i.e.: LD_LIBRARY_PATH=/home/pi/Downloads/linux-sdk-demo-arm ldd ./test and also run ldd libfoo.so. Ideally one of these commands will reveal a missing dependency (=> not found), mismatching libc version (compared to ldd --version) or the wrong loader (something other than /lib/ld-linux-armhf.so.3). – jdonald Mar 16 '18 at 5:12
0

Does libfoo is compiled as ARM library (or) x86 library. You can check and confirm this using file utility

file <absolute/relate_path_to_libfoo_folder>/libfoo.so

The above command should provide the architecture as ARM instead if you see it as i386 (or) i686 then the library is compiled for x86 architecture which can't be used on the Pi. You need to compile the library using the same cross toolchain first and then use it to link to your test application.

  • The poster (and also the error messages in his post) show that the file cannot be found. So it's not a problem with a different architecture at this point... – Uwe Plonus Mar 14 '18 at 15:10
  • According to the poster description the file is present in the directory so I thought of this possibility. – BalaC Mar 14 '18 at 15:16
  • 1
    It is compiled for ARM. Here is the output of file libfoo.so libCP5200.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, not stripped – Aniket Pawar Mar 15 '18 at 5:54
  • 1
    Also output of file ./test ./test: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=af019abeb87723b522d440f1c44ba2f85cd0356a, not stripped – Aniket Pawar Mar 15 '18 at 5:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.