I have opencv3 installed through home-brew and pkg-config can find the linkers too by
pkg-config --cflags --libs opencv
the outputs contains -lopencv_core, but when I add that in Makefile like this
CC=clang++
CFLAGS= -Wall -g -std=c++0x
LFLAGS= -I/usr/local/Cellar/opencv3/3.2.0/include -I/usr/local/Cellar/opencv3/3.2.0/bin -I/usr/local/Cellar/opencv3/3.2.0/lib -lopencv_core
CFILES=blah.cpp
HFILES=blah.hpp
OFILES=blah.o
all: main
%.o: %.cpp $(HFILES)
$(CC) -c $(CFLAGS) $< -o $# $(LFLAGS)
main: $(OFILES) $(HFILES)
$(CC) $(CFLAGS) $(OFILES) -o main $(LFLAGS)
it says
ld: library not found for -lopencv_core
clang: error: linker command failed with exit code 1 (use -v to see invocation)
How should I link that to gcc?
Assuming you want CFLAGS to be the options for compilation and LFLAGS to
be the options for linkage, the settings:
CFLAGS= -Wall -g -std=c++0x
LFLAGS= -I/usr/local/Cellar/opencv3/3.2.0/include -I/usr/local/Cellar/opencv3/3.2.0/bin -I/usr/local/Cellar/opencv3/3.2.0/lib -lopencv_core
are confused.
The -I path option is meaningful for compilation and meaningless for linkage. It
tells the preprocessor to search in path for header files that you #include in
the source code. There will be header files in:
/usr/local/Cellar/opencv3/3.2.0/include
There will be no header files in:
/usr/local/Cellar/opencv3/3.2.0/bin
just executables, which are irrelevant to building your program. And there will be no header files in:
/usr/local/Cellar/opencv3/3.2.0/lib
just static and or dynamic libraries.
The library libopencv_core that linker can't find is presumably
in /usr/local/Cellar/opencv3/3.2.0/lib. The way to tell the
linker to search there for the library is:
-L/usr/local/Cellar/opencv3/3.2.0/lib -lopencv_core
So these settings make sense:
CFLAGS := -Wall -g -std=c++0x -I/usr/local/Cellar/opencv3/3.2.0/include
LFLAGS := -L/usr/local/Cellar/opencv3/3.2.0/lib -lopencv_core
However, to compile and link an opencv program you would probably be better
leaving it to pkg-config to get the options right:
CFLAGS := -Wall -g -std=c++0x $(shell pkg-config --cflags opencv)
LFLAGS := $(shell pkg-config --libs opencv)
The -l option looks in the usual places for the mentioned library. Where and what it looks varies by OS, which you didn't mention. Possibly it can be fixed by adding -L /usr/local/lib or some other path to where you know the libraries are.
Related
I have the following shared libraries:
libssl.so, libssl.so.1.1, libcurl.so, libcurl.so.4, libcurl.so.4.4.0, libcrypto.so, libcrypto.so.1.1.
All of the libraries are in the openssl folder.
My question is, how can I link version 1.1 of libssl? Is it done automatically?
I've tried the following:
g++ -c my_file_name.cpp -std=c++11 -w -fpermissive -lpthread --coverage $(INCLUDES) `pkg-config --cflags glib-2.0` `pkg-config --libs glib-2.0` -O0 -Lopenssl -lcrypto -lcurl -lssl
g++ my_file_name.o -o ex -std=c++11 -w -fpermissive -lpthread --coverage -lgtest -lgtest_main -lpthread `pkg-config --cflags glib-2.0` `pkg-config --libs glib-2.0` -O0 -Lopenssl -lcrypto -lcurl -lssl
But it seems that the link doesn't happen. As I still get errors like:
error: ‘X509_STORE_CTX_get0_chain’ was not declared in this scope
Later edit
nm libssl.so.1.1 | grep X509_STORE_CTX_get0_chain results in 0000000000218210 T X509_STORE_CTX_get0_chain. That would mean that the link that I've done does not happen.
It's worth mentioning that the error comes from a .c file included in the .cpp file.
Probably the libssl.so is a symbolic link to libssl.so.1.1 etc. etc.
The problem seems to be related to the missing implementation in one of these library of this function :X509_STORE_CTX_get0_chain.
Now you have to check if this symbol is defined in one of these library you link, or if you need to link someone else.
To check this you can execute the following command over each library:
nm libToCheck.so | grep X509_STORE_CTX_get0_chain
if no one have this symbol defined maybe you missing some library to link.
If exist, check the scope of the utilizzation of the function, it could not correspond to the scope declared in the library. Check the namespace or similar.
So I am using nvidia's deepstream sdk and trying to modify the makefile of one of the sample examples given as I wish to link and add my own libraries. This is the makefile being employed where I am setting the path of the CUSTOM_LIB to point to the location of my library. The issue is the project gets compiled successfully but during run time, its unable to find the custom library. I performed ldd on the executable generated and there also it was showing the library as 'not found'. I think it's something to do with rpath but I am not sure about that.
APP:= sample
TARGET_DEVICE = $(shell gcc -dumpmachine | cut -f1 -d -)
NVDS_VERSION:=4.0
LIB_INSTALL_DIR?=/opt/nvidia/deepstream/deepstream-$(NVDS_VERSION)/lib/
ifeq ($(TARGET_DEVICE),aarch64)
CFLAGS:= -DPLATFORM_TEGRA
endif
CUDA_VER:=10.0
CC:=g++
SRCS:= $(wildcard ../src/*.c)
#SRCS+= $(wildcard ../../apps-common/src/*.c)
#SRCS+=
INCS:= $(wildcard ../include/*.h)
PKGS:= gstreamer-1.0 gstreamer-video-1.0 x11 opencv
OBJS:= $(SRCS:.c=.o)
CFLAGS+= -I../include -I/usr/include -I$(CUSTOM_LIB)/include -I/usr/local/cuda-10.0/targets/aarch64-linux/include/ -I/usr/include/jsoncpp -DDS_VERSION_MINOR=0 -DDS_VERSION_MAJOR=4 -fpermissive -Wnarrowing
LIBS+= -L$(LIB_INSTALL_DIR) -L/usr/lib/aarch64-linux-gnu -L$(CUSTOM_LIB)/lib -L/usr/lib/aarch64-linux-gnu/ -lcurl -letlic -letolm -lssl -lcrypto -llogger -lpthread -lsqlite3 -ljsoncpp -lnvdsgst_meta -lnvbufsurface -lnvbufsurftransform -lnvds_meta -lnvdsgst_helper -lnvds_utils -lm -L/usr/local/cuda-$(CUDA_VER)/lib64/ -lcudart \
-lgstrtspserver-1.0 -Wl,-rpath,$(LIB_INSTALL_DIR)
CFLAGS+= `pkg-config --cflags $(PKGS)`
LIBS+= `pkg-config --libs $(PKGS)`
all: $(APP)
debug: CXXFLAGS += -DDEBUG -g
debug: CFLAGS += -DDEBUG -g
debug: $(APP)
%.o: %.c $(INCS) Makefile
$(CC) -c -o $# $(CFLAGS) $<
$(APP): $(OBJS) Makefile
$(CC) -o $(APP) $(OBJS) $(LIBS)
clean:
rm -rf $(OBJS) $(APP)
You need to set rpath to a colon-separated list of directories where your libraries are found. You only add LIB_INSTALL_DIR but not CUSTOM_LIB_DIR. Generally everything you pass to -L you need to pass to -rpath too, unless there is a specific reason not to. For example, if you are building a package that has more than a single library and you are going to install in a standard place like /usr/lib, you don't have to add the directory where libraries temporarily live to -rpath. If you are going to install to a non-standard directory, add that directory.
I am creating client-server application, using gRPC. So far I was not using TLS encryption. Now I want to enable it, and strangely I get this error. It seems, at least to me, that this is a linker error. What would be best ways to solve it?
CLion doesn't highlight anything, so I assumed everything was syntactically OK, but when compiling I got that error.
/usr/bin/ld: CMakeFiles/projectname.dir/main.cpp.o: in function `grpc::SslServerCredentials(grpc::SslServerCredentialsOptions const&)':
/home/username/projectname/third_party/grpc/include/grpcpp/security/server_credentials.h:60: undefined reference to `grpc_impl::SslServerCredentials(grpc::SslServerCredentialsOptions const&)'
collect2: error: ld returned 1 exit status
This is a makefile that I use to generate C++ code from gRPC specification:
HOST_SYSTEM = $(shell uname | cut -f 1 -d_)
SYSTEM ?= $(HOST_SYSTEM)
CXX = g++
CPPFLAGS += `pkg-config --cflags protobuf grpc`
CXXFLAGS += -std=c++11
ifeq ($(SYSTEM),Darwin)
LDFLAGS += -L/usr/local/lib `pkg-config --libs protobuf grpc++`\
-lgrpc++_reflection\
-ldl
else
LDFLAGS += -L/usr/local/lib `pkg-config --libs protobuf grpc++`\
-Wl,--no-as-needed -lgrpc++_reflection -Wl,--as-needed\
-ldl
endif
PROTOC = protoc
GRPC_CPP_PLUGIN = grpc_cpp_plugin
GRPC_CPP_PLUGIN_PATH ?= `which $(GRPC_CPP_PLUGIN)`
PROTOS_PATH = ./
vpath %.proto $(PROTOS_PATH)
%.grpc.pb.cc: %.proto
$(PROTOC) -I $(PROTOS_PATH) --grpc_out=. --plugin=protoc-gen-grpc=$(GRPC_CPP_PLUGIN_PATH) $<
%.pb.cc: %.proto
$(PROTOC) -I $(PROTOS_PATH) --cpp_out=. $<
clean:
rm -f *.o *.pb.cc *.pb.h
Then problem was solved like this:
I had to chage grpc++_unsecure to grpc++ under target_link_libraries in CMakeLists.txt cmake build configuration file.
I had forgotten/not thought about this at first.
target_link_libraries(bita_server
pqxx
sodium
protobuf::libprotobuf
# grpc++_unsecure
grpc++
SQLiteCpp
sqlite3
pthread
dl
${_PROTOBUF_LIBPROTOBUF}
)
In CMakeLists.txt under grpc folder, there are many target_link_libraries. which one to edit in order to include the change.
I'm doing some modifications to an existing project which is pretty big, so it's built with the autotools. The modifications involve the Ibex library, so I've added an #include "ibex.h" in one of the source files. The library is properly installed on my system, I have the following files:
/usr/local/lib/libibex.a
/usr/local/include/ibex/ibex.h
/usr/local/share/pkgconfig/ibex.pc
Results of the pkg-config commands:
$ pkg-config --libs ibex
-L/usr/local/lib -libex -lprim -lClp -lCoinUtils -lm
$ pkg-config --cflags ibex
-frounding-math -ffloat-store -I/usr/local/include -I/usr/local/include/ibex
The original Makefile.am corresponding to the compil unit I want to get to use ibex, is as follows:
noinst_LTLIBRARIES = liblrasolver.la
AM_CPPFLAGS=$(config_includedirs)
liblrasolver_la_SOURCES = LAVar.h LAVar.C Delta.h Delta.C LRASolver.h LRASolver.C LAArray.h LAArray.C LARow.h LARow.C LAColumn.h LAColumn.C
if WANT_LIBRARY
include_HEADERS = Delta.h LAArray.h LAColumn.h LARow.h LAVar.h LRASolver.h
endif
I modified it this way:
noinst_LTLIBRARIES = liblrasolver.la
AM_CPPFLAGS=$(config_includedirs) `pkg-config --cflags ibex`
AM_LDFLAGS=`pkg-config --libs ibex` -lblas -llapack
liblrasolver_la_SOURCES = LAVar.h LAVar.C Delta.h Delta.C LRASolver.h LRASolver.C LAArray.h LAArray.C LARow.h LARow.C LAColumn.h LAColumn.C
if WANT_LIBRARY
include_HEADERS = Delta.h LAArray.h LAColumn.h LARow.h LAVar.h LRASolver.h
endif
Came to this modification by looking into the generic Makefile provided along with ibex sources to compile ibex projects:
SRCS=$(wildcard *.cpp)
BINS=$(SRCS:.cpp=)
CXXFLAGS := $(shell pkg-config --cflags ibex)
LIBS := $(shell pkg-config --libs ibex) -lblas -llapack
ifeq ($(DEBUG), yes)
CXXFLAGS := $(CXXFLAGS) -O0 -g -pg -Wall -frounding-math
else
CXXFLAGS := $(CXXFLAGS) -O3 -DNDEBUG -Wno-deprecated -frounding-math
endif
all: $(BINS)
% : %.cpp
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -o $# $< $(LIBS)
clean:
rm -f $(BINS)
Ok, autoreconf works, as well as ./configure (though its output never talks about "ibex" which I find suspicious already). But make fails. Doesn't find the header:
../../../src/tsolvers/lrasolver/LRASolver.h:38:18: fatal error: ibex.h: No such file or directory
#include "ibex.h"
You're not using pkg-config correctly. You should use the PKG_CHECK_MODULES macro, see for reference https://autotools.io/pkgconfig/pkg_check_modules.html (full disclosure: I wrote that.)
You're also using AM_LDFLAGS incorrectly since libraries are not ldflags. You should use _LIBADD.
So I'm having trouble compiling my application which is using yaml-cpp
I'm including "yaml.h" in my source files (just like the examples in the yaml-cpp wiki) but when I try compiling the application I get the following error:
g++ -c -o entityresourcemanager.o entityresourcemanager.cpp
entityresourcemanager.cpp:2:18: error: yaml.h: No such file or directory
make: *** [entityresourcemanager.o] Error 1
my makefile looks like this:
CC = g++
CFLAGS = -Wall
APPNAME = game
UNAME = uname
OBJECTS := $(patsubst %.cpp,%.o,$(wildcard *.cpp))
mac: $(OBJECTS)
$(CC) `pkg-config --cflags --libs sdl` `pkg-config --cflags --libs yaml-cpp` $(CFLAGS) -o $(APPNAME) $(OBJECTS)
pkg-config --cflags --libs yaml-cpp returns:
-I/usr/local/include/yaml-cpp -L/usr/local/lib -lyaml-cpp
and yaml.h is indeed located in /usr/local/include/yaml-cpp
Any idea what I could do?
Thanks
Your default target is "mac" and you have rule how to build it. It depends on object files and you do not have any rules how to build those, so make is using its implicit rules. Those rules do just that:
g++ -c -o entityresourcemanager.o entityresourcemanager.cpp
As you can see there is no -I/usr/local/... part here.
The easiest way to fix that is to change CPPFLAGS and LDFLAGS value globally:
YAML_CFLAGS := $(shell pkg-config --cflags yaml-cpp)
YAML_LDFLAGS := $(shell pkg-config --libs yaml-cpp)
SDL_CFLAGS := $(shell pkg-config --cflags sdl)
SDL_LDFLAGS := $(shell pkg-config --libs sdl)
CPPFLAGS += $(YAML_CFLAGS) $(SDL_CFLAGS)
LDFLAGS += $(YAML_LDFLAGS) $(SDL_LDFLAGS)
mac: $(OBJECTS)
$(CXX) -o $(APPNAME) $(OBJECTS) $(LDFLAGS)
CPPFLAGS value is used by implicit rules that build object files from cpp files, so now compiler should find yaml headers.
Edit:
LDFLAGS probably should go after OBJECTS
Don't you mismatch your include directory?
-I/usr/local/include
instead of
-I/usr/local/include/yaml-cpp