I'm using macbook and terminal compiling gcc version 4.8.1. I solve some problem like:
fatal error ~~~~ No such file or directory
by adding such files in compile path myself. As far, those error was resolved by finding in finder application and add in root directory /usr/local/include/c++/4.8.1 myself.
But pthread.h does not exist at all my computer.
How can I get that header file?
Use this command:
gcc -I/usr/local/include/c++/4.8.1/... myfile.c -o myfile
-I indicate gcc to take include file from this specified path.
Related
I'm trying to use the GNU Prolog Compiler to build an executable from my Prolog program like so:
$ gplc solution.prolog -o prog
and it's failing with a really cryptic error:
error trying to execute as: No such file or directory
I can't figure out what it's trying to tell me is missing. Does anyone know?
I'm using Fedora Silverblue 37, and glpc is running inside of a 'toolbox' that is also Fedora 37.
The issue appears to have been that I didn't have a C compiler installed. I installed the gcc package, and got a different error:
gcc: fatal error: cannot read spec file ‘/usr/lib/rpm/redhat/redhat-hardened-ld’: No such file or directory
Apparently to get that file, I needed to install the redhat-rpm-config package. I found that package name from this relevant comment on the RedHat bugzilla.
Compilation succeeds now!
Although I can see that libhdf5.so.100 is actually inside /usr/local/lib, I receive the following error when running octave:
bash-4.3$ octave
/usr/local/bin/octave-cli-4.0.2: error while loading shared libraries: libhdf5.so.100: cannot open shared object file: No such file or directory
I built octave 4.0.2 myself.
I added the line /usr/local/lib to /etc/ld.so.conf and then ran sudo ldconfig. Problem solved.
I'm using software on Linux Ubuntu 14.04 64bit that uses gcc. I get errors about files or programs not being found like these:
cc: error trying to exec 'cc1': execvp: No such file or directory
or
fatal error: stddef.h: No such file or directory
However, when I do
gcc -print-search-dirs
I get many paths, and cc1 is on the first path in that list (/usr/lib/gcc/x86_64-linux-gnu/4.8/). I do not understand this.
Then I created a link to cc1 as follows (in /usr/bin):
sudo ln -s /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 cc1
Now the first error disappears, but I get the second error. Strange again, because I have this file /usr/lib/gcc/x86_64-linux-gnu/4.8/include/stddef.h which is again on the gcc search path.`
I'm not an expert in gcc at all, but this makes no sense to me. Thanks for your help.
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 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