Error while loading shared libraries

[AntiBNI]

Hi guys!

I’ve been trying to get around this problem for some time now without any luck.

I have some shared libraries that I am using with my application but I keep getting “error while loading shared libraries: <LibName.so>: cannot open shared object file: No such file or directory”

In the SDK that I am using it says to simply put all the so files in a folder and use the “export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/pi/project/lib/arm”

but I have tried that, I have tried:

• export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./home/pi/project/lib/arm (With a Dot on front of /)
• export LD_LIBRARY_PATH=/home/pi/project/lib/arm (Without the $LD_LIBRARY_PATH)
• Copying the libs to “usr/lib” then doing an ldconfig

I have also included the library dir to “LIBRARY_DIRS” on the make file

I have also added the LD_LIBRARY_PATH in the VisualGDB Project properties under debug settings, and also checked the “Run debugger as root with sudo”

None of the solutions I have found online works and I’m running out of ideas.

Any help will be greatly appreciated, Thanks!!

 

[AntiBNI]

I forgot to mention I am using Raspberry Pi 2 as the build system

[support]

Hi,

Normally specifying the path in LD_LIBRARY_PATH in VisualGDB Project Properties should solve the problem. If this does not work, please try setting it manually:

1. Connect to your Raspberry Pi via SmarTTY
2. Run ‘export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/pi/project/lib/arm’
3. Try running your executable
4. If it does not work, run ‘ldd <executable name>’ and check for messages about missing libraries

Most likely you are missing some other dependencies (libraries required by other libraries) or have some invalid symlinks somewhere.

[AntiBNI]

I didn’t know about ldd command so thanks for that, It’s very helpful.

 

I did run it manually and tried the ldd command but still.. It will show the normal linux libraries like libgcc_s.so.1 and such but all my 5 libraries from the SDK say ‘SDKLibraryName.so => not found’

I wonder why it doesn’t find the lib when executing while It finds it compiling.

• This reply was modified 9 years, 1 month ago by AntiBNI.

[support]

Hi,

The compiler uses a different path from linking. In fact, if you have specified relative paths to the libraries and not used the -L<directory> -l<library name>, the linker may hardcode the relative path in the executable leading to strange errors. We could help you fix this if you could share your linker command line, the exact LD_LIBRARY_PATH, the exact location of one of the libraries and the matching output from LDD.

[pedley]

I was having an identical problem using a cross-compiler under Win7 and executing on a Pi. I am trying to link to boost libraries in directory /usr/boost_1_59_0/lib. The minimal test program consists of a ‘local’ shared library DpLog.so and a main program LogTest. There does not appear to be a problem linking to the test library – just the Boost ones.

[I submitted another question without spotting this one. It does not seem to have appeared on the forum. If it does, apologies for the duplicate].

Following the advice above, on the Pi, I found that the LD_LIBRARY_PATH was empty and ldd LogTest and ldd DpLog.so found all the standard libraries but not Boost. So I set LD_LIBRARY_PATH to ‘:/usr/boost_1_59_0/lib’ and ran the program on the Pi without problem (/tmp/LogTest).

However, when I again tried to debug from vgdb, I still had the error:

‘Remote debugging from host 192.168.1.10

/tmp/MyProg: error while loading shared libraries: libboost_log.so.1.59.0: cannot open shared object file: No such file or directory’

Checked that LD_LIBRARY_PATH was still set correctly on the Pi – it was and the program still ran OK from the Pi command line.

 

This seems very strange to me, as the VGDB error seems to be coming from an identical environment to that which works perfectly when run from the Pi.

I attach the various outputs and shall be very grateful for any advice.

 

### Value of LD_LIBRARY_PATH (having been set on the Pi)
pi@RaspberryPi /tmp $ echo $LD_LIBRARY_PATH
:/usr/boost_1_59_0/lib

### ldd on the main program
pi@RaspberryPi /tmp $ ldd ./LogTest
        linux-vdso.so.1 (0x7ef44000)
        /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76fa7000)
        DpLog.so => /tmp/./DpLog.so (0x76f96000)
        libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76ea8000)
        libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76e2d000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76e00000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76cc3000)
        libboost_log.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_log.so.1.59.0 (0x76c21000)
        libboost_chrono.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_chrono.so.1.59.0 (0x76c0b000)
        libboost_thread.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_thread.so.1.59.0 (0x76be1000)
        libboost_date_time.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_date_time.so.1.59.0 (0x76bc2000)
        libboost_filesystem.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_filesystem.so.1.59.0 (0x76b9e000)
        libboost_system.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_system.so.1.59.0 (0x76b8b000)
        libboost_regex.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_regex.so.1.59.0 (0x76ab9000)
        /lib/ld-linux-armhf.so.3 (0x54b0a000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76aa2000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76a7a000)

### ldd on the test shared library
pi@RaspberryPi /tmp $ ldd ./DpLog.so
        linux-vdso.so.1 (0x7ef77000)
        /usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76fba000)
        libboost_log.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_log.so.1.59.0 (0x76f18000)
        libboost_chrono.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_chrono.so.1.59.0 (0x76f02000)
        libboost_thread.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_thread.so.1.59.0 (0x76ed8000)
        libboost_date_time.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_date_time.so.1.59.0 (0x76eb9000)
        libboost_filesystem.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_filesystem.so.1.59.0 (0x76e95000)
        libboost_system.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_system.so.1.59.0 (0x76e83000)
        libboost_regex.so.1.59.0 => /usr/boost_1_59_0/lib/libboost_regex.so.1.59.0 (0x76db1000)
        libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76cc3000)
        libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76c48000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76c1b000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76add000)
        librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76ac6000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76a9e000)
        /lib/ld-linux-armhf.so.3 (0x54ba8000)

### This is the successful run of the test program from the command line
pi@RaspberryPi /tmp $ ./LogTest
Hello, World!
DpLogTest: 1

### Output from the cross-compiler build
1>—— Rebuild All started: Project: DpLog, Configuration: Debug Win32 ——
1>Build started 28/10/2015 17:21:38.
1>Rebuild:
1>  VisualGDB: Run “cmd.exe /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug clean” in directory “C:\Dev\Cpp\Test\LogTest\DpLog” on local computer
1>  cmd /C del /S /Q Debug
1>  Deleted file – C:\Dev\Cpp\Test\LogTest\DpLog\Debug\DpLog.dep
1>  C:\Dev\Cpp\Test\LogTest\DpLog\Debug\DpLog.log
1>  The process cannot access the file because it is being used by another process.
1>  Deleted file – C:\Dev\Cpp\Test\LogTest\DpLog\Debug\DpLog.o
1>  Deleted file – C:\Dev\Cpp\Test\LogTest\DpLog\Debug\DpLog.so
1>  VisualGDB: Run “cmd.exe /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug” in directory “C:\Dev\Cpp\Test\LogTest\DpLog” on local computer
1>  C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -ggdb -ffunction-sections -O0 -std=c++11  -I=/usr/boost_1_59_0 -DDEBUG  -fPIC -c DpLog.cpp -o Debug/DpLog.o -MD -MF Debug/DpLog.dep
1>  C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -shared -o Debug/DpLog.so -Wl,-gc-sections   -L=/usr/boost_1_59_0/lib -Wl,–start-group Debug/DpLog.o -lboost_log -lboost_chrono -lboost_thread -lboost_date_time -lboost_filesystem -lboost_system -lboost_regex  -Wl,–rpath=’$ORIGIN’  -Wl,-soname,DpLog.so  -Wl,–end-group
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.57
2>—— Rebuild All started: Project: LogTest, Configuration: Debug Win32 ——
2>Build started 28/10/2015 17:21:39.
2>Rebuild:
2>  VisualGDB: Run “cmd.exe /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug clean” in directory “C:\Dev\Cpp\Test\LogTest\LogTest” on local computer
2>  cmd /C del /S /Q Debug
2>  Deleted file – C:\Dev\Cpp\Test\LogTest\LogTest\Debug\LogTest
2>  Deleted file – C:\Dev\Cpp\Test\LogTest\LogTest\Debug\LogTest.dep
2>  C:\Dev\Cpp\Test\LogTest\LogTest\Debug\LogTest.log
2>  The process cannot access the file because it is being used by another process.
2>  Deleted file – C:\Dev\Cpp\Test\LogTest\LogTest\Debug\LogTest.o
2>  VisualGDB: Run “cmd.exe /c “C:\Pi\Toolchain\bin\make.exe” CONFIG=Debug” in directory “C:\Dev\Cpp\Test\LogTest\LogTest” on local computer
2>  C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -ggdb -ffunction-sections -O0  -I../DpLog -DDEBUG  -c LogTest.cpp -o Debug/LogTest.o -MD -MF Debug/LogTest.dep
2>  C:/Pi/Toolchain/bin/arm-linux-gnueabihf-g++.exe -o Debug/LogTest -Wl,-gc-sections   -L=/usr/boost_1_59_0/lib -Wl,–start-group Debug/LogTest.o  ../DpLog/Debug/DpLog.so -Wl,–rpath=’$ORIGIN’ -Wl,–rpath=’$ORIGIN/../../DpLog/Debug/’  -Wl,–end-group
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_log.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_chrono.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_thread.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_date_time.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_filesystem.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_system.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>c:/pi/toolchain/bin/../lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/bin/ld.exe : warning : libboost_regex.so.1.59.0, needed by ../DpLog/Debug/DpLog.so, not found (try using -rpath or -rpath-link)
2>
2>Build succeeded.
2>
2>Time Elapsed 00:00:00.69
========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========
### Output from the debug session started from VisualGDB
Process /tmp/LogTest created; pid = 3524
Listening on port 2000
Remote debugging from host 192.168.1.10
/tmp/LogTest: error while loading shared libraries: libboost_log.so.1.59.0: cannot open shared object file: No such file or directory

Child exited with status 127
GDBserver exiting

 

[support]

Hi,

Could you try replacing the contents of the main source file with the following:

#include <stdio.h>
#include <stdlib.h>

int main()
{
    printf(">%s<\n", getenv("LD_LIBRARY_PATH"));
}

Does it show the correct LD_LIBRARY_PATH when you debug it from VisualGDB?

[AntiBNI]

Bazis,

Sorry for the delay on the answer.

 

Here is the Makefile and dump form the debuger an application:

Makefile:

#Generated by VisualGDB (http://visualgdb.com)
#DO NOT EDIT THIS FILE MANUALLY UNLESS YOU ABSOLUTELY NEED TO
#USE VISUALGDB PROJECT PROPERTIES DIALOG INSTEAD

BINARYDIR := Debug

#Toolchain
CC := gcc
CXX := g++
LD := $(CXX)
AR := ar
OBJCOPY := objcopy

#Additional flags
PREPROCESSOR_MACROS := DEBUG
INCLUDE_DIRS := /home/pi/BioFinger/inc/arm
LIBRARY_DIRS := /home/pi/BioFinger/lib/arm
LIBRARY_NAMES := fbiocpsb fbio4cap fbio4com fbio4bio fbio4smat
ADDITIONAL_LINKER_INPUTS :=
MACOS_FRAMEWORKS :=
LINUX_PACKAGES :=

CFLAGS := -ggdb -ffunction-sections -O2 -w -DUNIX -std=c99 -fsigned-char
CXXFLAGS := -ggdb -ffunction-sections -O2 -w -DUNIX -std=c99 -fsigned-char
ASFLAGS :=
LDFLAGS := -Wl,-gc-sections
COMMONFLAGS :=
LINKER_SCRIPT :=

START_GROUP := -Wl,--start-group
END_GROUP := -Wl,--end-group

#Additional options detected from testing the toolchain
IS_LINUX_PROJECT := 1

 

===========================Debug Log =================================

1>—— Build started: Project: BioFingerServer, Configuration: Debug Win32 ——
1>VisualGDB : warning : Found a source file with spaces in the path: “C:\Users\Dev\Documents\Visual Studio 2015\Projects\BioFingerServer\BioFingerServer\BioFingerServer.cpp”. If the build fails, please rename/move it.
1> VisualGDB: Sending 14 updated source files to build machine…
1> VisualGDB: Run “make CONFIG=Debug” in directory “/tmp/VisualGDB/c/Users/Dev/Documents/Visual Studio 2015/Projects/BioFingerServer/BioFingerServer” on pi@192.168.2.105 (SSH)
1> g++ -ggdb -ffunction-sections -O2 -w -DUNIX -std=c99 -fsigned-char -L/home/pi/BioFinger/lib/arm -I/home/pi/BioFinger/inc/arm -DDEBUG -c BioFingerServer.cpp -o Debug/BioFingerServer.o -MD -MF Debug/BioFingerServer.dep
1> g++ -ggdb -ffunction-sections -O2 -w -DUNIX -std=c99 -fsigned-char -L/home/pi/BioFinger/lib/arm -I/home/pi/BioFinger/inc/arm -DDEBUG -c FingerWrapper.cpp -o Debug/FingerWrapper.o -MD -MF Debug/FingerWrapper.dep
1> g++ -o Debug/BioFingerServer -Wl,-gc-sections -L/home/pi/BioFinger/lib/arm -Wl,–start-group Debug/BioFingerServer.o Debug/FingerWrapper.o -lfbiocpsb -lfbio4cap -lfbio4com -lfbio4bio -lfbio4smat -Wl,–rpath=’$ORIGIN’ -Wl,–end-group
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

 

 

======and application output======

/tmp/VisualGDB/c/Users/Dev/Documents/Visual Studio 2015/Projects/FingerScanServer/FingerScanServer/Debug/FingerScanServer: error while loading shared libraries: libfbiocpsb.so: cannot open shared object file: No such file or directory

 

 

what I did is re-image the Pi and tried compiling without messing with the  “LD_LIBRARY_PATH” variable in linux but still doesn’t work.

The full LD_LIBRARY_PATH I’m trying to use is “/home/pi/BioFinger/lib/arm”

Let me know if you need more info and Thanks, your help is hugely appreciated!

• This reply was modified 9 years ago by AntiBNI.
• This reply was modified 9 years ago by AntiBNI.

[AntiBNI]

I also, tried a file command on the libraries and they all output “ELF 32-bit LSB shared object,ARM,version 1 (SYSV),dynamically linked, stripped” hope that is of any help.

[pedley]

Hi Bazis,

Thanks for your reply.

No, this prints “/usr/lib/boost_1_57_0/stage/lib”. I have no idea where it gets this from – not even from the old toolchain (I updated from Wheezy to Jessie but the version of Boost on the previous disk was still 1.59). No such directory exists on the PC under ‘sysroot’. If I query the Pi both before and after running the program, it shows LD_LIBRARY_PATH as blank. So presumably VGDB is setting LD_LIBRARY_PATH (to the unhelpful value) immediately before the program runs and restoring the previous value immediately afterwards.

I have tried setting LD_LIBRARY_PATH under ‘Debug Settings’ to both ‘/usr/boost_1_59_0/lib’ and ‘$LD_LIBRARY_PATH:/usr/boost_1_59_0/lib’ but it seems that both are ignored.

If I set the correct LD_LIBRARY_PATH variable directly on the Pi, it is correctly reported:
pi@RaspberryPi /tmp $ export LD_LIBRARY_PATH=/usr/boost_1_59_0/lib
pi@RaspberryPi /tmp $ echo $LD_LIBRARY_PATH
/usr/boost_1_59_0/lib
pi@RaspberryPi /tmp $ ./LogTest
/usr/boost_1_59_0/lib
 So the problem appears to be that VGDB is setting the environment variable to an unknown (probably historical) value and I can see no way of correcting this. Any further ideas, please?

Best Regards,

David

[AntiBNI]

Pedley,

for what ARM version is your shared object compiled for? I just found out that my Library is compiled for ARMV7 and since I’m running Raspbian which is compiled for ARMv6, That meant I had an ARMv6 distro with an ARMV7 Kernel. That might be one of the problems I am getting.

I’m right now installing Arch Linux, which is full ARMV7 and see if that fixes my issue.

I have read hundreds of articles and looks like a simple LD_LIBRARY_PATH assignment with the path of the lib will make the linker first look at that custom path before any other default path, so that makes me think something is off somewhere.

 

Is what I just said a valid statement Bazis??

 

 

 

[AntiBNI]

YES!!!!WOHOOO

It was exactly what I said.

I will explain what I did because It might help some one in the internet.

When I tried the “readelf” command against the shared object “.so” file, It showed me that It was compiled for ARMv7 and since I was running Raspbian compiled for ARMv6, the ldd  (<i>List Dynamic Dependencies) </i>will not find it, Even tho you have specified the correct LD_LIBRARY_PATH and it will tell you that the file could not be found for some odd reason.

 

So, After installing a full ARMv7 distro like ArchLinux I was able to successfully assign the “.so” library path to “LD_LIBRARY_PATH and run ldd against the binary and see that the ldd can now see and link the “.so” file as a dependency.

Thanks a lot for your time and knowledge Bazis, I really appreciate it!!

[pedley]

Thanks for your suggestion, AntiBNI. However, I don’t think it applies in my case. I built the Boost libraries with the compiler that came with the Jessie distro and am using that same compiler to build the programs. Admittedly, there could be an inconsistency with the cross-compiler loaded to the PC (identical version) but how could one tell?

I think I know where the LD_LIBRARY_PATH that VGDB uses came from. When I was evaluating VGDB, I used a Wheezy distro and Boost 1.57 was presumably preloaded in that location. I installed version 1.59 at that stage but may originally have reference v1.57 and it somehow stuck in VGDB’s memory. I have subsequently changed to Jessie with a later version of the compiler, loaded and re-compiled Boost v1.59 and copied/synced the toolchain on to the PC.

I have managed to make things work with a hack. I created a new directory on the Pi (/usr/lib/boost_1_57_0/stage/lib – where LD_LIBRARY_PATH thinks the libraries should be) and copied them all from (/usr/boost_1_59_0/lib – the correct location). Thus I have two identical copies, one flagged with an incorrect version number. The second is used by the compiler/linker on the PC (via sync) and the first is used for dynamic linking on execution.

This is very unsatisfactory and is certainly not a “solution”. However, it allows me to make some progress with development before a solution emerges.

Do you have any further suggestions, please, Bazis?

• This reply was modified 9 years ago by support.

[MartinBonner]

What it means by “File not found” is not that it can’t find your .so, it means that it can’t find the loader to load an ARMv7 library on an ARMv6 kernel.  You can get the same problem when you try and run a 32-bit exe on a 64 bit Linux – the exe is there, but the exec call fails with “File not found”.

[pedley]

That seems to have been AntiBNI’s problem but is not the answer to mine.

In my case, if I simply copy the libraries to the directory which VGDB sets LD_LIBRARY_PATH to (incorrectly and ignoring project settings), then everything works fine. So it doesn’t appear to be a loader issue – just being told by VGDB to look in the wrong place.

[Author]

Posts