I have successfully built and installed the opencv lib. Now I am trying to use these libs in my application but I keep getting link errors. I am using:
pkg-config --libs opencv
When I run this on the command line I can see the output. It list a lot of libraries but not all of them are listed with the absolute path specified. For example, here is a partial output:
libippcc_l.a libippvm_l.a tbb rt pthread m dl /usr/lib/libXext.s stdc++
And when I build my app I get link errors. Here is a partial output:
g++: libipps_l.a: No such file or directory
g++: libippi_l.a: No such file or directory
g++: libippcv_l.a: No such file or directory
g++: libippcc_l.a: No such file or directory
g++: libippvm_l.a: No such file or directory
g++: tbb: No such file or directory
g++: rt: No such file or directory
g++: pthread: No such file or directory
g++: m: No such file or directory
g++: dl: No such file or directory
g++: stdc++: No such file or directory
It appears that the linker cannot resolve the libraries that do not include an absolute path which seems reasonable. But my confusion is why dosn't the output from pkg-config include the absolute path for all of its libs? When I do NOT use "pkg-config --libs opencv" on the build line, the libraries for intel ipp, pthread, m, stdc++, etc gets resolved properly and the app builds fine because I also have them specified on the link line as: "-lpthread -lstdc++" ... etc. These are positioned on the link line AFTER the I specify: "pkg --libs opencv"
But using "pkg-config --libs opencv" screws up the resolution.
I have run "ldconfig" from the command line to update all of the symbolic links in my libs directories but this did not resolve this problem.
Any help would be greatly appreciated.
If pkg-config --libs opencv is outputting that, then you have a problem. Maybe a previous installation of OpenCV broke it, or maybe you are not using a version recent enough, or maybe it wasn't compiled successfully, or maybe there's a problem with the newest version from the repository.
Anyway, I'm using OpenCV 2.3.1 on Mac OS X and pkg-config --libs opencv outputs the following info:
-L/usr/local/lib -lopencv_core -lopencv_imgproc -lopencv_highgui -lopencv_ml -lopencv_video -lopencv_features2d -lopencv_calib3d -lopencv_objdetect -lopencv_contrib -lopencv_legacy -lopencv_flann
You can try to compile your application by hand to see if anything else is broken:
g++ test.cpp -o test -I/usr/local/include/opencv -I/usr/local/include -L/usr/local/lib -lopencv_core -lopencv_imgproc -lopencv_highgui -lopencv_ml -lopencv_video -lopencv_features2d -lopencv_calib3d -lopencv_objdetect -lopencv_contrib -lopencv_legacy -lopencv_flann
Note that your install might have placed OpenCV headers and libraries in different directories.
I think that your problem may be related to the one I'm having, and the subject of this pull request to opencv. My guess is: you are installing from source on a linux machine? Does your situation change if you find your opencv.pc file (probably at /usr/local/lib/pkgconfig/opencv.pc), and add -l before the offending words there (rt pthread etc)?
NB: Installing from source will make a new (bad) opencv.pc that overwrites the one where you made the changes I'm suggesting, so if you go through more rebuild-install cycles, do remember to go fix up opencv.pc again before trying to rebuild your program.
This is caused - usually in my practice - by new CMake or a misbehaving one :) It's quite simple to solve - edit by hand opencv.pc and add missing "-l" prefixes to the names. That's it! All other problems are disappearing after this fix. Second usual trouble is the PKG_CONFIG_PATH itself - add it in your shell GLOBAL(!!) profile script and re-launch the shell and verify it via printenv command or something like that.
You can try searching for "opencv.pc" to find the path. For me, the package was in
/Applications/opencv-2.4.11/build/unix-install/
Thus, for me the command that worked was:
pkg-config --libs /Applications/opencv-2.4.11/build/unix-install/opencv.pc
Related
I tried to compile my context.c file with "gcc $(pkg-config --cflags --libs glib-2.0)" context.c.
But it doesn't work because it does not find galloca header file:
context.c:3:10: fatal error: galloca.h: file or directory not found #include <galloca.h>
I tried "gcc $(pkg-config --cflags --libs glib-2.0 glib)" where galloca.h is located /usr/include/glib-2.0/glib. But after adding glib to the compile command, it does not even find glib.h anymore, which is in /usr/include/glib-2.0.
I tried to add the all necessary paths to PKG_CONFIG_PATH with "export PKG_CONFIG_PATH=/usr/include/glib-2.0/gio/pkgconfig" and so on.... without success.
I also added all necessary library paths to /etc/ld.so.conf and sudo ldconfig -v, also without success.
It is not the first time i face the problem, that necessary libraries can't be found on this system while compiling, but as we in germany say: "i am at the end of my latin", so i have no more clue how to solve this issue and would be gratfull for any help.
Thanks in advance.
PS: I use a raspberry pi 4B 8GB and raspbian linux.
Your library path will not help it to find include file.
Maybe you want -I/usr/include/glib-2.0 -I/usr/include/glib-2.0/glib
Maybe your build script accept CFLAGS environment variable where you can put this option.
Or maybe you change (edit) source code,
#include <galloca.h>
become
#include <glib/galloca.h>
because already it looks correctly in /usr/include/glib-2.0, only the subdirectory is wrong
Afterwards you discover if you must set some path also for libraries. But one thing by one, first compile, then worry about the link. You talk about ld.so.conf. Really this is for runtime, but OK, at build it is last option after trying everything else (see at man ld and search ld.so.conf). Really for build time library path you want -L option maybe with LDFLAGS environment variable. But as I say, first try compile and then discover if link problem.
Wer mit seinem Latein am Ende ist, muss Griechisch sprechen.
While trying to build Aseprite on Debian 10 (amd64) virtualbox VM, after building Skia, the ninja aseprite command returns the error:
/usr/bin/ld: cannot find -lSKIA_OPENGL_LIBRARY-NOTFOUND
[1/1] Linking CXX executable bin/aseprite
FAILED: bin/aseprite
: && /usr/bin/c++ -Wall -Wno-switch -O2 -g -DNDEBUG src/CMakeFiles/aseprite.dir/main/main.cpp.o -o bin/aseprite lib/libapp-lib.a lib/libclip.a -lxcb -lpthread lib/libdio-lib.a lib/libfilters-lib.a lib/libflic-lib.a lib/libtga-lib.a lib/librender-lib.a lib/libdoc-lib.a lib/libfixmath-lib.a lib/libui-lib.a lib/liblaf-os.a lib/liblaf-gfx.a lib/liblaf-ft.a /root/deps/skia/out/Release-x64/libskia.a -lSKIA_OPENGL_LIBRARY-NOTFOUND /usr/lib/x86_64-linux-gnu/libfontconfig.so /usr/lib/x86_64-linux-gnu/libX11.so /usr/lib/x86_64-linux-gnu/libXext.so /usr/lib/x86_64-linux-gnu/libXcursor.so /root/deps/skia/out/Release-x64/libskshaper.a lib/libobs.a lib/libundo.a lib/libcmark.a lib/libjpeg.a lib/libgiflib.a lib/libwebpdemux.a lib/libwebpmux.a lib/libwebp.a -lpthread -lm lib/libfreetype.a lib/libharfbuzz.a lib/libfreetype.a lib/libharfbuzz.a lib/libpng16.a -lm lib/libjson11.a lib/libarchive.a /usr/lib/x86_64-linux-gnu/libcrypto.so /usr/lib/x86_64-linux-gnu/libexpat.so /usr/lib/x86_64-linux-gnu/libssl.so lib/libfmt.a lib/libtinyexpr.a lib/liblauxlib.a lib/liblua.a lib/liblualib.a lib/libupdater-lib.a lib/libcfg-lib.a lib/libver-lib.a lib/libtinyxml.a lib/libnet-lib.a lib/liblaf-base.a lib/libmodpbase64.a /usr/lib/x86_64-linux-gnu/libdl.so lib/libcurl.a lib/libz.a -ldl && :
/usr/bin/ld: cannot find -lSKIA_OPENGL_LIBRARY-NOTFOUND
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
How may I solve this?
It appears that CMake is looking for OpenGL and failing... Aseprite doesn't seem to use OpenGL anyway, so disabling that altogether by clearing the cache variable SKIA_OPENGL_LIBRARY should work:
cd aseprite/build
cmake -DSKIA_OPENGL_LIBRARY="" ..
ninja aseprite
I have tested it on Windows, but I'm not entirely sure if it will work on Linux...
For anyone still looking for an answer to this. I got it to build on Ubuntu 20.04.
Follow the instructions to build skia over at the skia git repository. Make a note of which folder you cloned the repository into, you will need it later. I tried using the pre-built binaries but I must have been doing something wrong and could just never get it work.
When the build is complete you will see a note about 32-byte alignment, and if you check the out\Release-x64 folder you will see a libskia.a file. Now you know that skia was built succesfully.
Install the aseprite linux build dependencies with sudo apt-get install -y g++ cmake ninja-build libx11-dev libxcursor-dev libxi-dev libgl1-mesa-dev libfontconfig1-dev. You will find these instructions at the aseprite git repository.
Follow the instruction further down that page for the linux install but pay attention to the parameters you need to change regarding the location of that libskia.a file mentioned in point 2.
Before you start building (and why you're here) you need to enter #Ben_'s command given above to unlink the dependency to OPENGL (cmake -DSKIA_OPENGL_LIBRARY="" ..)
Now proceed to build aseprite with as the rest of the build instructions given on its repo page with ninja aseprite
Now go to aseprite/build/bin and find the aseprite executable.
You can copy this bin folder to another folder, and run aseprite from there. You can then delete all of the sources you downloaded.
There will be a bunch of errors during the python step, and you'll notice it complains about not being able to find some repositories, I think common.git is one of them. You may safely ignore this warning.
If you want to keep supporting development of the application I do recommend you spend whatever it costs for a license (but it's totally legal to build your own copy like this).
I am trying to make the PCA-SIFT code (pcasift-0.91nd.tar.gz) in this webpage: http://www.cs.cmu.edu/~yke/pcasift/. After running ./configure which is OK, the make command report that the C compiler can not find header pgm.h:
image.cc:18:22: fatal error: pgm.h: No such file or directory
#include
^ compilation terminated.
There is a webpage in internet which discussed this issue: http://ubuntuforums.org/showthread.php?t=1918422. A solution was stated at the end:
Apparently, the header files are in the directory /usr/include/pgm-5.1
- the preferred way to get this into your include directories when compiling is to use pkgconfig. You will need to add something like
pkg-config --cflags openpgm-5.1 at the end of your compilation
command to get the right headers and add pkg-config --libs
openpgm-5.1 to your linking command.
, but I cannot understand it. Specifically, what does "add pkg-config --cflags openpgm-5.1 at the end of your compilation command" mean? What should I do, to add pkg-config --cflags openpgm-5.1 literally or the results this command returns in terminal? And add to what file? The Makefile is generated by ./configure. Should I add to Makefile or ./configure? I have successfully install libpgm-dev and they are really in /usr/include/pgm-5.1. The command pkg-config --cflags openpgm-5.1 returns -I/usr/include/pgm-5.1 -I/usr/lib/x86_64-linux-gnu/pgm-5.1/include and command pkg-config --libs openpgm-5.1 returns -lpgm -lpthread -lm.
Since that thread was closed, I have to ask here. Hoping someone familiar with Linux compiling process could help me with this issue. Thanks a lot.
I solved the problem myself.
Everything in the ubuntuforums.org webpage mentioned in the original question is wrong; that's why I met with so many problems.
Wrong 1: It's wrong to install libpgm-dev using sudo apt-get install libpgm-dev.
We should download Netpbm, and run the following command after uncompression:
./configure //type none on prompt if you don't have JPEG, TIFF, etc. libraries
make
sudo make package pkgdir=netpbmpkg
sudo ./installnetpbm
sudo rm -f -r /netpbmpkg/
Then Netpbm is installed on Ubuntu.
Wrong 2. The include path returned by pkg-config --cflags is wrong
By default, The include path shold be /usr/local/netpbm/include and the lib path is /usr/local/netpbm/lib.
Wrong 3. The linking option -lpgm returned by pkg-config --libs is wrong
The correct linking option should be -lnetpbm.
Following the right way, I can successfully compile the project in Netbeans (forget about command line make).
The problem I faced has been solved here:
Loading shared library in open-mpi/ mpi-run
I know not how, setting LD_LIBRARY_PATH or specifying -x LD_LIBRARY_PATH fixes the problem, when my installation itself specifies the necessary -L arguments. My installation is in ~/mpi/
I have also included my compile-link configs.
$ mpic++ -showme:version
mpic++: Open MPI 1.6.3 (Language: C++)
$ mpic++ -showme
g++ -I/home/vigneshwaren/mpi/include -pthread -L/home/vigneshwaren/mpi/lib
-lmpi_cxx -lmpi -ldl -lm -Wl,--export-dynamic -lrt -lnsl -lutil -lm -ldl
$ mpic++ -showme:libdirs
/home/vigneshwaren/mpi/lib
$ mpic++ -showme:libs
mpi_cxx mpi dl m rt nsl util m dl % Notice mpi_cxx here %
When I compiled with mpic++ <file> and ran with mpirun a.out I got a (shared library) linker error
error while loading shared libraries: libmpi_cxx.so.1:
cannot open shared object file: No such file or directory
The error has been fixed by setting LD_LIBRARY_PATH. The question is how and why? What am i missing? Why is LD_LIBRARY_PATH required when my installation looks just fine.
libdl, libm, librt, libnsl and libutil are all essential system-wide libraries and they come as part of the very basic OS installation. libmpi and libmpi_cxx are part of the Open MPI installation and in your case are located in a non-standard location that must be explicitly included in the linker search path LD_LIBRARY_PATH.
It is possible to modify the configuration of the Open MPI compiler wrappers and make them pass the -rpath option to the linker. -rpath takes a library path and appends its to a list, stored inside the executable file, which tells the runtime link editor (a.k.a. the dynamic linker) where to search for libraries before it consults the LD_LIBRARY_PATH variable. For example, in your case the following option would suffice:
-Wl,-rpath,/home/vigneshwaren/mpi/lib
This would embed the path to the Open MPI libraries inside the executable and it would not matter if that path is part of LD_LIBRARY_PATH at run time or not.
To make the corresponding wrapper add that option to the list of compiler flags, you would have to modify the mpiXX-wrapper-data.txt file (where XX is cc, c++, CC, f90, etc.), located in mpi/share/openmpi/. For example, to make mpicc pass the option, you would have to modify /home/vigneshwaren/mpi/share/openmpi/mpicc-wrapper-data.txt and add the following to the line that starts with linker_flags=:
linker_flags= ... -Wl,-rpath,${prefix}/lib
${prefix} is automatically expanded by the wrapper to the current Open MPI installation path.
In my case, I just simply appends
export LD_LIBRARY_PATH=/PATH_TO_openmpi-version/lib:$LD_LIBRARY_PATH
For example
export LD_LIBRARY_PATH=/usr/local/openmpi-1.8.1/lib:$LD_LIBRARY_PATH
into $HOME/.bashrc file and then source it to active again source $HOME/.bashrc.
I installed mpich 3.2 using the following command on Ubuntu.
sudo apt-get install mpich
When I tried to run the mpi process using mpiexec, I got the same error.
/home/node1/examples/.libs/lt-cpi: error while loading shared libraries: libmpi.so.0: cannot open shared object file: No such file or directory
Configuring LD_LIBRARY_PATH didn't fix my problem.
I did a search for the file 'libmpi.so.0' on my machine but couldn't find it. Took me some time to figure out that 'libmpi.so.0' file is named as 'libmpi.so' on my machine. So I renamed it to 'libmpi.so.0'.
It solved my problem!
If you are having the same problem and you installed the library through apt-get, then do the following.
The file 'libmpi.so' should be in the location '/usr/lib/'. Rename the file to 'libmpi.so.0'
mv /usr/lib/libmpi.so /usr/lib/libmpi.so.0
After that MPI jobs should run without any problem.
If 'libmpi.so' is not found in '/usr/lib', you can get its location using the following command.
whereis libmpi.so
first, run this command
$ sudo apt-get install libcr-dev
if still have this problem then configure LD_LIBRARY_PATH like this:
export LD_LIBRARY_PATH=/usr/local/mpich-3.2.1/lib:$LD_LIBRARY_PATH
then add it to ~/.bashrc before this line:
[ -z "$PS1" ] && return
Simply running
$ ldconfig
appears to me as a better way to solve the problem (taken from a comment on this question). In particular, since it avoids misuse of the LD_LIBRARY_PATH environment variable. See here and here, for why I believe it's misused to solve the problem at hand.
I am attempting to install an application. During compilation it fails with the following error:
/usr/bin/ld: cannot find -lemu
I have installed the libemu library, and it now currently resides in /opt/libemu/. However, when I try and compile my application the library is not found. Is there any way to correct this?
EDIT: It also looks like the make is resulting in:
It also looks like the make file is compiling with the following:
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.6/libemu_module.o
-L/opt/libemu/lib -lemu -o build/lib.linux-x86_64-2.6/libemu.so
I have tried setting my LD_LIBRARY_PATH to /opt/libemu, still doesn't work - fails with the error mentioned above.
You need to tell the linker where it is:
gcc stuff -L/opt/libemu -lemu
or:
gcc stuff /opt/libemu/libemu.a
where stuff is your normal compile/link options files etc.
You can also specify library paths in the LIBRARY_PATH environment variable:
LIBRARY_PATH=/opt/libemu
export LIBRARY_PATH
before you run your build. Yet another option is to see where gcc looks for libraries by running:
gcc --print-search-dirs
and put your library in one of the listed directories.
Edit: It is really not clear from your latest info what you are trying to build. Are you trying to turn a static library into a shared library? Most important - What is the exact filename of the library file you have copied into the /opt/libemu directory?
The environment variable LD_LIBRARY_PATH should include (but probably does not by default) /opt/libemu.
try running:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/libemu
make install