I have an error making a code project because of what I believe is a missing routine from lapack:
HomographyInit.cc:(.text+0x385): undefined reference to `dgesvd_'
I think I need to add lapack library somehow to my Makefile. Here is part of my Makefile:
CC = g++
COMPILEFLAGS = -I MY_CUSTOM_INCLUDE_PATH -D_LINUX -D_REENTRANT -Wall -O3 -march=nocona -msse3
LINKFLAGS = -L MY_CUSTOM_LINK_PATH -lGVars3 -lcvd
I tried doing the following to no avail:
CC = g++
COMPILEFLAGS = -I MY_CUSTOM_INCLUDE_PATH -D_LINUX -D_REENTRANT -Wall -O3 -march=nocona -msse3
LINKFLAGS = -L MY_CUSTOM_LINK_PATH -lGVars3 -lcvd **-llapack**
Result:
make
...
/usr/bin/ld: cannot find -llapack
collect2: ld returned 1 exit status
How can I add lapack to my project? I am pretty sure I installed it correctly, though would be willing to double-check that somehow.
It looks like liblapack isn't in the path that ld can find. I would suggest two things:
Establish a symbolic link manually. It is possible (and sometimes common) that ld cannot recognize liblapack.so.3gf or liblapack.so.3.0.1 or so are essentially liblapack.so. You can set up a link by ln -s liblapack.so.3gf liblapack.so
Install liblapack-dev package instead if you're using ubuntu or debian repos. For some unclear reasons, liblapack3gf is not the same as liblapack-dev. I am not sure if in any circumstances, both will do or not do the same thing.
I think the first item should be able to resolve your problem (hopefully).
On my computer the dynamic library is in /usr/lib64/liblapack.so.3.4.1 and contains the requested symbol:
$ nm -D /usr/lib64/liblapack.so.3.4.1 | grep dgesvd
0000000000189200 T dgesvd_
So I would guess that the place where your lapack is installed is not in the linker search path. You should add the flag -L/path/to/the/lapackdir to LINKFLAGS
Related
I did not get response from Qualcomm forum so I decided to post here. When I was trying to run examples of Halide for Hexagon by running make run as written in the document. Then I got the following issue. The -lc++abi is missing.
clang++ -std=c++11 -I /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/include -stdlib=libc++ -O3 -g -fno-rtti -rdynamic conv3x3_generator.cpp /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/lib/libHalide.a /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/tools/GenGen.cpp -o /opt/qcom/Hexagon_SDK/4.3.0.0/tools/HALIDE_Tools/2.3.03/Halide/Examples/build/offload/hexagon_benchmarks/bin/conv3x3.generator -lz -lrt -ldl -lpthread -lm
/usr/bin/ld: cannot find -lc++abi
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I checked the /usr/lib and find. So it should be there?
./x86_64-linux-gnu/libc++abi.so.1.0
./x86_64-linux-gnu/libc++abi.so.1
./llvm-10/lib/libc++abi.so.1.0
./llvm-10/lib/libc++abi.so.1
Did I miss anything or make anything stupid? Thanks!
ld is your system's host linker -- that's GNU BFD ld. clang++ must be in your PATH but it's the host clang++ and not the hexagon-clang++ that would be with Halide/Hexagon tools.
I contacted the person from Qualcomm. I am not supposed to use either /usr/bin/clang++ nor hexagon-clang++. I downloaded clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04.tar.xz from https://releases.llvm.org/7.0.1/. You should use clang++ under the bin folder after you extract it. Now it works for me.
The project I am attempting compile is not in any way complex, and references nothing but the standard library and one self-contained library (everything compiles fine on another system). As indicated by the title, it can't even link against something in the standard library, due to things in there not having been compiled with -fPIC, supposedly. I didn't build it myself, nor do I want to, and reinstalling things with apt didn't seem to resolve the "recompile with -fPIC" issue.
I will say that I think one possible source of the issue is due to gcc-multilib or something being installed earlier, but I think that was purged. I don't know, maybe something was overwritten or a conflict arose. Might not even be related. Any ideas?
Running Ubuntu 18.04
g++ -I inc -I /usr/include/mono-2.0 -MMD -MF dep/Nonsense.d -std=c++17 -O3 -fno-stack-protector -fno-unroll-loops -fomit-frame-pointer -Wno-ignored-optimization-argument -c -o obj/Nonsense.o src/Nonsense.cpp
g++ -I inc -I /usr/include/mono-2.0 -MMD -MF dep/Socket.d -std=c++17 -O3 -fno-stack-protector -fno-unroll-loops -fomit-frame-pointer -Wno-ignored-optimization-argument -c -o obj/Socket.o src/Socket.cpp
g++ -shared -flto -o libNonsense.so obj/Nonsense.o obj/Socket.o -Llib -lenet
/usr/bin/x86_64-linux-gnu-ld: obj/Socket.o: relocation R_X86_64_PC32 against symbol `_ZTISt13runtime_error##GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
makefile:22: recipe for target 'libNonsense.so' failed
make: *** [libNonsense.so] Error 1
Apparently, it is compulsory to compile with the -fPIC flag in 64bits platform. If you are making a 32-bits project with linkink with 32-bits library; you don't need -fPIC.
Indeed, without -fPIC, the dynamic linker recalculates adresses for global variables and functions (which are not known in advance in the step of compilation). However, in a 64-bits system, it is not possible to use this technique as it is required to guess in advance the size of adress.
PIC (Position Independent Code), a more sophisticated and complicated process is used. https://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64 for explanations.
As the error message says, you need to recompile with -fPIC. Your current compiler command does not show the -fPIC option:
g++ -I inc -I /usr/include/mono-2.0 -MMD -MF dep/Socket.d -std=c++17 -O3 -fno-stack-protector -fno-unroll-loops -fomit-frame-pointer -Wno-ignored-optimization-argument -c -o obj/Socket.o src/Socket.cpp
Same for -flto by the way—this flag also has to be specified when compiling in order to be effective.
I am learning to create shared libraries in Linux, subsequently to develop parallelised scientific computing programs. I took the toy example from here for shared library. I modified the Makefile from this question to suit the toy example. My Makefile now is
CC = mpicc
INCDIR = -I ./
CFLAGS = -Wall -rdynamic -g -fPIC $(INCDIR)
LIBADD = -L ./ -lcalc_mean
all: dyn_main.out
dyn_main.out: libcalc_mean.so
$(CC) -o $# main.c $(LIBADD)
libcalc_mean.so: calc_mean.o
$(CC) -shared --export-dynamic -o $# $<
calc_mean.o: calc_mean.c
$(CC) $(CFLAGS) -c $<
clean :
-rm *.o
-rm *.out
-rm *.so
.PHONY:
clean
When I make with CC = gcc in the Makefile, things run fine. I could run the binary even with mpirun.
When I have CC = mpicc in the Makefile, I get the following error.
mpicc -Wall -rdynamic -g -fPIC -I ./ -c calc_mean.c
mpicc -shared --export-dynamic -o libcalc_mean.so calc_mean.o
mpicc -o dyn_main.out main.c -L ./ -lcalc_mean
/home/elan/localinstalls/lib/libmpi.so: undefined reference to `pthread_key_create'
/home/elan/localinstalls/lib/libmpi.so: undefined reference to `pthread_getspecific'
/home/elan/localinstalls/lib/libmpi.so: undefined reference to `pthread_create'
/home/elan/localinstalls/lib/libmpi.so: undefined reference to `pthread_atfork'
/home/elan/localinstalls/lib/libmpi.so: undefined reference to `pthread_setspecific'
/home/elan/localinstalls/lib/libmpi.so: undefined reference to `pthread_join'
collect2: ld returned 1 exit status
make: *** [dyn_main.out] Error 1
I added the path to libpthread.so,.a to LD_LIBRARY_PATH, but no avail. I have a self compiled openmpi-1.5.4. If this were a openmpi dependency, shouldn't it have been resolved when I configured it?
Is this error familiar? I am using Ubuntu 11.04, with gcc 4.5.2. I already built and run some mpi parallel programs successfully. But they are large packages configured with autotools. One of the config.log s display the same error. But even that one runs fine.
References to / examples of creating static/shared libraries with mpi will also be appreciated (though Openmpi discourages fully static libraries.)
Thank you very much,
Elan.
You should be able to just add -lpthread.
Open MPI probably didn't add it because it found that adding -lpthread wasn't necessary (likely due to some other dependency implicitly pulling in the pthread library). But with the linker flags you're using, you might well have changed that implicit dependency, so the pthread library isn't being pulled in automatically anymore.
If adding -lpthread to the command line fixes the issue, then see this FAQ entry for how to update the wrapper compilers (E.g., add your own flags): http://www.open-mpi.org/faq/?category=mpi-apps#override-wrappers-after-v1.0
You can see what options the Open MPI compiler wrapper supplies to the underlying compiler and linker using the -showme option or one of its specific variants:
-showme:compile to just show the compiler flags
-showme:link to just show the linker flags
For example:
$ mpicc -showme
icc -I/opt/MPI/openmpi-1.5.3/linux/intel/include -I/opt/MPI/openmpi-1.5.3/linux/intel/include/openmpi -fexceptions -pthread -I/opt/MPI/openmpi-1.5.3/linux/intel/lib -Wl,-rpath,/opt/MPI/openmpi-1.5.3/linux/intel/lib -I/opt/MPI/openmpi-1.5.3/linux/intel/lib -L/opt/MPI/openmpi-1.5.3/linux/intel/lib -lmpi -ldl -Wl,--export-dynamic -lnsl -lutil
I am facing below errors when trying to statically link libDuma, Can you tell me how to ask g++ to use malloc from libDuma?
sunny#sunny-laptop:~/CodeTest$ g++ ./testDuma.cpp -g -o testDuma -static -lduma -pthread
/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib/libc.a(malloc.o): In function `free':
(.text+0x4b00): multiple definition of `free'
/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib/libduma.a(duma.o):(.text+0x25f0): first defined here
/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib/libc.a(malloc.o): In function `malloc':
(.text+0x4bc0): multiple definition of `malloc'
/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib/libduma.a(duma.o):(.text+0x2730): first defined here
/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib/libc.a(malloc.o): In function `realloc':
(.text+0x5950): multiple definition of `realloc'
/usr/lib/gcc/i686-linux-gnu/4.4.5/../../../../lib/libduma.a(duma.o):(.text+0x23d0): first defined here
collect2: ld returned 1 exit status
Don't force a completely static link (don't use the -static flag) -- doing so on any modern UNIX system is an extremely bad idea(TM).
Instead, link just the libduma statically. Either of these commands should work:
g++ ./testDuma.cpp -g -pthread -o testDuma /path/to/libduma.a
g++ ./testDuma.cpp -g -pthread -o testDuma -Wl,-Bstatic -lduma -Wl,-Bdynamic
Add -nodefaultlibs flag to not link to libc. Or, remove -lduma and link it dynamically after compilation with:
LD_PRELOAD=/usr/lib/libduma.so ./testDuma
I have downloaded the latest GLUI source code and now I am trying to compile it. When I do so, I get the following error:
g++ -O0 -Wall -pedantic -I./ -I./include -I/usr/X11R6/include -o bin/example1 example/example1.cpp -L./lib -lglui -L/usr/X11R6/lib/libXdmcp.a -lglut -lGLU -lGL -lXmu -lXext -lX11 -lXi -lm
/usr/bin/ld: cannot find -lXmu
collect2: ld returned 1 exit status
When I did a locate libXmu, I get the following output:
> %:~/src/GLUI/src$ locate libXmu
> /usr/lib/libXmu.so.6
> /usr/lib/libXmu.so.6.2.0
> /usr/lib/libXmuu.so.1
> /usr/lib/libXmuu.so.1.0.0
Do I get the error because I don't have a /usr/lib/libXmu.so? If this is the case, how can I make one? (I am not experienced with linking at all).
Thanks!
Linux distributions usually package the libraries needed for running programs separately from the files needed to build programs.
Look for packages named *-devel or *-dev.
I don't know which one you need in particular for this, but you can use apt-cache search to look for it.
The answer was actually one of the first ones here originally but the owner deleted it, it seems. I was able to solve the problem by creating a symbolic link to the latest version of the library (i.e. /usr/lib/libXmu.so.6) and compile the code successfully.
I had the same problem, if creating a symbolic link doesnt help,
try the following:
Print your $PATH ("echo $PATH"),
and check if the library file you need is in one of those directories.
Use "export PATH=/newly/added/path:$PATH" to add new directory to check.
Ive been including libevent, added "-levent" in the gcc command, and ld used file /usr/lib/libevent.so, so it looks like the "lib" prefix and extension are being added automatically by ld.
Keep it up.