libtool can't find the la when linking with option -L - libtool

I met the problem when compiling the source code of mpc which will depend on gmp.
The command to compile mpc is as below.
./configure --with-mpfr=/home/wy/tmp/mpfr-4.0.2/ins --with-gmp=/home/wy/tmp/gmp-6.2.0/ins --prefix=/home/wy/tmp/mpc-1.1.0/ins
The gmp has been installed into /home/user/tmp/gmp-6.2.0/ins successfully.
The error when compiling mpc with libtool is as below.
/bin/bash ../libtool --tag=CC --mode=link gcc -std=gnu99 -O2 -pedantic -fomit-frame-pointer -m64 -mtune=corei7 -march=corei7 -version-info 4:0:1 -L/home/wy/tmp/gmp-6.2.0/ins/lib -L/home/wy/tmp/mpfr-4.0.2/ins/lib -o libmpc.la -rpath /home/wy/tmp/mpc-1.1.0/ins/lib abs.lo acos.lo acosh.lo add.lo add_fr.lo add_si.lo add_ui.lo arg.lo asin.lo asinh.lo atan.lo atanh.lo clear.lo cmp.lo cmp_abs.lo cmp_si_si.lo conj.lo cos.lo cosh.lo div_2si.lo div_2ui.lo div.lo div_fr.lo div_ui.lo exp.lo fma.lo fr_div.lo fr_sub.lo get_prec2.lo get_prec.lo get_version.lo get_x.lo imag.lo init2.lo init3.lo inp_str.lo log.lo log10.lo mem.lo mul_2si.lo mul_2ui.lo mul.lo mul_fr.lo mul_i.lo mul_si.lo mul_ui.lo neg.lo norm.lo out_str.lo pow.lo pow_fr.lo pow_ld.lo pow_d.lo pow_si.lo pow_ui.lo pow_z.lo proj.lo real.lo rootofunity.lo urandom.lo set.lo set_prec.lo set_str.lo set_x.lo set_x_x.lo sin.lo sin_cos.lo sinh.lo sqr.lo sqrt.lo strtoc.lo sub.lo sub_fr.lo sub_ui.lo swap.lo tan.lo tanh.lo uceil_log2.lo ui_div.lo ui_ui_sub.lo -lmpfr -lmpfr -lgmp -lm
/bin/grep: /usr/local/lib/libgmp.la: No such file or directory
/bin/sed: can't read /usr/local/lib/libgmp.la: No such file or directory
libtool: error: '/usr/local/lib/libgmp.la' is not a valid libtool archive
Makefile:432: recipe for target 'libmpc.la' failed
make[2]: *** [libmpc.la] Error 1
make[2]: Leaving directory '/home/wy/tmp/mpc-1.1.0/src'
Makefile:465: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/wy/tmp/mpc-1.1.0'
Makefile:375: recipe for target 'all' failed
make: *** [all] Error 2
From the error message, we can see that the lib path has been indicated as -L/home/wy/tmp/gmp-6.2.0/ins/lib. But libtool still can't find the lib.

This is going to be hard to answer easily, but it seems like you have some other .la file that references it, and causes it to fail this way. Paths within .la files are always absolute. See this old blog post of mine for details.
My best guess for your particular case, is that you have an old copy of mpfr installed in /usr/local — and that is taking precedence over the one you want to use.

The problem appears to be in the MPFR configure scripts or makefile, not in MPC!
As you can see above, it's not looking for libgmp.la in the place you specified on the command-line, but in the default installation location. The reason for this is that the location of libgmp.la is specified incorrectly in libmpfr.la! It's not MPC's fault...
I was able to work around the problem by editing libmpfr.la, which you can find where you specified the MPFR libraries to go, and change the location to libgmp.la from /usr/lib/libgmp.la to the actual location where you targeted the GMP libraries.
The line in libgmp.la should look like this:
# Libraries that this one depends upon.
dependency_libs=' -L/your/mpfr/lib/target /your/gmp/lib/target/libgmp.la
Where "/your/mpfr/lib/target" should be where you told MPFR to put its library files, and "/your/gmp/lib/target" needs to be changed to where you told GMP to put its library files.

Related

CUDA + CMake target library dependence breaks on different machine

I recently tried to build my https://github.com/eyalroz/cuda-api-wrappers/ library's examples after switching to another Linux distribution on the same machine. Strangely enough, I encountered a linking issue. The command:
/usr/bin/c++ -Wall -std=c++11 -g CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o -o examples/bin/device_management -rdynamic lib/libcuda-api-wrappers.a -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -ldl -lrt
fails to find the CUDA runtime library, and I get:
CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o: In function `cuda::device::peer_to_peer::get_attribute(cudaDeviceP2PAttr, int, int)':
/home/eyalroz/src/mine/cuda-api-wrappers/src/cuda/api/device.hpp:38: undefined reference to `cudaDeviceGetP2PAttribute'
collect2: error: ld returned 1 exit status
but if I add -L/usr/local/cuda/lib64 it builds fine. This didn't use to happen before; and it doesn't happen on another machine I've checked on, nor does it even happen to other targets using the CUDA runtime in the same CMakeLists.txt (like version_managament).
FindCUDA seems to be finding everything, as the value of ${CUDA_LIBRARIES} is /usr/local/cuda/lib64/libcudart_static.a;-lpthread;dl;/usr/lib/x86_64-linux-gnu/librt.so. And the target lines in CMakeLists.txt are:
add_executable(device_management EXCLUDE_FROM_ALL examples/by_runtime_api_module/device_management.cpp)
target_link_libraries(device_management cuda-api-wrappers ${CUDA_LIBRARIES})
as is suggested in answers to other related questions (e.g. here). Why is this happening? Should I "manually" add the -L switch?
Edit: Following #RobertCrovella's suggestion, here are the ld search paths:
$ gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012 | tr ':' "\n" | tail -n +3
/usr/local/cuda/lib64/x86_64-linux-gnu/5/
/usr/local/cuda/lib64/x86_64-linux-gnu/
/usr/local/cuda/lib/
/usr/lib/gcc/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/
/usr/x86_64-linux-gnu/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/lib/x86_64-linux-gnu/5/
/lib/x86_64-linux-gnu/
/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/usr/local/cuda/lib64/
/usr/x86_64-linux-gnu/lib/
/usr/lib/
/lib/
/usr/lib/
$ ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu")
SEARCH_DIR("=/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib")
Notes:
Yes, I know the CMakeLists.txt there is ugly.
TL;DR:
After the FindCUDA invocation, add the lines:
get_filename_component(CUDA_LIBRARY_DIR ${CUDA_CUDART_LIBRARY} DIRECTORY)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} "-L${CUDA_LIBRARY_DIR}")
and building should succeed on both systems.
Discussion:
(Paraphrasing #RobertCrovella and myself in the comments:)
OP was expecting, that if the following hold:
FindCUDA succeeds
${CUDA_LIBRARIES} includes a valid full path to either the static or the dynamic CUDA runtime library
the library dependency is indicated using target_link_libraries(relevant_target ${CUDA_LIBRARIES})
... then the CMake-based build he was attempting should succeed on a variety of valid CUDA installations. That is (unfortunately) not the case, since while FindCUDA does locate the CUDA library path, it does not actually make your linker search that path. So a failure should actually be expected. The build had worked on OP's old system due to a "fluke", or rather, due to OP having added the CUDA library directory to the linker's search path, somehow, apriori.
The linking command must be issued with the -L/path/to/cuda/libraries switch, so that the linker knows where to looks for the (unspecified-path) libraries referred to be the CUDA-related -l switches (in OP's case, -lcudart_static).
This answer discusses how to do that in CMake for different kinds of targets. You might also want to have a look at man gcc (the GCC manual page, also available here) regarding the -l and -L options, if you are not familiar with them.

error: ld returned 1 exit status during installation

I am still doing the Caffe Installation but now I'm facing a new problem. When I run make command a new error massage appear which is:
LD -o .build_release/lib/libcaffe.so.1.0.0-rc3
/usr/bin/ld: cannot find -lhdf5_hl
/usr/bin/ld: cannot find -lhdf5
/usr/bin/ld: cannot find -lopencv_imgcodecs
collect2: error: ld returned 1 exit status
Makefile:563: recipe for target '.build_release/lib/libcaffe.so.1.0.0-rc3'
failed
make: *** [.build_release/lib/libcaffe.so.1.0.0-rc3] Error 1
I am pretty sure I already have all the dependencies.
Hope someone can help me. Thank you.
It can't find the way to reach the files. I mean the files here are libhdf5_hl.so, libhdf5.so and libopencv_imgcodecs.so.
Open your Makefile.config file, you'll find the following lines:
# Whatever else you find you need goes here.
INCLUDE_DIRS := $(PYTHON_INCLUDE) /usr/local/include
LIBRARY_DIRS := $(PYTHON_LIB) /usr/local/lib /usr/lib
That means those 3 files I mentioned above are not found within the default LIBRARY_DIRS. Search through usr subdirectories.
If you've found the location, for example /usr/local/hdf5/lib, then add it to LIBRARY_DIRS.
LIBRARY_DIRS := $(PYTHON_LIB) /usr/local/lib /usr/lib /usr/local/hdf5/lib
You need to create symbolic links to the missing library files. For hdf5 you may do this:
ln -s /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10.0.1 /usr/lib/x86_64-linux-gnu/libhdf5.so
ln -s /usr/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.10.0.1 /usr/lib/x86_64-linux-gnu/libhdf5_hl.so
Before creating the symbolic links check the version of your library files and OS. For me it's 10.0.1 and my OS is Ubuntu 15.10.

Caffe compilation fails: Undefined symbols for architecture x86_64?

If I try building the newest version of Caffe, it leads to this error:
$ make all
CXX/LD -o .build_release/tools/caffe.bin
clang: warning: argument unused during compilation: '-pthread'
Undefined symbols for architecture x86_64:
"caffe::Net<float>::Forward(float*)", referenced from:
test() in caffe.o
time() in caffe.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [.build_release/tools/caffe.bin] Error 1
I'm building on osx, OpenBLAS, and CPU_ONLY. I found a kind of similar issue on here but it appears to have been a resolved issue, and I'm not getting the exact same error, though perhaps it's related? I can also build and run an older version of Caffe from a month ago, so I think something has changed very recently.
Any ideas on how to overcome this error?
It shows a link problem when compile.On osx this problem will happen usually.I guess the problem happened in Makefile.config.You can change to
# To customize your choice of compiler, uncomment and set the following.
# N.B. the default for Linux is g++ and the default for OSX is clang++
CUSTOM_CXX := g++
and confirm some path is correct.
I had exactly the same problem. Its now resolved.
Do check if you already have a libcaffe.so in your system library paths (maybe /usr/local/lib). If so, delete the existing libcaffe.so and build again.

CUDA 7.0 Error while compiling samples

I'm trying to install CUDA 7.0 on Ubuntu 14.04. I've followed the installation instructions as outlined here. Specifically, I've followed steps in section 3.6 and Chapter 6. While compiling the examples (Section 6.2.2.2) using make, I'm getting the following error:
make[1]: Entering directory `/usr/local/cuda-7.0/samples/3_Imaging/cudaDecodeGL'
/usr/local/cuda-7.0/bin/nvcc -ccbin g++ -m64 -gencode arch=compute_20,
code=compute_20 -o cudaDecodeGL FrameQueue.o ImageGL.o VideoDecoder.o
VideoParser.o VideoSource.o cudaModuleMgr.o cudaProcessFrame.o
videoDecodeGL.o -L../../common/lib/linux/x86_64 -L/usr/lib/"nvidia-346"
-lGL -lGLU -lX11 -lXi -lXmu -lglut -lGLEW -lcuda -lcudart -lnvcuvid
/usr/bin/ld: cannot find -lnvcuvid
collect2: error: ld returned 1 exit status
make[1]: *** [cudaDecodeGL] Error 1
make[1]: Leaving directory `/usr/local/cuda-7.0/samples/3_Imaging/cudaDecodeGL'
make: *** [3_Imaging/cudaDecodeGL/Makefile.ph_build] Error 2
If you notice, there is -L/usr/lib/"nvidia-346". In my case, I have installed nvidia-349. What worked for me is to edit NVIDIA_CUDA-7.0_Samples/3_Imaging/cudaDecodeGL/findgllib.mk and change UBUNTU_PKG_NAME = "nvidia-346" to nvidia-349.
In order to properly install CUDA 7.0 on Ubuntu 14.04, you need a nvidia driver version 346 or higher.
If you're using the .deb installation method, the nvidia graphics driver is installed automatically.
If you used the .run file installation method and chose not to install the nvidia driver, you can manually install the driver afterwards through the package manager:
sudo apt-add-repository ppa:xorg-edgers/ppa && sudo apt-get update
sudo apt-get install nvidia-346 nvidia-346-dev nvidia-346-uvm libcuda1-346 nvidia-libopencl1-346 nvidia-icd-346
In my case, I installed nvidia-352 afterwards due to a bug in nvidia-346 and I stumbled upon the same error.
andoum's approach of manually changing the hard-coded UBUNTU_PKG_NAME = "nvidia-346" to UBUNTU_PKG_NAME = "nvidia-352" in NVIDIA_CUDA-7.0_Samples/3_Imaging/cudaDecodeGL/findgllib.mk worked fine for me.
I met the same issue and solution is that put path of nvidia into system path:
sudo gedit /etc/environment
add these path into environment
LIBRARY_PATH=/usr/lib/your_nvidia_edition:$LIBRARY_PATH
In fact I have encountered this problem when I made a make. I installed Cuda 8.0 under my Ubuntu 16.04. This problem had been confusing me for several weeks and I was almost tending to reinstall ubuntu for that after reviewing many suggestions via google, but finally I addressed it myself recently.
First of all, you should replace all the UBUNTU_PKG_NAME= ##nvidia-3xx## to the one of your actually installed nvidia driver version as recommended above. Then you will probably get compiling error after you do a new make. In my case, I have the link errors like
/usr/bin/ld: warning: libGLX.so.0, needed by /usr/lib/nvidia-
375/libGL.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libGLdispatch.so.0, needed by /usr/lib/nvidia-
375/libGL.so, not found (try using -rpath or -rpath-link)
....
or whatever contains missing link errors. Do locate the files you miss like
$ locate libGLX.so.
/usr/lib/nvidia-375/libGLX.so.0
/usr/lib32/nvidia-375/libGLX.so.0
$ locate libGLdispatch.so.0
/usr/lib/nvidia-375/libGLdispatch.so.0
/usr/lib32/nvidia-375/libGLdispatch.so.0
The error above is probably caused the compiling files cannot find in the default cuda libraries as you set, so you just need to copy the missing files to /usr/lib/nvidia-3xx/ (the actual path in your case) and this should work(it works in my case), if it doesn't maybe you could try to link the new add files to the one that need using a
$ sudo ln -s (requested file) (requesting file).
Hope this will help.

Makefile Error after adding C mysql libs Eclipse CDT

I'm using Eclipse Juno CDT.
I added the following to my project:
the mysql/includes path to the includes path setting
the libmysql.lib and zlib.lib to libraries setting
the mysql library path to the library paths setting
Now, when I make my project, the compilation throws an error when I run the application.
This is the build:
10:08:56 **** Build of configuration Debug for project mysqlapp ****
make all
Building file: ../src/mysqlapp.c
Invoking: Cygwin C Compiler
gcc -I"C:\Program Files\MySQL\MySQL Connector C 6.0.2\include" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/mysqlapp.d" -MT"src/mysqlapp.d" -o "src/mysqlapp.o" "../src/mysqlapp.c"
cygwin warning:
MS-DOS style path detected: C:\Users\Yonaton\workspace\mysqlapp\Debug
Preferred POSIX equivalent is: /cygdrive/c/Users/Yonaton/workspace/mysqlapp/Debug
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Finished building: ../src/mysqlapp.c
Building target: mysqlapp.exe
Invoking: Cygwin C Linker
gcc -L"C:\Program Files\MySQL\MySQL Connector C 6.0.2\lib\opt" -o "mysqlapp.exe" ./src/mysqlapp.o
Finished building target: mysqlapp.exe
And this is the run within eclipse:
10:09:55 **** Incremental Build of configuration Debug for project mysqlapp ****
make all
src/mysqlapp.d:1: *** multiple target patterns. Stop.
10:09:56 Build Finished (took 225ms)
Under Project->Properties->C/C++ General->Paths and Symbols->Libraries do not add the file name of the library, nor the path.
So if you want to link against /lib64/libz.so just add z.
Or alternativly add the z under Project->Properties->C/C++ Build->Settings->GCC Linker->Libraries.
If the library is not located under a standard path add the custom search path for a library under Project->Properties->C/C++ General->Paths and Symbols->Libraries Paths.
Update (referring "multiple target patterns"):
make does not like DOS paths. In the .d file a : after the drive letter is interpreted as target delimiter.
Switch to UNIX paths (as you were already told to do ... ;-)).
(see also: "multiple target patterns" Makefile error)
If I remember correctly "-l" ( small L) before your libraries.