Geek Answers Handbook

Makefile - cannot find shared library

I have a Makefile for a C ++ Linux project:

MODE ?= dbg DIR = ../../../../../somdir/$(MODE) SRC_FILES = a.cpp b.cpp H_FILES = ah LDFLAGS += -L$(DIR)/lib/linux '-Wl,-R$$ORIGIN' CPPFLAGS = -I$(DIR)/include LIBRARIES = -lsomeso ifeq (rel, $(MODE)) CFLAGS = -Wall -g -DNDEBUG else CFLAGS = -Wall -ansi -pedantic -Wconversion -g -DDEBUG -D_DEBUG endif sample: $(SRC_FILES) $(H_FILES) Makefile g++ $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) $(LIBRARIES) $(SRC_FILES) -o sample

when I run 'make', it builds the project without errors. but when I run the project, he complains that:

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

The path I give to DIR goes to the folder where the shared object is located (relative to where the makefile is located), and if that was the wrong path, why didn't it complain during the make process.

Does anyone know what I am missing?

Thanks Matt

+4
source share
5 answers
 LDFLAGS += -L$(DIR)/lib/linux '-Wl,-R$$ORIGIN'

The above should be:

 LDFLAGS += -L$(DIR)/lib/linux -Wl,-R$(DIR)/lib/linux '-Wl,-R$$ORIGIN'

That is, for each non-standard location of the -L dynamic library, the corresponding -Wl,-R must be specified. $ORIGIN needed to find dynamic libraries relative to an executable file, not sure if you need one.

People are often advised to use LD_LIBRARY_PATH . This is bad advice, in my opinion, because it complicates deployment.

+3
source

When the application starts, the location of libsomeso.so must be in the environment variable LD_LIBRARY_PATH . Try running a program like this:

 LD_LIBRARY_PATH="path_to_libsomeso_so:$LD_LIBRARY_PATH" myprogram

Here path_to_libsomeso_so is the full directory path where libsomeso.so is located and myprogram is the executable file of your program. Note that you must specify the path to the directory containing libsomeso.so , not the libsomeso.so file.

+2
source

The problem is not at compile time. Everything goes well. There is a runtime problem.

Indeed, your program is linked to a shared library of objects. Therefore, at runtime, you must load this file of shared objects. At compile time, you instruct the compiler where this file was with the -L flag.

For the runtime, you must set the environment variable LD_LIBRARY_PATH to point to the directory where your libsomeso.so file is libsomeso.so .

Alternatively, you can put this file in one of the standard directories in which these shared object files are found: /usr/local/lib , /usr/lib , /lib , but this should be what you will do for the final distributed version your library.

+1
source

As Maxim Yegorushkin said, LD_LIBRARY_PATH is a bad choice. Meanwhile, using the -L$(your lib path) -l$(your lib name) gcc / g ++ argument to link the shared library is not a good choice. Because after building exe, you must tell exe where the shared library directory is located. By default, the executable searches only the shared library in /usr/lib or /usr/local/lib . Although, you said makefile, where is the shared library when building the executable. But when you execute this exe file, they are different. However, a link to a static library does not have such a problem.

Thus, the best way to deal with your problem is to change the way you link your common shared file. Like this:

 DYNAMIC_LIB_DIR = ../lib (your lib path ,this is a example) OBJLIBS = xxx.so (your lib name) gcc/g++ -o exe_name sourcefile/object_file $(DYNAMIC_LIB_DIR)/$(OBJLIBS)
0
source

Refresh this dynamic library cache!

After adding the custom custom library to /usr/local/lib first check that /usr/local/lib is listed in /etc/ld.so.conf.d/libc.conf .

Then complete the update of the dynamic link library cache:

 $ sudo ldconfig
0
source

More articles:


All Articles