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
2
  • foo.so looks suspicious... Normally libraries are called libfoo.so under linux
    – Uwe Plonus
    Mar 14, 2018 at 10:54
  • For naming convention i have written it as foo.so but in real its libfoo.so. Edited the question Mar 14, 2018 at 10:55

2 Answers 2

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.

7
  • 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 Mar 15, 2018 at 5:49
  • objdump -p libfoo.so | grep libfoo outputs libfoo.so: file format elf32-littlearm Mar 15, 2018 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. Mar 15, 2018 at 12:13
  • it outputs nothing @grigoryev Mar 15, 2018 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, 2018 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.

4
  • 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, 2018 at 15:10
  • According to the poster description the file is present in the directory so I thought of this possibility.
    – BalaC
    Mar 14, 2018 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 Mar 15, 2018 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 Mar 15, 2018 at 5:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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