In an auxiliary make file (named arch.make) which contains some libraries, I have wrote
FFLAGS=-g -O2
FPPFLAGS= -DMPI -DFC_HAVE_FLUSH -DFC_HAVE_ABORT
LDFLAGS=-L/export/apps/computer/lapack-3.2
LAPACK_LIBS=-llapack_LINUX
LIBS=$(LAPACK_LIBS)
Then, the Makefile contains
siesta: check-siesta what version $(MPI_INTERFACE) $(FDF) $(WXML) $(XMLPARSER) \
$(COMP_LIBS) $(ALL_OBJS)
$(FC) -o siesta \
$(LDFLAGS) $(ALL_OBJS) $(FDF) $(WXML) $(XMLPARSER) $(MPI_INTERFACE)\
$(COMP_LIBS) $(FoX_LIBS) $(LIBS)
Other variables are fine. Please note $(LIBS) and $(LDFLAGS) which are defined in arch.make.
That library file really exists according to
root#cluster:ObjPar# ls /export/apps/computer/lapack-3.2/lapack_LINUX.a -l
-rw-r--r-- 1 root root 18296682 Jul 10 20:50 /export/apps/computer/lapack-3.2/lapack_LINUX.a
However, the make process exits with the following error
......
dc_lapack.a `FoX/FoX-config --libs --wcml` -llapack_LINUX -lblas
/usr/bin/ld: cannot find -llapack_LINUX
collect2: ld returned 1 exit status
There are many lines before that but I omitted them.
What should I do?
The linker does not find a file called liblapack_LINUX.a or liblapack_LINUX.so. You will need to point to the file directly with
LAPACK_LIBS=/export/apps/computer/lapack-3.2/lapack_LINUX.a
The LDFLAGS variable may be removed.
You are likely to have to link the BLAS library in this way as well if the library is not called libblas.a or libblas.so. The order of linking may also be important. BLAS before LAPACK.
Related
I have some C++ code on an openSuse platform that I need to compile to be executed on a different linux-based target. Part of the code is a dynamic library libfoo.so. I compile everything with make and then copy the compiled executable prog together with the libfoo.so to the target. When I then run the executable, I get some errors indicating the libfoo could not be initialized. I've tried everything I could find to tell the executable where it can find the libfoo.so but I still get the error.
Could anybody tell me what I am doing wrong here? I feel like it could be an error in the Makefile.
I am very new to C++ and using Makefiles in general, and on top of it all, the target runs kind of a proprietary linux version, so I cannot provide much information about it. I do have the appropriate compiler for it though.
My directory structure on the openSuse platform:
|src
|--Foolib
|----foolib.h
|----libfoo.so
|--Otherlib
|----otherlib.h
|----otherlib.hpp
|---+OtherlibSrcDirectory
|--bar.cpp
|--bar.h
|--Makefile
Directory structure on the target:
|program
|--libfoo.so
|--prog
My Makefile:
LIBS = -LFoolib -lfoo
INC = -I OtherLib -I Foolib
CXXFLAGS += -lpthread -std=c++11 -D_GLIBCXX_USE_NANOSLEEP $(INC)
LDFLAGS = '-Wl,-rpath,$$ORIGIN'
SRC_FILES = bar.cpp
OBJ = $(SRC_FILES:%.cpp=%.o)
prog: $(OBJ)
$(CXX) $(CXXFLAGS) $(LDFLAGS) $(LIBS) -o $# $^
%.o: %.cpp
$(CXX) $(CXXFLAGS) $(LIBS) -c $<
Basically, bar.h includes Foolib/foolib.h as well as Otherlib/OtherlibSrcDirectory and bar.cpp includes bar.h. Then some functions from foolib.h are called in bar.cpp and they return error values. If necessary I can provide some more insights into the code but I'll leave it out for now to keep it a bit shorter.
Any help would be highly appreciated!
Found my mistake.
libfoo.so was already on the target machine and it was located in the correct folder (/lib). My program had been able to find it without problems.
My mistake: I executed my program on the target machine without root permissions.
Without root permissions, I am not allowed to initialize Foolib.
sudo ./prog fixed everything.
I have the following makefile and I would add the library "libcrypto.a" in a static way. I need to do this because the target system cannot install the openssl libraries.
# Environment
MKDIR=mkdir
CP=cp
GREP=grep
NM=x86_64-linux-nm
CCADMIN=CCadmin
RANLIB=x86_64-linux-ranlib
CC=x86_64-linux-gnu-gcc
CCC=x86_64-linux-gnu-g++
CXX=x86_64-linux-gnu-g++
FC=x86_64-linux-gfortran
AS=x86_64-linux-as
# Macros
CND_PLATFORM=GNU-Linux
CND_DLIB_EXT=so
CND_CONF=Release_x86_64
CND_DISTDIR=dist
CND_BUILDDIR=build
# Include project Makefile
include Makefile
# Object Directory
OBJECTDIR=${CND_BUILDDIR}/${CND_CONF}/${CND_PLATFORM}
# Object Files
OBJECTFILES= \
${OBJECTDIR}/_ext/7daaf93a/DtaCommand.o \
${OBJECTDIR}/_ext/7daaf93a/DtaDev.o \
${OBJECTDIR}/_ext/7daaf93a/DtaDevGeneric.o \
${OBJECTDIR}/_ext/7daaf93a/DtaDevOpal.o \
${OBJECTDIR}/_ext/7daaf93a/DtaDevOpal1.o \
${OBJECTDIR}/_ext/7daaf93a/DtaDevOpal2.o \
${OBJECTDIR}/_ext/7daaf93a/DtaHashPwd.o \
${OBJECTDIR}/_ext/7daaf93a/DtaHexDump.o \
${OBJECTDIR}/_ext/7daaf93a/DtaResponse.o \
${OBJECTDIR}/_ext/7daaf93a/DtaSession.o \
${OBJECTDIR}/_ext/b7b9df0c/blockwise.o \
${OBJECTDIR}/_ext/b7b9df0c/chash.o \
${OBJECTDIR}/_ext/b7b9df0c/hmac.o \
${OBJECTDIR}/_ext/b7b9df0c/pbkdf2.o \
${OBJECTDIR}/_ext/b7b9df0c/sha1.o \
${OBJECTDIR}/_ext/822bcbe5/DtaDevLinuxNvme.o \
${OBJECTDIR}/_ext/822bcbe5/DtaDevLinuxSata.o \
${OBJECTDIR}/_ext/822bcbe5/DtaDevOS.o \
${OBJECTDIR}/GetPassPhrase.o \
${OBJECTDIR}/LinuxPBA.o \
${OBJECTDIR}/UnlockSEDs.o
# C Compiler Flags
CFLAGS=-m64
# CC Compiler Flags
CCFLAGS=-m64
CXXFLAGS=-m64
# Link Libraries and Options
LDLIBSOPTIONS=-lcurses -ltinfo
# Build Targets
.build-conf: ${BUILD_SUBPROJECTS}
"${MAKE}" -f nbproject/Makefile-${CND_CONF}.mk ${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/linuxpba
${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/linuxpba: ${OBJECTFILES}
${MKDIR} -p ${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}
${LINK.cc} -o ${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/linuxpba ${OBJECTFILES} ${LDLIBSOPTIONS} -s
${OBJECTDIR}/_ext/7daaf93a/DtaCommand.o: ../Common/DtaCommand.cpp
${MKDIR} -p ${OBJECTDIR}/_ext/7daaf93a
${RM} "$#.d"
$(COMPILE.cc) -O2 -Werror -I../linux -I../Common -I../Common/pbkdf2 -std=c++11 -MMD -MP -MF "$#.d" -o ${OBJECTDIR}/_ext/7daaf93a/DtaCommand.o ../Common/DtaCommand.cpp
#...... SIMILAR FOR THE OTHER ELEMENTS OF "OBJECTDIR ......"
I tried to add to my "LDLIBSOPTIONS" several things but I don't find the correct way to do this, for example:
"-lcrypto" it links the library in a dynamic way (not good for my case)
"[absolute path]/libcrypto.a" it returns "libcrypto.a(dso_dlfcn.o): undefined reference to symbol 'dlclose##GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line".
"[absolute path]/libcrypto.a -ldl"libcrypto.a(evp_enc.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
Any suggestion ?
OpenSSL link lincrypto.a in a static way
...
"-lcrypto" it links the library in a dynamic way (not good for my case)
Use -l:libcrypto.a. It specifies the full name of the library. Below is from the LD(1) man page. See the part about :filename.
-l namespec
--library=namespec
Add the archive or object file specified by namespec to the list of
files to link. This option may be used any number of times. If
namespec is of the form :filename, ld will search the library path for
a file called filename, otherwise it will search the library path for
a file called libnamespec.a.
On systems which support shared libraries, ld may also search for
files other than libnamespec.a. Specifically, on ELF and SunOS
systems, ld will search a directory for a library called
libnamespec.so before searching for one called libnamespec.a. (By
convention, a .so extension indicates a shared library.) Note that
this behavior does not apply to :filename, which always specifies a
file called filename.
The linker will search an archive only once, at the location where it
is specified on the command line. If the archive defines a symbol
which was undefined in some object which appeared before the archive
on the command line, the linker will include the appropriate file(s)
from the archive. However, an undefined symbol in an object appearing
later on the command line will not cause the linker to search the
archive again.
See the -( option for a way to force the linker to search archives
multiple times.
You may list the same archive multiple times on the command line.
This type of archive searching is standard for Unix linkers. However,
if you are using ld on AIX, note that it is different from the
behaviour of the AIX linker.
"[absolute path]/libcrypto.a" it returns "libcrypto.a(dso_dlfcn.o): undefined reference to symbol 'dlclose##GLIBC_2.2.5' //lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line"
For this problem, add -ldl after libcrypto and libssl in your link command.
"[absolute path]/libcrypto.a -ldl"libcrypto.a(evp_enc.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
For this problem, see What does .rodata and -fPIC mean when compiling OpenSSL? and Compilation fails with “relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object”.
The short of it is, you need to configure OpenSSL with the shared option. If you don't want to build the shared libraries, the add -fPIC to CFLAGS. Also see Compilation and Installation on the OpenSSL wiki.
It looks like your libcrypto.a is not compiled as PIC (or at least as PIE), and your toolchain defaults to creating PIE-enabled executables. You probably have to link with a command like this:
gcc -fno-pie -no-pie … -Wl,-Bstatic -lcrypto -Wl,-Bdynamic -ldl -lpthread
Some parts of libcrypto depend on libdl and libpthread, so these libraries are required, too, but you must link them dynamically because they are part of glibc.
In my makefile, I have specified a library dependency as follows:
LDFLAGS := -l/home/karnivaurus/OpenCV-3.0.0/build/lib/libopencv_core.so
all: $(DYNAMIC_NAME)
$(DYNAMIC_NAME): $(OBJS) | $(LIB_BUILD_DIR)
# echo LD -o $#
$(Q)$(CXX) -shared -o $# $(OBJS) $(LINKFLAGS) $(LDFLAGS) $(DYNAMIC_FLAGS)
Now, if I run make all, I get the following error:
/usr/bin/ld: cannot find -l/home/karnivaurus/Libraries/OpenCV-3.0.0-RC1/build/lib/libopencv_core.so
However, in the directory /home/karnivaurus/Libraries/OpenCV-3.0.0-RC1/build/lib, there is definitely a file called libopencv_core.so. I have checked the spelling many times!
Are there any reasons why the linker cannot find this file, even though I have explicitly specified its exact location and passed that to the linker?
Thanks!
Either use -L for the library path and -lopencv_core:
LDFLAGS := -L /home/karnivaurus/OpenCV-3.0.0/build/lib/ -lopencv_core
or just include the full path to the .so file without -l.
LDFLAGS := /home/karnivaurus/OpenCV-3.0.0/build/lib/libopencv_core.so
I have a fortran code (pardiso_1.f) and it needs some libraries (BLAS, lapack and Pardiso libraries) to be compiled. When I try to compile it, I link libraries before compilation and I write this line in linux terminal:
gfortran pardiso_1.f -L/home/behnam/Pardiso -lpardiso412-GNU450-X86-64 -L/usr/lib -lblas -llapack -fopenmp
and it works perfectly.
However I have to run the code using makefile. I am so new in writing makefiles and I do not know how to do the linkage. I have written this makefile. could anyone help me to find out what is wrong with that?
FC = gfortran
OPT = -O2
PROGRAMS = pardiso_1
all: $(PROGRAMS)
FFLAGS = -fopenmp
#### BLAS, LAPACK and PTHREAD libraries
LBLAS = /usr/lib/
###location of pardiso file
LIBMKL = /home/behnam/PS2/
#### Series of libraries
LIBRARIES= -llapack -lblas -lpthread -lm -lpardiso412-GNU430-X86-64
PATHFC = /usr/bin/
nlace: ${PATHFC}${FC} ${OPT} ${FFLAGS} -I${PROGRAMS} -o nlace.exe \
-L${LIBMKL} -lpardiso412-GNU430-X86-64\
-L${LBLAS} ${LIBRARIES}
clean:
rm -f *.o *.exe fort.* *~ *.mod
veryclean: clean
rm -f *~ $(PROGRAMS)
The errors are:
behnam#meen-392430:~/testing$ make
make: Warning: File `Makefile' has modification time 23 s in the future
gfortran -fopenmp pardiso_1.f -o pardiso_1
/tmp/ccYNexaH.o: In function `MAIN__':
pardiso_1.f:(.text+0xb3): undefined reference to `pardisoinit_'
pardiso_1.f:(.text+0x2ae): undefined reference to `pardiso_chkmatrix_'
pardiso_1.f:(.text+0x36e): undefined reference to `pardiso_chkvec_'
pardiso_1.f:(.text+0x44c): undefined reference to `pardiso_printstats_'
pardiso_1.f:(.text+0x5ae): undefined reference to `pardiso_'
pardiso_1.f:(.text+0x860): undefined reference to `pardiso_'
pardiso_1.f:(.text+0xb78): undefined reference to `pardiso_'
pardiso_1.f:(.text+0xe00): undefined reference to `pardiso_'
collect2: ld returned 1 exit status
make: *** [pardiso_1] Error 1
Your makefile does not contain the -L/home/behnam/Pardiso part of your command line.
Your rule for PROGRAMS does not contain a recipe that includes the library calls. I presume you want something like your nlace rule, but right now, make is not calling any of your -L switches as part of its operation.
When compiling our project, we create several archives (static libraries), say liby.a and libz.a that each contains an object file defining a function y_function() and z_function(). Then, these archives are joined in a shared object, say libyz.so, that is one of our main distributable target.
g++ -fPIC -c -o y.o y.cpp
ar cr liby.a y.o
g++ -fPIC -c -o z.o z.cpp
ar cr libz.a z.o
g++ -shared -L. -ly -lz -o libyz.so
When using this shared object into the example program, say x.c, the link fails because of an undefined references to functions y_function() and z_function().
g++ x.o -L. -lyz -o xyz
It works however when I link the final executable directly with the archives (static libraries).
g++ x.o -L. -ly -lz -o xyz
My guess is that the object files contained in the archives are not linked into the shared library because they are not used in it. How to force inclusion?
Edit:
Inclusion can be forced using --whole-archive ld option. But if results in compilation errors:
g++ -shared '-Wl,--whole-archive' -L. -ly -lz -o libyz.so
/usr/lib/libc_nonshared.a(elf-init.oS): In function `__libc_csu_init':
(.text+0x1d): undefined reference to `__init_array_end'
/usr/bin/ld: /usr/lib/libc_nonshared.a(elf-init.oS): relocation R_X86_64_PC32 against undefined hidden symbol `__init_array_end' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
Any idea where this comes from?
You could try (ld(2)):
--whole-archive
For each archive mentioned on the command line after the --whole-archive option, include every object file in the
archive in the link, rather than searching the archive for the required object files. This is normally used to turn
an archive file into a shared library, forcing every object to be included in the resulting shared library. This
option may be used more than once.
(gcc -Wl,--whole-archive)
Plus, you should put -Wl,--no-whole-archive at the end of the library list. (as said by Dmitry Yudakov in the comment below)