3

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
Aurora0001
  • 6,357
  • 3
  • 25
  • 39
Aniket Pawar
  • 31
  • 1
  • 6

2 Answers2

2

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.

Dmitry Grigoryev
  • 28,277
  • 6
  • 54
  • 147
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.

BalaC
  • 31
  • 1