Getting this error during "make" in mpich
GEN lib/libmpi.la
libtool: error: only absolute run-paths are allowed
Compiler being used is clang (the code builds fine with gcc). Any idea what this error could be due to?
Here is the configure command:
./configure '--prefix=$PWD/BIN' '--with-device=ch3:nemesis:mxm' '--with-mxm=/home/xyz/software/hpcx-v1.9.5-gcc-inbox-redhat7.3-x86_64/mxm' '--disable-spawn' '--disable-ft-tests' '--enable-g=all' '--enable-nemesis-dbg-localoddeven' '--enable-large-tests' '--disable-perftest' 'CC=clang' 'CXX=clang++' 'FC=gfortran' 'F77=gfortran' --cache-file=/dev/null --disable-fortran
I think the issue is the evaluation of $PWD within the quotes. If you replace
./configure '--prefix=$PWD/BIN' ...
with
./configure --prefix=$PWD/BIN ...
you should be good.
I ran into this error as well when building a different piece of software. The solution for me was to enclose the shell variable in --prefix= with {}:
./configure --prefix=${PWD}/BIN
Related
I have been using clang-3.5 to happily build bitcode versions of musl libc and
use the result to produce nice stand alone executables.
Recent attempts with clang-3.8 have not been so happy. It seems that
the bitcode clang-3.8 generates uses functions defined in
compiler-rt/lib/builtins
Typical examples of functions I find polluting the bitcode are mulxc3, mulsc3, and muldc3. I can solve this by linking against libgcc, or even the llvm alternative if I had any clear idea of what that was. Though I would rather prevent the problem from happening in the first place.
I have seen mention of flags like rtlib=compiler-rt etc, but have found precious little documentation on the subject.
So here are some simple questions.
Is it possible to prevent clang from using the compiler-rt/lib/builtins
in the emitted bitcode? Or if not
Does llvm produce a version of libgcc that I could use. Actually I would
probably build a bitcode version of it, but that is besides the point.
Love to hear some guidance on this.
Added 12/8/2016: So I will illustrate my issues with a particular workflow that
people can reproduce if they wish, or, more likely, just point out where I am being stupid.
So start by checking out:
musllv
and follow the instructions in the README.to compile (here I am using clang-3.8 on ubuntu 14.04)
WLLVM_CONFIGURE_ONLY=1 CC=wllvm ./configure --target=LLVM --build=LLVM
make
cd lib
extract-bc -b libc.a
you will also need the bitcode of a simple executable. I will use nweb.c here.
wllvm nweb.c -o nweb
extract-bc nweb
Now we can do things like:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
This workflow goes smoothly for clang-3.5 but for clang-3.8 we get:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
/tmp/libc-f734a3.o: In function `cpowl':
libc.a.bc:(.text+0xbb9a): undefined reference to `__mulxc3'
/tmp/libc-f734a3.o: In function `cpowf':
libc.a.bc:(.text+0x38f7d): undefined reference to `__mulsc3'
/tmp/libc-f734a3.o: In function `csqrt':
libc.a.bc:(.text+0x78fc3): undefined reference to `__muldc3'
/tmp/libc-f734a3.o: In function `cpow':
libc.a.bc:(.text+0xafafc): undefined reference to `__muldc3'
clang-3.8: error: linker command failed with exit code 1 (use -v to seeinvocation)
So as #paul-brannan points out we could try
clang -static -nostdlib --rtlib=compiler-rt nweb.bc libc.a.bc crt1.o libc.a -o nweb
But this is where I am probably being stupid, because I get:
clang-3.8: warning: argument unused during compilation: '--rtlib=compiler-rt'
irregardless of whether I use it as a linking or compiling flag.
OK so I finally managed to make headway on this. I built llvm-3.8.1 together with the compiler-rt project using wllvm and wllvm++.
One of the build products was libclang_rt.builtins-x86_64.a,
and from this archive I was able to extract the bitcode module
libclang_rt.builtins-x86_64.bc
using the command:
extract-bc -b libclang_rt.builtins-x86_64.a
This bitcode module has definitions for those pesky instrinsics like
__mulxc3, __mulsc3, and __muldc3.
Hallelujah!
This is basically the same issue as in mingw ld cannot find some library which is exist in the search path, MinGW linker can't find MPICH2 libraries - and I'm aware that there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW - but I couldn't find anything that explains how I can troubleshoot.
I am building a project with a huge linker command like (via g++) on MinGW, in a MSYS2 shell (git-bash.exe). The process fails with, among others:
/z/path/to/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lssl
I add -Wl,--verbose to the g++ linker call (to be passed to ld), and I can see for the -L/z/path/to/libs/openssl/lib/mingw -lssl:
...
attempt to open /z/path/to/libs/openssl/lib/mingw/libssl.a failed
...
/z/path/to/libs/openssl/lib/mingw/ssl.dll failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
But this is weird, because the file exists?
$ file /z/path/to/libs/openssl/lib/mingw/libssl.a
/z/path/to/libs/openssl/lib/mingw/libssl.a: current ar archive
(... and it was built with the same compiler on the same machine)?
Weirdly, once it attempts to open with forward slash .../libssl.a, once with backslash ...\libssl.a - but at least the first path checks out in a bash shell, as shown above?
It gets even worse if I try to specify -l:libssl.a -- or if I specify -L/z/path/to/libs/openssl/lib/mingw -Wl,-Bstatic -lssl -- instead; then all attempts to open are with a backslash:
...
attempt to open /z/path/to/scripts/other/build/openssl/build/mingw/lib\libssl.a failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
To top it all off, if I look it up manually through the command line using ld, it is found ?!:
$ ld -L/z/path/to/libs/openssl/lib/mingw -lssl --verbose
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/ssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
Does anyone have an idea why this happens, and how can I get ld to finally find these libraries? Or rather - how can I troubleshoot, and understand why these libraries are not found, when they exist at the paths where ld tries to open them?
OK, found something more - not sure if this is a bug; but my problem is that I'm actually reading arguments from a file (otherwise I get g++: Argument list too long). So, to simulate that:
$ echo " -Wl,--verbose -L/z/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
# nothing
$ g++ `cat tcmd3` 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
... it turns out, if the very same arguments are fed on the command line, then static library lookup succeeds - but if the arguments are read from file through the # at-sign, then static library lookup fails?! Unfortunately, I cannot use on my actual project, since even with cat, I'd still get g++: Argument list too long ... So how can I fix this?
MSYS has special handling of directories as arguments when they are used in the shell. This translates e.g. /<drive_letter>/blabla to the proper Windows style paths. This is to accomodate Unix programs that don't handle Z: style directory root.
What you see here is that MSYS isn't performing this interpretation for string read from a file. When you think about it, it's very logical, but as you have experienced first-hand, also sometimes annoying.
Long story short: don't put Unix style paths in files with command arguments. Instead, pass them through e.g. cygpath -w, which works in MSYS2 (which should be the MSYS that Git for Windows 2+ comes with).
Ok, with some more experiments, I noticed that:
-L/z/path/to/libs/openssl/lib/mingw, the Unix path specification, tends to fail - while if we specify the same, except starting with a Windows drive letter, that is:
-LZ:/path/to/libs/openssl/lib/mingw, then things work - also from an arguments file with # at-sign:
$ echo " -Wl,--verbose -LZ:/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
I guess, since the shell is MSYS2/git-bash.exe, entering full POSIX paths on the shell with /z/... is not a problem, because the shell will convert them - but in a file, there is nothing to convert them, so we must use Windows/MingW convention to specify them...
I have been trying to enable the gold linker on FreeBSD to use the link time optimizations. I made gold from the binutils under /usr/ports. After building binutils using make -k install clean i got ld under /usr/bin and in the directory /usr/local/bin i got ld, ld.gold and ld.bfd.
Now while trying to use link time optimization for the simple example programs here http://llvm.org/docs/GoldPlugin.html (a.c and b.c under the heading 'Examples of Link Time Optimization') i entered the four commands as follows:
clang -flto a.c -c -o a.o
ar q a.a a.o
clang b.c -c -o b.o
clang -flto a.a b.o -o main
I got the following error:
usr/bin/ld: unrecogonized option '-plugin'
usr/bin/ld: use the --help option for usage information
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Is there the problem with the linker that ld.gold is not being called. Should I replace the ld with ld.gold? Does the linker looks in the right directiry for the .so plugins?
The LLVMgold.so and libLTO.so shared objects are in the directory /usr/local/llvm-devel/lib/.
I cannot find the directory where clang is installed. I am not sure where to make the bfd-plugins directory and add the symlinks to LLVMgold.so and libLTO.so.
I am using freebsd 10.1 release. How to enable the gold linker for link time optimizations?
also how can I enable it to be the default linker?
You may want to use ld.gold instead of ld. It is installed at /usr/local/bin/ld.gold. If you are using a Makefile, it would work by setting LD variable to ld.gold, either by modifying your Makefile or specifying it on command line. Example in case you are using lang/clang37:
gmake all CC=clang37 LD=ld.gold
EDIT:
It would be even more neat if you add -fuse-ld=gold to your LDFLAGS:
LDFLAGS=-fuse-ld=gold
I'm not sure ld.bfd allows plugins, but I could be wrong.
Your /usr/bin/ld should be a symlink to whatever linker you want. You can change which linker is used by using binutils-config. Check the man-page here: http://www.linuxhowtos.org/manpages/8/binutils-config.htm. I realise this is a Linux link, but it's directed at binutils itself rather than linux-specifically.
It should be something along the lines binutils-config --gold.
On my Gentoo box it is binutils --linker=gold
EDIT: As pointed out, binutils-config doesn't work on BSD it seems. You can still manually update the symlinks though, the downside is that there might be a few of them.
You can find out which ld is used by your compiler by using gcc -print-prog-name=ld or clang -print-prog-name=ld. The file printed should be a symlink you can re-create to point to ld.gold as oposed to ld.bfd.
I am trying to build the OpenCV samples which come with the source package and I get the following:
CMake Error at CMakeLists.txt:10 (ocv_check_dependencies):
Unknown CMake command "ocv_check_dependencies".
I did install OpenCV using
cmake .
make
sudo make install
and I got a tutorial snippet working (thus I suppose it is installed correctly as a library). However, compiling the samples does not work.
I guess I have to somehow configure CMake to have “ocv_check_dependencies” - but how? I am lost!
Actually for OpenCV 2.4.4 beta the root CMakeList.txt file says:
OCV_OPTION(BUILD_EXAMPLES "Build all examples"
-DBUILD_EXAMPLES=ON worked just fine for me.
I got it.
In order to build the samples one has to change the default configuration for cmake by providing it via -D. What I did wrong was that I tried to execute cmake from within the samples directory.
The proper way to build the samples is invoking cmake like so (from within the root directory of the unpacked archive):
cmake -DBUILD_SAMPLES .
which will turn samples ON. One can proceed using make, make install than. The samples can be found in bin after building.
See also FAQ
How to compile OpenCV sample code ?
# For OpenCV 3
cd /path/to/opencv/samples/cpp/
#Compile
g++ -ggdb `pkg-config --cflags --libs opencv` facedetect.cpp -o facedetect
#run
./facedetect
Works for me.
googled from this link
mydragonisland's build instructions almost worked for me; with a minor reordering and including accents:
g++ facedetect.cpp -o facedetect `pkg-config --libs opencv`
The macro 'ocv_check_dependencies' is defined in: your_path_to/opencv/cmake/OpenCVModule.cmake
# ensures that all passed modules are available
# sets OCV_DEPENDENCIES_FOUND variable to TRUE/FALSE
macro(ocv_check_dependencies)
set(OCV_DEPENDENCIES_FOUND TRUE)
foreach(d ${ARGN})
if(d MATCHES "^opencv_[^ ]+$" AND NOT HAVE_${d})
set(OCV_DEPENDENCIES_FOUND FALSE)
break()
endif()
endforeach()
endmacro()
The top level CMakeLists.txt contains 'include' commands for files from opencv/cmake/ . Which is why the macro is available when you compile by calling cmake from the root of the opencv sources.
Reason
error message context:
CMake Error at CMakeLists.txt:10 (ocv_check_dependencies):
Unknown CMake command "ocv_check_dependencies".
This error message happens because cmake can't find the definition of ocv_check_dependencies
That's why the console said Unknown CMake command
Solution
If cmake cannot find where ocv_check_dependencies is defined
Just like #Nick Hockings Said:
ocv_check_dependencies is a macro defined in Your/OpenCV/path/OpenCVModule.cmake
macro(ocv_check_dependencies)
set(OCV_DEPENDENCIES_FOUND TRUE)
foreach(d ${ARGN})
if(d MATCHES "^opencv_[^ ]+$" AND NOT HAVE_${d})
set(OCV_DEPENDENCIES_FOUND FALSE)
break()
endif()
endforeach()
endmacro()
The fastest way is to copy this snippet above to your CMakeList.txt file right above where ocv_check_dependencies is
Therefore, cmake can finally understand what it is
That should do the trick, i hope no one else will bother with this question in the future
I got similar errors. My approach is as following:
1) cd xxx/samples 2) mkdir build 3) cd build 4) cmake .. 5) make
Now it works. We could not build individual project under their source files.
Following steps works for me.
Export toolchain path.
cd opencv-3.3.0/samples
cross_cmake &&
cross_make
cd opencv-3.3.0/samples/cpp/
When I try to build Assimp by running build_ios.sh, it tells me:
CMake Error: your C compiler: "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-gcc" was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name.
CMake Error: your CXX compiler: "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-g++" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
What I need the path to be is:
/Applications/XCode.app/Contents/Developer/Platforms/...
I've tried changing DEVROOT in build_ios.sh and IPHONE_xxxx_TOOLCHAIN.cmake, because that's what CMAKE_C_COMPILER etc seem to get generated from, but it still gives me the same errors.
Option 1:
You can set CMake variables at command line like this:
cmake -D CMAKE_C_COMPILER="/path/to/your/c/compiler/executable" -D CMAKE_CXX_COMPILER "/path/to/your/cpp/compiler/executable" /path/to/directory/containing/CMakeLists.txt
See this to learn how to create a CMake cache entry.
Option 2:
In your shell script build_ios.sh you can set environment variables CC and CXX to point to your C and C++ compiler executable respectively, example:
export CC=/path/to/your/c/compiler/executable
export CXX=/path/to/your/cpp/compiler/executable
cmake /path/to/directory/containing/CMakeLists.txt
Option 3:
Edit the CMakeLists.txt file of "Assimp": Add these lines at the top (must be added before you use project() or enable_language() command)
set(CMAKE_C_COMPILER "/path/to/your/c/compiler/executable")
set(CMAKE_CXX_COMPILER "/path/to/your/cpp/compiler/executable")
See this to learn how to use set command in CMake. Also this is a useful resource for understanding use of some of the common CMake variables.
Here is the relevant entry from the official FAQ: https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-do-i-use-a-different-compiler
The cc and cxx is located inside /Applications/Xcode.app. This should find the right paths
export CXX=`xcrun -find c++`
export CC=`xcrun -find cc`
SOLUTIONS
Sometimes the project is created before installing g++. So install g++ first and then recreate your project. This worked for me.
Paste the following line in CMakeCache.txt:
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++
Note the path to g++ depends on OS. I have used my fedora path obtained using which g++