I'm running make and ld will not find libraries that I have verified to exist using dnf provides '*/libpthread.so' for example. I get the following error code:
g++ -fopenmp -static -lpthread -o bayescan_2.1 start.o beta.o dirichlet.o RJupdates.o MHupdates.o likelihood.o read_write.o anyoption.o
/bin/ld: cannot find -lpthread
/bin/ld: cannot find -lm
/bin/ld: cannot find -ldl
/bin/ld: cannot find -lpthread
/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make: *** [Makefile:4: bayescan_2.1] Error 1
These libraries all are found in /usr/lib64 on my chair's computing cluster. However the ld.so.conf file does not include a path that only goes to /usr/lib64 and I don't have admin permissions to create a new .conf file in /etc/ld.so.conf.d/.
Is there any way I can force make to search for the libraries in /usr/lib64?
Here is the actual Makefile in question:
# BayeScan makefile
bayescan_2.1: start.o beta.o dirichlet.o RJupdates.o MHupdates.o likelihood.o read_write.o anyoption.o
g++ -fopenmp -static -lpthread -o bayescan_2.1 start.o beta.o dirichlet.o RJupdates.o MHupdates.o likelihood.o read_write.o anyoption.o
start.o: start.cpp errors.cpp anyoption.h global_defs.h
g++ -fopenmp -c start.cpp errors.cpp
beta.o: beta.cpp global_defs.h
g++ -fopenmp -c beta.cpp
dirichlet.o: dirichlet.cpp global_defs.h
g++ -fopenmp -c dirichlet.cpp
RJupdates.o: RJupdates.cpp global_defs.h
g++ -fopenmp -c RJupdates.cpp
MHupdates.o: MHupdates.cpp global_defs.h
g++ -fopenmp -c MHupdates.cpp
likelihood.o: likelihood.cpp global_defs.h
g++ -fopenmp -c likelihood.cpp
read_write.o: read_write.cpp errors.cpp global_defs.h
g++ -fopenmp -c read_write.cpp errors.cpp
anyoption.o: anyoption.cpp anyoption.h
g++ -fopenmp -c anyoption.cpp
clean:
rm *.o bayescan_2.1
EDIT:
Turns out ld was trying to find static libraries with the -static flag. Removing this flag from the Makefile fixed the issue.
Simply add -L/usr/lib64 to the link command. See Directory Options in the GCC manual:
-Ldir
Add directory dir to the list of directories to be searched for -l.
If you can't or don't want to edit the Makefile, you can supply additional search directories through an environment variable
LIBRARY_PATH
The value of LIBRARY_PATH is a colon-separated list of directories, much like PATH. When configured as a native compiler, GCC tries the directories thus specified when searching for special linker files, if it cannot find them using GCC_EXEC_PREFIX. Linking using GCC also uses these directories when searching for ordinary libraries for the -l option (but directories specified with -L come first).
For example, run this in your shell before invoking make:
$ export LIBRARY_PATH="$LIBRARY_PATH:/usr/lib64"
Related
I am trying to install my C++ igraph library from https://github.com/igraph/igraph to visual studio code using the following method this is my makefile made according to this link.
CXX = g++
CXX_FLAGS = -std=c++17 -O3 -march=native -DNDEBUG
LIB = -Llib
INC = -Iinclude
.PHONY: all
all: a.out
a.out: main.cpp
$(CXX) $(CXX_FLAGS) $(INC) $(LIB) -ligraph -lm -lstdc++ -lgomp -lpthread -o $# main.cpp
.PHONY: clean
clean:
rm a.out
The compiler will always return something like:
g++ -std=c++17 -O3 -march=native -DNDEBUG -Iinclude -Llib -ligraph -lm -lstdc++ -lgomp -lpthread -o a.out main.cpp
/usr/bin/ld: /tmp/ccqJLfvi.o: in function `main':
main.cpp:(.text.startup+0x9): undefined reference to `igraph_rng_default'
/usr/bin/ld: main.cpp:(.text.startup+0x16): undefined reference to `igraph_rng_seed'
collect2: error: ld returned 1 exit status
make: *** [Makefile:12: a.out] Error 1
If i only want to use data structures such as igraph_t graph* it will work, but if i try to call fucntion it will return error and will not generate a.out file. It would be incredablly good if someone would be able to explain why this happens cuz it really got on my nerve right now.
Please follow the instructions in the documentation to set up your package to link to igraph.
Instructions to install igraph: https://igraph.org/c/html/latest/igraph-Installation.html Note that you must both build and install the package. Make a note of the location you used to install it to (the value of CMAKE_INSTALL_PREFIX)
Instructions on compiling your first igraph program: https://igraph.org/c/html/latest/igraph-Tutorial.html Unless you are already comfortable with writing C programs and linking them to external libraries, I strongly recommend that you use CMake to set up your project, as described in the linked tutorial. CMake works the same way on all platforms (Windows/macOS/Linux) and will automatically figure out how to link your program to igraph correctly. When configuring your project, be sure to set CMAKE_PREFIX_PATH to the location where you installed igraph earlier.
I got following error while compiling library that computes some stuff with molecules. It is mostly academic project.
/usr/bin/ld: trajectory_manager.o: undefined reference to symbol '_ZSt24__throw_out_of_range_fmtPKcz##GLIBCXX_3.4.20'
//usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
It occurs to me that linker is trying to use some specific version of GLIBC but fails to find it or something but I am unable to find any solution to this at all.
The code was compiled using g++ (gcc version 5.3). Linker I have in version ldd (Ubuntu EGLIBC 2.19-0ubuntu6.7) 2.19. If necessary please tell me in comment section and I will provide any further information.
Edit:
Each src is compiled using:
mpiCC -pthread -ansi -Wno-long-long -g -D_DEBUG -I /home/asd/tunnel_analyzer/boost_lib/include -I ../../../src/lib -o main.o -c ../../../src/main/main.cpp
mpiCC -pthread -ansi -Wno-long-long -g -D_DEBUG -I /home/asd/tunnel_analyzer/boost_lib/include -o cache.o -c ../../../src/lib/cache.cpp
etc. and linked
mpiCC -pthread -ansi -Wno-long-long -g -D_DEBUG -I /home/asd/tunnel_analyzer/boost_lib/include -L/home/asd/tunnel_analyzer/boost_lib/lib -L. -o caverdock main.o cache.o coords.o current_weights.o everything.o grid.o szv_grid.o manifold.o model.o monte_carlo.o mutate.o my_pid.o naive_non_cache.o non_cache.o parallel_mc.o parse_pdbqt.o pdb.o quasi_newton.o quaternion.o random.o ssd.o terms.o weighted_terms.o constraint.o scheduler.o trajectory_manager.o -l boost_system -l boost_thread -l boost_serialization -l boost_filesystem -l boost_program_options
Note that mpiCC is just alias for g++.
it seems to be a G++ bug; installing libstdc++6 (4.9) apparently helps solve this.
I want to compile a C source file from command prompt that draws a triangle using openGL. I have the gcc compiler installed. The source file that I want to compile and execute is binded with something called Makefile.win32 file.
In my computer's F: drive there is a folder called opengl_codes. Inside that folder there are a bunch of files and two folders called hello_triangle and common.
Inside the hello_triangle folder I have these files : main.c and Makefile.win32.
I read a bunch of tutorials in the internet about Makefile, found out that to compile and execute the c source file I have to do this :-
1.first execute make -f Makefile.win32 in command prompt from the containing directory.
2.then compile the source file. i.e. gcc -o main.exe main.c
But when I execute the first command i.e. make -f Makefile.win32I get this error :-
gcc -Wall -pedantic -o hellot.exe main.c -I ../common/include ../common/win32/libglew32.dll.a ../common/win32/glfw3dll.a -lOpenGL32 -L ./ -lglew32 -lglfw3 -lm
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lglew32
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lglfw3
collect2.exe: error: ld returned 1 exit status
make: *** [all] Error 1
I am not understanding what is causing this error.
Makefile :-
BIN = hellot.exe
CC = gcc
FLAGS = -Wall -pedantic
INC = -I ../common/include
LOC_LIB = ../common/win32/libglew32.dll.a ../common/win32/glfw3dll.a
SYS_LIB = -lOpenGL32 -L ./ -lglew32 -lglfw3 -lm
SRC = main.c
all:
${CC} ${FLAGS} -o ${BIN} ${SRC} ${INC} ${LOC_LIB} ${SYS_LIB}
I am working on a project in which protobuf and zmq are involved. I have finished it on VS2010 and now want to make it work under Linux. I just installed protobuf and zmq on our Linux server and the Makefile looks like this:
g++ -c -D_DEBUG TestTDFAPI_v2.cpp -I ../
g++ -c -D_DEBUG Platform.cpp
g++ -c -D_DEBUG PathHelper.cpp
g++ -c -D_DEBUG MyStruct.pb.cpp
g++ -c -D_DEBUG MyStruct.cpp
g++ -o Test_TDFAPI_v2 Platform.o PathHelper.o MyStruct.pb.o MyStruct.o TestTDFAPI_v2.o -l /usr/local/include -L /usr/local/lib -L../ -L../linux/ -lTDFAPI_v2 -lWHNetWork -lpthread -lprotobuf
After make, I got the following error:
/usr/bin/ld: cannot find -l/usr/local/include
collect2: ld returned 1 exit status
Anyone has any clue?
-l (minus ell) is for library files to search for resolving references, you want -I (minus eye) to specify include directories.
[SOLVED] created symlinks from /usr/lib/lib/* to /usr/lib*
[UPDATE 3] NEW VERSION:
Ok, I think I fixed something
use find / -name "libboost_system.*"
outout was
/usr/include/boost/lib/libboost_system.so
/usr/include/boost/lib/libboost_system.a
/usr/include/boost/lib/libboost_system.so.1.46.1
/usr/lib/lib/libboost_system.so
/usr/lib/lib/libboost_system.a
/usr/lib/lib/libboost_system.so.1.46.1
/usr/local/include/boost_1_46_1/bin.v2/libs/system/build/gcc-4.4.3/release/link-static/threading-multi/libboost_system.a
/usr/local/include/boost_1_46_1/bin.v2/libs/system/build/gcc-4.4.3/release/threading-multi/libboost_system.so.1.46.1
/usr/local/lib/libboost_system.so
/usr/local/lib/libboost_system.a
/usr/local/lib/libboost_system.so.1.46.1
/root/tmp/boost_1_46_1/bin.v2/libs/system/build/gcc-4.4.3/release/link-static/threading-multi/libboost_system.a
/root/tmp/boost_1_46_1/bin.v2/libs/system/build/gcc-4.4.3/release/threading-multi/libboost_system.so.1.46.1
why are these files in /usr/lib/lib ? and is it a problem ?
and the ls -l /usr/lib/lib | grep boost_system
ls -l /usr/lib/lib | grep boost_system
-rw-r--r-- 1 root root 21574 2011-05-09 15:15 libboost_system.a
lrwxrwxrwx 1 root root 25 2011-05-09 15:15 libboost_system.so -> libboost_system.so.1.46.1
-rwxr-xr-x 1 root root 20053 2011-05-09 15:15 libboost_system.so.1.46.1
atm my makefile looks like
LIBPATH=-I/usr/local/include/cpp-netlib
LIBS=$(LIBPATH) -lboost_system -lboost_filesystem -lboost_thread -lpthread
LD=g++ -g
CPP=g++ -c -g $(LIBS)
P=.
OBJ=$(P)/tmp/main.o $(P)/tmp/CLink.o $(P)/tmp/CFetcher.o
main: $(OBJ); $(LD) $(OBJ) $(LIBS) -o $#
$(P)/tmp/CLink.o: $(P)/src/CLink.cpp $(P)/include/CLink.h; $(CPP) -c $< -o $#
$(P)/tmp/CFetcher.o: $(P)/src/CFetcher.cpp $(P)/include/CFetcher.h; $(CPP) -c $< -o $#
$(P)/tmp/main.o: $(P)/src/main.cpp $(P)/include/CLink.h $(P)/include/CFetcher.h ; $(CPP) -c $< -o $#
all:
touch $(P)/tmp/*.o;
touch main;
rm -f $(P)/tmp/*.o;
rm -f main;
make main;
The Compiler output is lie
g++ -c -g -I/usr/local/include/cpp-netlib -lboost_system -lboost_filesystem -lboost_thread -lpthread -c src/main.cpp -o tmp/main.o
g++ -c -g -I/usr/local/include/cpp-netlib -lboost_system -lboost_filesystem -lboost_thread -lpthread -c src/CLink.cpp -o tmp/CLink.o
g++ -c -g -I/usr/local/include/cpp-netlib -lboost_system -lboost_filesystem -lboost_thread -lpthread -c src/CFetcher.cpp -o tmp/CFetcher.o
g++ -g ./tmp/main.o ./tmp/CLink.o ./tmp/CFetcher.o -I/usr/local/include/cpp-netlib -lboost_system -lboost_filesystem -lboost_thread -lpthread -o main
So for me all looks nice but when i try to run the program
./main
./main: error while loading shared libraries: libboost_system.so.1.46.1: cannot open shared object file: No such file or directory
The -l flags must come after the source files on linker command-line.
Yes, that means you'll have to split the LD definition to LD and LIBS, put all the -L and -l flags in the later and change the link command to:
$(LD) $(OBJ) $(LIBS) -o $#
The library (.so (dynamic) or .a (static)) files have to be the same version as the headers. While there are boost 1.46.1 headers installed in /usr/local/include/boost_1_46_1/, the corresponding library files don't seem to be installed at all. The only installed libraries are version 1.40.0 in /usr/lib, so the linker finds those (/usr/lib would be searched by default even if you didn't include the -L/usr/lib flag), but they don't contain the symbols expected by 1.46.1.
Note that when linking against shared library (using shared libraries is strongly recommended in Linux), the linker looks for the file with .so extension, but that is usually symlink to a file with added version suffix and the linker reads it and records the target name in the binary. That way programs compiled against the .1.40 will continue to work when 1.46 is installed, because the libboost*.so.1.40.0 may (and have to) stay around after the .so is redirected to the 1.46.1 version.
It should be even possible to install like:
/usr/local/lib/boost_1_46_1/libboost_system-mt.so -> /usr/local/lib/libboost_system-mt.so.1.46
/usr/local/lib/libboost_system-mt.so.1.46 -> /usr/local/lib/libboost_system-mt.so.1.46.1
/usr/local/lib/libboost_system-mt.so.1.46.1
and compile using -L/usr/local/lib/boost_1_46_1, though I currently can't find any package that would do it to confirm this. This way you could have development files for multiple versions installed and switch between them using explicit -I and -L flags while dynamic linker would still find the runtime files, for which it only looks in /usr/local/lib, /usr/lib and /lib (it can be configured in /etc/ld.so.conf, but that's the default).
Execute your application with strace. This will show the location were you app is looking for your boost libs. In my case an app was looking in /usr/lib/x86_64-linux-gnu for boost libs where the actual location was /usr/lib/lib. A simple export statement adding the paths for the boost shared libs in my case LD_LIBRARY_PATH=/usr/lib/lib worked a treat.
output from strace
open("/usr/lib/x86_64-linux-gnu/libboost_system.so.1.46.1", O_RDONLY) = -1 ENOENT (No such file or directory)
exit_group(127) = ?