I'm writing two C programs. One of them uses library libnsd.so. I compile two C programs using makefile which looks like this:
CC=gcc
CFLAGS= -Wall -g -O -fPIC
RM= rm
HLAV=main
HLAVO=main.o
all:lib $(HLAV)
cc c2.c -o c2
main: $(HLAVO)
$(CC) -L. -o $(HLAV) $(HLAVO) -lnsd
lib: libnsd.so
libnsd.so: nsd.o nd.o
$(CC) -shared $< -o $#
nsd.o: nsd.c nsd.h nd.h
nd.o: nd.c nsd.h nd.h
clean:
$(RM) -rf *.o *.so main
When I try to run an aplication I get an error:
error while loading shared libraries: libnsd.so: cannot open shared
object file: No such file or directory
Anyone knows how to solve it?
The error msg means your program can't find the dynamic library libnsd.so.
You need to find the library path from your system.
If the lib is not on the regular path, I suggest put it on the regular path.
whereis libnsd.so
mv your_dir/libnsd.so /usr/local/lib
Note: If the library is does not exist on your system, you should install it first.
Then, use ldconfig to write the path in the config file:
sudo echo "/usr/local/lib" >> /etc/ld.so.conf
sudo ldconfig
Or if you don't have root priviledge in your workstation, you can simply change user environment path:
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
Related
I am trying to create a shared library that is to be linked against OpenSSL-1.0.2p which depends on libssl1.0. The installed version of OpenSSL on my ubuntu bionic machine is however OpenSSL-1.1.1 which internally uses libssl1.1.
Since I do not wish to install OpenSSL-1.0 system-wide, I downloaded and compiled it separately installing it into a folder inside my home directory.
I wish to use this location against which I would want my shared library to link. Here is the Makefile for the shared library that I am trying to create:
APPBASE=/home/AB/Documents/APP/APP_2.17.0
OPENSSL1.0.2p_INSTALL_LOC=/home/AB/Documents/APP/OpenSSL-1.0.2p-installation
CC=gcc
#CFLAGS= -Wall -g -O -fPIC
CFLAGS= -Wall -g -O -static
RM= rm -f
.PHONY: all clean
src=$(wildcard *Generic/*.c *Linux/*.c)
$(info source=$(src))
#we use the custom compiled openssl version
#and NOT the one available on the system
#INC=-I/usr/include/openssl
INC+=-I$(OPENSSL1.0.2p_INSTALL_LOC)/include/openssl
INC+=$(foreach d,$(incdir),-I$d)
$(info includes=$(INC))
LIB=-L$(OPENSSL1.0.2p_INSTALL_LOC)/lib
LIB+=-l:libssl.a -l:libcrypto.a
# looks like we need this for proper static linking of libc
LIB+= -static-libgcc
$(info links=$(LIB))
obj=$(src:.c=.o)
#all: libAPP.so
all: libAPP.a
clean:
$(RM) *.o *.so
$(shell find $(APPBASE) -type f -iname "*.o" -exec rm -rf {} \;)
.c.o:
${CC} ${CFLAGS} $(INC) -c $< -o $#
#${CC} ${CFLAGS} $(INC) -c $< -o $#
libAPP.a: $(obj)
#ar rcs $# $^
#$(LINK.c) -shared $^ -o $#
However, make reports that the header files being included are from the system's openssl installation and hence the compile is failing (since it is expecting OpenSSL-1.0.2p). Here's a sample:
In file included from /usr/include/openssl/e_os2.h:13:0,
from /usr/include/openssl/bio.h:13,
from /usr/include/openssl/x509v3.h:13,
.... (source file 1)
gcc -static -Wall -g -O -fPIC -I/home/AB/Documents/APP/OpenSSL-1.0.2p-installation/include/openssl -I*/path/to/app/include1* -I*/path/to/app/include2* -c */path/to/src1* -L/home/AB/Documents/APP/OpenSSL-1.0.2p-installation/lib -lssl -lcrypto
sr1.c: In function ‘Get_CACertificates’: warning: implicit declaration of function ‘CRYPTO_w_lock’; did you mean ‘CRYPTO_zalloc’? [-Wimplicit-function-declaration]
CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
^~~~~~~~~~~~~
CRYPTO_zalloc
CRYPTO_w_lock is a macro which is no longer present in the latest version of crypto.h (OpenSSL-1.1) which makes it clear that my application is still looking at the system version of OpenSSL.
Within my source files, I am including the SSL header files like so:
#include <openssl/bio.h>
#include <openssl/ssl.h>
#include <openssl/err.h>
Although angular braces are supposed to tell the compiler to look into the system's header files, doesn't the -L on the command line as well as the -I flags force it to look for them in the said directories before looking at the system files?
I do have a crypto.h file in the custom install location for OpenSSL but the compiler seems to be ignore it for some reason
ab#ab1-pc:/home/AB/Documents/APP/OpenSSL-1.0.2p-installation$ find . -iname "crypto.h"
./include/openssl/crypto.h
What am I missing here?
UPDATE 1: As suggested by Darren, removed the trailing openssl so now my include path is
INC+=-I$(OPENSSL1.0.2p_INSTALL_LOC)/include and voila I can see the shared library getting created. However when I try to find references to ssl within this newly minted shared library, I see that I have 87 entries (which includes ALL symbols having ssl as part of their name)
ab#ab1-pc:~/Documents/AB/APP_2.17.0$ nm libAPP.so | grep -i "ssl" | wc -l
87
whereas listing only the global symbols from libssl.a tells me it has 1113 globally defined symbols.
ab#ab1-pc:~/Documents/AB/APP_2.17.0$ nm -g ../OpenSSL-1.0.2p-installation/lib/libssl.a | grep -i "ssl" | wc -l
1113
Shouldn't the former count be MORE than the latter?? Has it got something to do with the fact that my 'app' is a shared library? Even then shouldn't it pull in ALL the symbols (at least the global ones) from any static libraries it links against??
UPDATE 2: Now apparently since I was facing issues with SSL symbols, I switched to creating a static library so made changes to the makefile accordingly.
In this line:
INC+=-I$(OPENSSL1.0.2p_INSTALL_LOC)/include/openssl
... try changing it to:
INC+=-I$(OPENSSL1.0.2p_INSTALL_LOC)/include
... i.e., without the 'openssl' part.
Your includes, e.g.,
#include <openssl/bio.h>
#include <openssl/ssl.h>
#include <openssl/err.h>
... expect directory search paths to terminate on the 'include/', not on the 'openssl'.
I have the following Makefile:
OBJ=main.o other.o other1.o other2.o
LINKDIVSUF=-L libdivsufsort-master/build/lib/ -ldivsufsort64 -Wl,-R libdivsufsort-master/build/lib/
INCDIVSUF=-I libdivsufsort-master/build/include -ldivsufsort64
EXE=program
COMPFLAGS=-MMD -fopenmp -std=c++17 -O3
CXX=g++
$(EXE):$(OBJ)
$(CXX) $(COMPFLAGS) $(OBJ) -o $(EXE) $(LINKDIVSUF) -lz -lboost_regex -lboost_program_options
%.o: %.cpp
$(CXX) $(COMPFLAGS) $(INCDIVSUF) -c $<
-include $(OBJ:.o=.d)
The program links to a dynamic library, libdivsufsort64.so.3, located from the build directory at ./libdivsufsort-master/build/lib/.
Use of -Wl,-R libdivsufsort-master/build/lib/is to avoid having to concatenate absolute/path/to/libdivsufsort-master/build/lib/ to LD_LIBRARY_PATH in order to run program. Indeed, when I make program
without -Wl, -R libdivsufsort-master/build/lib/, and without setting the LD_LIBRARY_PATH as mentioned and subsequently run program, I get the following error message:
./program: error while loading shared libraries: libdivsufsort64.so.3: cannot open shared object file: No such file or directory
With -Wl, -R libdivsufsort-master/build/lib/, program runs successfully with no alteration to LD_LIBRARY_PATH, but only when
I run program from the same directory in which it was built.
If I try to run program when compiled with -Wl, -R libdivsufsort-master/build/lib/ from any other directory, it fails to run, terminating with
the aforementioned error message.
How can I change the g++ compilation options (or anything else at compilation time) to enable program to run from
any directory whilst avoiding the need to alter LD_LIBRARY_PATH? The only "solution" I have found is to concatenate libdivsufsort-master/build/lib/ to LD_LIBRARY_PATH. By doing so, I can run program from any
directory, thus removing the need to compile with Wl,-R libdivsufsort-master/build/lib/, however, this of course requires the user of program to manually set their LD_LIBRARY_PATH, which I specifically want to avoid.
Solution
Reading this post that discusses the use of relative or absolute paths with -R (-rpath) I came up with this solution.
Append the following lines, such that the Makefile is now:
libdivsufsort_lib = $(addprefix $(shell pwd), /libdivsufsort-master/build/lib/)
libdivsufsort_include = $(addprefix $(shell pwd), /libdivsufsort-master/build/include/)
OBJ=main.o other.o other1.o other2.o
LINKDIVSUF=-L libdivsufsort-master/build/lib/ -ldivsufsort64 -Wl,-R libdivsufsort-master/build/lib/
INCDIVSUF=-I libdivsufsort-master/build/include -ldivsufsort64
EXE=program
COMPFLAGS=-MMD -fopenmp -std=c++17 -O3
CXX=g++
$(EXE):$(OBJ)
$(CXX) $(COMPFLAGS) $(OBJ) -o $(EXE) $(LINKDIVSUF) -lz -lboost_regex -lboost_program_options
%.o: %.cpp
$(CXX) $(COMPFLAGS) $(INCDIVSUF) -c $<
-include $(OBJ:.o=.d)
This avoids the use of $ORIGIN, to produce an absolute path to programs
directory, which is not supported on some systems. The two additional
lines produce the absolute path irrespective of the binary's location -
it just needs to kept in the build directory and compiled again if the build
directory moves. Importantly, program can now be called from outside the
build directory.
You need to use $ORIGIN with -Wl,-R to locate the library in relative path:
LINKDIVSUF = ... -Wl,-R,'$ORIGIN/libdivsufsort-master/build/lib'
I am having trouble compiling using make in windows 7 with gcc and the gsl library. It occurs only when using make (when I type the compilation commands manually into the cmd line, it compiles correctly). I found some posts where people had similar errors from gcc, but none where it worked when typing normally, but not when using make. The contents of my Makefile are shown below:
#Compiler
COMP=gcc
# Compiler Flags. -Wall turns on all warnings
FLAGS=-Wall
# GSL include file dir
INCLUDES=GnuWin32/include
# GSL Libraries directory
LIB=GnuWin32/lib
# Library Flags
LFLAGS=-lgsl -lgslcblas -lm
# Target Program
EXE=ex2.1.exe
# Dependencies needed for $(PROGRAM)
OBJ=ex2.1.o
# List of source files for objects
SRC=ex2.1.c
# List with types of files to be cleared by clean:
TRASH=*.exe *.o
# I/O files to be cleaned with 'very clean' target
#IOFILES= *.dat *.out *.csv *.mod
all: $(SRC) $(EXE)
$(EXE): $(OBJ)
$(COMP) -L/$(LIB) $(OBJ) $(LFLAGS) -o $(EXE)
$(OBJ): $(SRC)
$(COMP) -I/GnuWin32/include -c ex2.1.c
#$(COMP) -I/$(INCLUDES) -c $(SRC)
clean:
del $(TRASH)
If I type make with only the ex2.1.c present in the directory, I get the following output and error:
gcc -I/GnuWin32/include -c ex2.1.c
gcc: error: CreateProcess : No such file or directory
make: *** [ex2.1.o] Error 1
However, if I first type "gcc -I/GnuWiun32/include -c ex2.1.c", ex2.1.o is created successfully with no error. If then type 'make' I get the following output/error:
gcc -L/GnuWin32/lib ex2.1.o -lgsl -lgslcblas -lm -o ex2.1.exe
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin-0.dll not found
compilation terminated
make: *** [ex2.1.exe] Error 1
But if I manually enter "gcc -L/GnuWin32/lib ex2.1.o -lgsl -lgslcblas -lm -o ex2.1.exe" then the executable compiles and runs like it should, so the problem seems to be with how make is calling gcc? My PATH variable contains the paths to both make.exe as well as gcc.exe, so I am not sure what I do not set up correctly. Does anyone have an idea of what may be wrong? Thanks.
I'm using opencv on mac, every time I compile the program, I have to type:
g++ -I /usr/local/include -L /usr/local/lib main.cpp
What can I do to avoid typing -I and -L params?
Create a Makefile:
CXXFLAGS=-I /usr/local/include -O3 -DSOMETHING
LDFLAGS=-L /usr/local/lib
LIBS=-lwhatever
main: main.o
$(LD) -o $# $* $(LDFLAGS) $(LIBS)
main.o: main.cpp
And then just type make at the command prompt:
$ make
trojanfoe is almost right, but the makefile doesn't use the conventional names. If it did, it would be even simpler:
CXXFLAGS=-I /usr/local/include -O3 -DSOMETHING
LDFLAGS=-L /usr/local/lib
LDLIBS=-lwhatever
With that makefile you can just type make main and make will use its implicit rules for compiling a C++ file
I have a master Makefile that calls submakefiles inside directories.
Those submakefiles are generated by autotools starting from Makefile.am and configure.ac files.
The first target of the entire project is a shared library, while the others are executables that link against it (so there is a dependency in the main Makefile).
The problem is that I can only see the compilation output of the shared library, while the other projects are just printing warnings and errors (just stderr text, I believe).
I can't understand what is causing this behaviour since all the projects are called from the very same rule in the master Makefile and all the submakefiles are autogenerated from very seemed configuration files.
The snippet of master Makefile that compiles all the targets looks like this:
SUBDIRS = libMylib app1 app2 app3
$(SUBDIRS):
$(ECHO) "-> Building $#"
$(MAKE) -C $#
$(ECHO) "-> Build of $# finished."
The output of "libMylib" is like:
-> Building libMylib
libtool: compile: ppc-linux-gcc -DHAVE_CONFIG_H -I. -I/opt/ELDK/ppc_8xx/usr/include/ -I/opt/ELDK/ppc_8xx/include/ -Wall -std=gnu99 -O2 -MT libMylibF1.lo -MD -MP -MF .deps/libMylibF1.Tpo -c libMylibF1.c -fPIC -DPIC -o .libs/libMylibF1.o
...
libtool: link: ppc-linux-gcc -shared -fPIC -DPIC .libs/libMylibF1.o .libs/libMylibF2.o .libs/libMylibF3.o -Wl,-rpath -Wl,/opt/ELDK/ppc_8xx/lib -Wl,-rpath -Wl,/opt/ELDK/ppc_8xx/lib -lz -lpthread -O2 -Wl,-soname -Wl,libMylib.so.0 -o .libs/libMylib.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libMylib.so.0" && ln -s "libMylib.so.0.0.0" "libawmg.so.0")
libtool: link: (cd ".libs" && rm -f "libMylib.so" && ln -s "libMylib.so.0.0.0" "libMylib.so")
libtool: link: ( cd ".libs" && rm -f "libMylib.la" && ln -s "../libMylib.la" "libMylib.la" )
-> Build of libAwmg finished.
While the output of any "appN" is:
-> Building app1
app1F1.c: In function `app1F1Func1':
app1F1.c:161: warning: unused variable `varA'
app1F2.c:85: warning: `app1F2FuncX' defined but not used
-> Build of app1 finished.
Could anyone please help me?
EDIT:
I found out that I was able to see the compile stuff in "libMylib" because it is "libtoolized".
If I "libtoolize" another project, I can see the linker part of the output (libtool: link:...).
So, considering that make calls a shell (sh) for each line in the rule, that $(MAKE) equals to just "make" and, by default, make is verbose, why do the submake is not printing its output to stdout?
Which flags may be passed to it so that this happens?
It depends on the Makefiles in the sub directories. If, for example, you have a # in front of the compile commands in the app Makefiles, then they will not output the commands that were being run (also look for $(Q), which is used quite commonly when you want to enable/disable verboseness in makefiles). Alternatively, your make commands in the apps directories may be pushing stdout to some files (which would still allow you to see the warnings).
By the same token your library makefile may be incorrectly redirecting stderr elsewhere, which would explain why you don't see any error outputs on that (or it just doens't have any errors...)
Please post the build rules in the other directories (and all associated variable definitions) if you want more help.
Well, my master makefile includes another file that puts a .SILENT rule in.
I haven't noticed that until today.
Removing this rule makes everithing work as expected.
Oh my...