I'm trying to get started with a domain-specific language (C++ extension) for image processing called Halide.
Following the Halide README, here's what I've tried:
Downloaded the Ubuntu 12.04 Halide binary, and extracted in a directory called ~/halide.
In the ~/halide directory, I created hello_halide.cpp, as described in the Using Halide section of this page.
Tried to compile hello_halide.cpp:
g++-4.6 -std=c++0x hello_halide.cpp -L halide -lHalide -ldl -lpthread -o hello_halide
But, g++ can't find libhalide:
/usr/bin/ld: error: cannot find -lHalide
Tried adding ~/halide to my $PATH and $LD_LIBRARY_PATH, but this didn't help.
How can I compile this basic hello_halide.cpp Halide program?
Notes:
CUDA is one of Halide's dependencies. I have CUDA installed, and I can compile/run CUDA programs.
I'm using Ubuntu 12.04.
My g++ version is 4.6.3.
-L halide tells the linker to look for the library in the subdirectory halide. In this case that means that your source file hello_halide.cpp should be in a folder ~/myfolder/, and the library libHalide.so at ~/myfolder/halide/libHalide.so (or .a if it's static). If it's somewhere else, pass an absolute path to -L.
Your idea of setting LD_LIBRARY_PATH or PATH does not work since the latter is for directories that will be searched for executables and the former is for directories that will be searched for shared libraries when you launch an executable that needs shared libraries.
Related
I am working on Windows 10 64-bit using MSYS2 with the 64-bit toolchain. In the MSYS2 terminal I found and installed the following packages after searching for them with pacman -Ss,
mingw64/mingw-w64-x86_64-openblas 0.2.20-2
mingw64/mingw-w64-x86_64-lapack 3.6.1-1
mingw64/mingw-w64-x86_64-arpack 3.5.0-1
I took an example fortran source file from the Intel MKL library examples; I copied the dgelsx.f file to a folder in my msys home directory. I compile (in the mingw64 terminal) with
gfortran dgelsx.f -o dgelsx -llapack -lblas
it compiles without any complaint, but when I attempt to run it, I get the error
C:/msys64/home/k_chu/lapacktext/dgelsx.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory
Why is this happening? I haven't attempted to deal with an arpack example yet until I get this working. Also if I do get all of this working, will it be possible to use the arpack libraries in Microsoft Visual Studio with the Intel ifort compiler? I tried copying the .dll files in /msys64/mingw64/bin into my MSV project folder but no luck, same with the .a and .dll.a files in the /msys64/mingw64/lib.
Please use dependency walker (http://www.dependencywalker.com) to locate the .dll, which the program cannot find on the path. Or compile with -static-libgcc or -static-libstdc++ to avoid dependencies at runtime.
I cannot make Armadillo 4.3 work on Windows. The library armadillo/include is included and I run g++ "-LC:\\Armadillo\\BLAS_Lapack" -o1 -o test.exe test.o -llapack -lblas, then I get the following error message:
C:/Armadillo/include/armadillo_bits/blas_wrapper.hpp:183: undefined reference to `wrapper_ddot_'
test.o: In function `ZN4arma4blas4gemvIdEEvPKcPKiS5_PKT_S8_S5_S8_S5_S8_PS6_S5_':
C:/Armadillo/include/armadillo_bits/blas_wrapper.hpp:34: undefined reference to `wrapper_dgemv_'
test.o: In function `ZN4arma4blas4gemmIdEEvPKcS3_PKiS5_S5_PKT_S8_S5_S8_S5_S8_PS6_S5_':
C:/Armadillo/include/armadillo_bits/blas_wrapper.hpp:69: undefined reference to `wrapper_dgemm_'
If I run g++ -o1 -o test.exe test.o -llapack -lblas, I get
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -llapack
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lblas
I did uncomment the configuration file config.hpp according to the README file.
Does anybody know how to make Armadillo work? (I am using Eclipse CDT.)
It took a while to get this right, but it seems transparent once it works. I will explain step by step. (Make sure you have uncommented the correct lines as directed in the README of the config.hpp file)
The general command for compiling with blas/lapack (using the default provided with armadillo (current version 4.500.0) and does make it faster :)
g++ main.cpp -I C:{ARMADILLO_ROOT}\include -L C:{ARMADILLO_ROOT}\examples\lib_win64 -lblas_win64_MT -llapack_win64_MT
where each of the commands are as follows:
g++: GNU G++ Compiler (using MinGW 4.9.1 C++ from equationsolution.com)
main.cpp: My main file of the C++ program (I have an abstract and concrete class defining the Levenshtein algorithm)
-I C:{ARMADILLO_ROOT}\include: The GCC C++ Compiler Include Path (To include the Armadillo library) where ARMADILLO_ROOT is where you have decompressed and placed your armadillo files
-L C:{ARMADILLO_ROOT}\examples\lib_win64: The MinGW C++ Linker Library Link Path (To link the BLAS and LAPACK libraries) I have used the default libs provided with armadillo, I believe and according to the doc you may and should substitute these linear libraries in a production instance)
-lblas_win64_MT -llapack_win64_MT: Identify the libraries to be used (name must match, so you cannot put -lblas or -llapack UNLESS your files are named that way - by default in this armadillo version they are named blas_win64_MT lapack_win64_MT (win64 since I am using both a MinGW/C++ 64bit and a 64bit armadillo [they should match])
Following this logic, you may configure eclipse (using eclipse Luna R1 4.4.1 -should be the same procedure on other versions) with the following:
Right Click the Project and Select "Properties" item in the popup menu
Under "C/C++ Build" on the left menu Select "Settings"
Under "GCC C++ Compiler" click on "Includes (-I)" and add the include path C:{ARMADILLO_ROOT}\include (Screenshot1)
Under "MinGW C++ Linker" click on "Libraries" add each "Libraries (-l)" as named blas_win64_MT lapack_win64_MT. (Screenshot2)
Under the same "MinGW C++ Linker" click on "Libraries" add a "Library search path (-L)" C:{ARMADILLO_ROOT}\examples\lib_win64
Click the "Apply" button before pressing "OK"
--Screenshot1
--Screenshot2
It seems to work now! I am using the Lapack and BLAS from the webpage indicated in the Readme file that I compiled myself according to #enhzflep comments.
To link everything properly in Eclipse CDT right click on your project and go to properties, then:
Under "C/C++ Build⟼Settings⟼GCC C++ Compiler⟼Command" type: g++ -I"C:\Armadillo\include" (replace with the correct path for your Armadillo folder). Make sure to do this for all Configurations (to be chosen in the drop-down menu at the top).
Under "C/C++ Build⟼Settings⟼MinGW C++ Linker⟼Libraries" add lapack and blas to the Libraries.
Under"C/C++ General⟼Paths and Symbols⟼GNU C++" add the path tot he include directory of your Armadillo folder C:\Armadillo\include.
It might be that it works with the original Lapack and BLAS files. It did not work for me, because I had only added the path to Armadillo under "C/C++ General⟼Paths and Symbols⟼GNU C++", which I guess only tells the editor what data types and functions to expect and not the compiler.
If you're using MinGW on Windows, a good option is to use OpenBLAS with Armadillo. OpenBLAS provides optimized and multi-threaded implementations of BLAS and LAPACK:
http://xianyi.github.io/OpenBLAS/
The OpenBLAS project provides pre-compiled versions for Windows. The source code can be also easily compiled under Linux and MacOS X.
Note that Armadillo doesn't support automatic installation under Windows. The cmake based installer provides a big fat warning message about that -- you're advised to heed it.
Instead of automatic installation, do the following (as described in the README.txt file that comes with Armadillo):
Manually modify include/armadillo_bits/config.hpp to enable the use of BLAS and LAPACK. In other words, make sure that ARMA_USE_BLAS and ARMA_USE_LAPACK are uncommented (enabled).
Also within include/armadillo_bits/config.hpp, disable ARMA_USE_WRAPPER, ie. make sure it's commented out.
When compiling your C++ programs, tell your compiler to use the armadillo include folder directly, and link with openblas. For example, with gcc use the -I switch to specify the include folder.
Im learning c++ and I compile from the command line. I have a problem when it comes to trying to add 3rd party libraries. I cant seam to figure out the linker system. Does anyone know a good tutorial or something like that?
For example I want to play around with the SDL2 library and ill use a command like this.
c++ -I/Library/Frameworks/SDL2.framework/Headers -L/Library/Frameworks/SDL2.framework/ -lSDL2 helloworld.cpp
and I get the error ld: library not found for -lSDL2
You need to put the linking flags last on the line:
g++ -I/Library/Frameworks/SDL2.framework/Headers helloworld.cpp -L/Library/Frameworks/SDL2.framework/ -lSDL2
I found out the answer. The following command compiled correctly. The include statement had to be changed to...
#include<SDL2/SDL.h>
and the correct compile command is...
c++ -o helloworld helloWorld.cpp -framework SDL2
I could also have used g++. On my system both c++ and g++ are symlinks to the same gnu compiler which happens to be the latest version I have installed on the system.
the option -L is a unix linker option and does not work on a MAC. The dev's for GCC were kind enough to include MAC specific linker options in the form of -framework. These serve to follow the mac tradition of how and where they like to store libraries. You can link several frameworks together by separating them with a comma. So for example i could also do -framework SDL2,SDL2_mixer as long as my source has
#include<SDL2_mixer/SDL_mixer.h>
When compiling this default search location for libraries is /Library/Frameworks. The include statement is cross platform compatable and the mac gnu linker knows that if I say
#include<SDL2/SDL.h>
that that header will be found at /Library/Frameworks/SDL2.framework/Headers
The -IPATH option still works on mac and can be used to pass alternate search locations for header and source files just like it works in unix.
I am trying to install a C++ library (armadillo) in a unix cluster where I do not have root permissions.
I managed to compile the C++ libraries without user permissions by running the following make command:
make install DESTDIR=my_usr_dir
But then in the armadillo readme file it says:
where "my_usr_dir" is for storing C++ headers and library files. Make sure your C++ compiler is configured to use the sub-directories present within this directory.
The compiler the armadillo uses to install the libraries is gcc-4.8.1. I am not sure where the compiler was installed but it's loaded when I start my session in the unix cluster.
After installing armadillo I am trying to compile open source code that uses the armadillo libraries. This open source code also has a makefile.
However, when I go to the open source code and I type in:
make
it calls g++. How can I make sure g++ will recognize the armadillo libraries previously installed in my_usr_dir?
Currently I get the following error if I go to src and then type make:
opencode.cpp:28:21: fatal error: armadillo: No such file or directory
#include <armadillo>
^
compilation terminated.
make: *** [mmcollapse] Error 1
you can use
alias gcc="gcc -I./my_usr_dir/include -L./my_usr_dir/lib"
and so on in your .bashrc file. In that way, whenever you invoke gcc on the command line, the flags will be added before every other argument you enter on the command line
I think the readme file refers to the usage of the library headers and library files from applications. For those to be useful, the compiler/linker/loader (usually all driven by the "compiler") have to know where to find them. The compiler always looks in some default directories, such as /usr/include (for headers) and /usr/lib/ (for libraries), but they require root permission to write into. However, you can tell the compiler with the flag -Idirectory to search in directory directory for headers. For libraries use -l and -L (check the manual page of your compiler). You may also need to consider the LD_LIBRARY_PATH and LD_RUN_PATH environment variables, if you're using dynamic linking (shared object files).
This question looks similar to
How to specify non-default shared-library path in GCC Linux? Getting "error while loading shared libraries" when running
If you dont want to change the .bashrc
use -rpath as suggested in the post above.
gcc XXX.c -o xxx.out -Lmy_usr_dir -lXX -Wl,-rpath=my_usr_dir
-L is for static linking
-rpath for adding the directory to the linker search path
more on -rpath here
I don't understand -Wl,-rpath -Wl,
Dont bother to upvote the answer because this is really not an answer. I would have commented but i could not locate the add comment for your post.
I wrote a small project using C++, OpenCV 2.2 and g++ in Ubuntu 11.04. I need to make a library (.so would be better), but I want it to run on the other computer, without OpenCV installed.
I've tried to build dynamic library using -shared and -fPIC flags for g++, and copied OpenCV .so libs to the working directory. Actually I need only core and feature2d, but actually it requested lot's of other libs, including highgui, which also has many dependencies.
I tried static linking, using -Wl,-Bstatic flags, but also unsuccessfully.
Did someone has the same problems? I would appreciate any kind of help.
It is possible to build OpenCV without dependencies from system libraries. To turn of all the dependencies for OpenCV 2.2 on Linux you can run cmake with following arguments:
cmake -DWITH_1394=OFF -DWITH_CUDA=OFF -DWITH_EIGEN2=OFF -DWITH_FFMPEG=OFF -DWITH_GSTREAMER=OFF -DWITH_GTK=OFF -DWITH_OPENEXR=OFF -DWITH_PVAPI=OFF -DWITH_QT=OFF -DWITH_TBB=OFF -DWITH_UNICAP=OFF -DWITH_V4L=OFF -DWITH_XINE=OFF -DUSE_IPP=OFF -DOPENCV_BUILD_3RDPARTY_LIBS=ON ..
But in this case you will not be able to use many of functions form highgui module:
video reading and writing
working with camera
all functions working with GUI (like imshow)