I want to compile the GTK+ test program for the Vala programming language. I saved the code as main.vala and call the compiler with the command line
valac --pkg gtk+-3.0 main.vala
But this does not work. I get the error:
Package gobject-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gobject-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gobject-2.0' found
error: pkg-config exited with status 1
Why can't pkg-config find that package? When I call
pkg-config --list-all | grep gobject-2.0
I do not get an error, but
gobject-2.0 GObject - GLib type, Object, Parameter and Signal library
So my question is, why doesn't the program compile?
It's hard to figure out what is going on based on the information you've provided—you're probably going to have to figure it out yourself. I'll try to include some pointers here. A good place to start would be to set the PKG_CONFIG_DEBUG_SPEW environment variable…
The most likely cause is that some environment variables and/or the pkg-config being invoked are different. It's hard to say exactly how they might be different, but all valac is doing is invoking pkg-config.
In order to determine which pkg-config to execute, valac first looks for the --pkg-config command line option or, if that isn't present, the PKG_CONFIG environment variable (see compiler/valacompiler.vala for the logic). If that isn't present, it will just invoke pkg-config (that part is in codegen/valaccodecompiler.vala, the Vala.CCodeCompier.compile method).
From there, pkg-config takes over. The pkg-config man page explains how it searches for files; basically the PKG_CONFIG_PATH. Again, enabling debug spew would probably be the best place to start.
Related
First Method (export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH):
Based on this method, I can compile h5_crtdat.f90 through "gfortran h5_crtdat.f90 -fintrinsic-modules-path /usr/local/include -lhdf5_fortran" successfully. And I can run it as well.
Second Method (-Wl,-rpath):
Based on this method, I can compile h5_crtdat.f90 through "gfortran h5_crtdat.f90 -fintrinsic-modules-path /usr/local/include -lhdf5_fortran -Wl,-rpath,/usr/local/lib" successfully. However, after type in "./a.out" I got the following error
"./a.out: error while loading shared libraries: libhdf5.so.200: cannot open shared object file: No such file or directory".
Questions:
I have searched the google that these two methods can produce the same effect when linking shared library in gfortran compiler. Thus, I do not know why I will get the errors when the second method is used.
These two serve a different purpose.
LD_LIBRARY_PATH says where to search for shared libraries when executing some executable that has already been compiled and linked. It is possible, but not guaranteed, that some linker will alsonconsider this path for the actual linking, but there are other variables, like LIBRARY_PATH for that.
-Wl,-rpath says where to link shared libraries when building the executable. It has no effect when running the executable.
You must set LD_LIBRARY_PATH or some equivalent when running the executable so that the necessary libraries for the run can be located.
How do you find the default search path for include files for gfortran?
For gcc, a past Q&A showed this website:
https://gcc.gnu.org/onlinedocs/gcc-4.1.1/cpp/Search-Path.html#Search-Path
But,
I'm not sure if it applies to gfortran.
I don't think it always applies.
For example, on an Linux server, (for lack of any other method) I did this
strace gfortran try.f90 > tmp.txt 2>&1
and found this particular gfortran searches directories like
/opt/intel/compilers_and_libraries_2016.2.181/linux/ipp/lib/intel64/x86_64-redhat-linux/4.4.7/finclude
and it does not search /usr/include . Apparently, this particular gfortran came with the Intel Fortran compiler and was customized.
So, my question is, is strace the only way to know what the default search paths are? (I need to know this, because I'm remotely helping a friend. I don't have direct access to his machine.)
Update: I should have mentioned the -print-search-dirs option. It doesn't include the "include" search path:
gfortran -print-search-dirs | grep --color include
The output of -print-search-dirs doesn't include the directories which strace indicates in the above experiment of mine.
Update2: I've just found that the gfortran on ubuntu searches only /usr/lib/gcc/x86_64-linux-gnu/7/finclude. I'm surprised that it doesn't even search /usr/include. So far, it seems we have to use -I/usr/include whereas we don't need -L/usr/lib . . . Does somebody know the reason for this asymmetry?
Update3: The answer below shows how to list include search paths:
echo | gfortran -E -Wp,-v -
Unfortunately, this one lists the paths only of the preprocessor (for #include), not for the INCLUDE statement of the Fortran language.
You can verify this by looking into one of the directories which the preprocessor does search. For example, I found cpuid.h in one of them. So, I compared
include 'cpuid.h'
with
#include "cpuid.h"
in a Fortran source program. Of course, either causes error, but the error messages make it clear that in the former case, the file isn't found and in the latter, the include file is found and inserted into the source code and that caused compile error.
Incidentally, this exercise showed that on my Linux server, gfortran searches /usr/lib/gcc/ . . . /finclude among other directories whereas its preprocessor searches /usr/lib/gcc/ . . . /include , which kind of makes sense.
For me
gfortran -print-search-dirs
does the trick.
My version
gfortran --version
GNU Fortran (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
I don't use it often and not a FORTRAN expert, so hope this helps.
Update
I looked back on some old notes and found this incantation:
echo | gfortran -E -Wp,-v -
Perhaps this is more useful?
Good day,
I recently could install Lua 5.3 to /opt/lua53 on Centos 7
I also added the following line into /etc/bashrc
PATH=/opt/lua35/bin:$PATH
LD_LIBRARY_PATH=/opt/lua53/lib:$LD_LIBRARY_PATH
export PATH LD_LIBRARY_PATH
export LUA_INCLUDE_DIR=/opt/lua53/include
My colleague also install a software and when I compile by doing
make
I got the following errors
[root#pc6 jixie]# make
-- Release Build
-- Could NOT find Lua (missing: LUA_INCLUDE_DIR) (Required is at least version "5.2")
-- Could NOT find ZEROMQPP (missing: ZEROMQPP_LIBRARIES ZEROMQPP_INCLUDE_DIRS)
-- Could NOT find OPENVDB (missing: OPENVDB_LIBRARIES OPENVDB_INCLUDE_DIRS)
-- Downloading/updating kdtree
-- Configuring done
-- Generating done
I look into serveral thread but none of then could help me.
As I wrote, I added the following line
export LUA_INCLUDE_DIR=/opt/lua53/include
hoping it can provide the path to LUA_INCLUDE_DIR, but unfortunately I still get the same error.
Any idea how I can solve my problem? DO you need more information of my system?
NB: I am using cmake 3.10
PATH=/opt/lua35/bin:$PATH looks wrong: It should be /opt/lua53/bin.
You are re-inventing the wheel and making it square this time round...
If you have installed Lua development (package or from source) then there should be a package-config file named lua.pc placed at a location where cmake or configure can find it and enquire it as to what should the libs and cflags of any application requiring Lua include/libs. For my system, these files are usually located at /usr/lib64/pkgconfig/ and indeed lua.pc lives there with this content:
V= 5.3
R= 5.3.4
prefix= /usr
exec_prefix=${prefix}
libdir= /usr/lib64
includedir=${prefix}/include
Name: Lua
Description: An Extensible Extension Language
Version: ${R}
Requires:
Libs: -llua -lm -ldl
Cflags: -I${includedir}
The above file tells configure where the include dir is, and what's more important, what flags to use during compilation (-I... -L... -l...).
If you are on a system with a package manager (say yum, dnf, apt-get, etc.) then placing these pc files to their location is taken care of automatically if they exist in the package that is.
If you insist to do it the way you have done it above by hand-coding LUA_INCLUDE_DIR to your shell's environment, then make sure that LUA_INCLUDE_DIR points to an existing and valid location with valid content. Are you sure the include files required can be found in that dir? Maybe there is an extra dir in there?
A C extension module that compiles fine on Travis-CI without anaconda fails when installed with anaconda. It appears to install just fine, but when I try to import it, I get the following error:
ImportError: /home/travis/anaconda/lib/python2.7/site-packages/quaternion/numpy_quaternion.so: undefined symbol: __log_finite
The full error can be seen here. Obviously, this looks like a linker error, where it can't find glibc (which I believe is where __log_finite is found). But why should it fail to find glibc?
When I run nm on that .so file (through Travis), it shows that __log_finite is indeed undefined, but shouldn't it find it through the usual process?
I've tried installing quaternion through pip and I've tried installing it by directly downloading it and running python setup.py install. Both seem to work, in the sense that it looks like all the files are where they should be. But both fail on import because they can't find that symbol.
I've even tried installing the full version of anaconda (rather than just miniconda, which is recommended). Nothing seems to work. How can I make Travis find that symbol, and is this something I'll have to worry about ordinarily with my distribution?
It appears to be a problem with a -ffast-math flag in my quaternion package. One thing that flag does is make the code assume that the numbers are finite, so that instead of using the log function, it uses some log_finite function, which for some reason Travis doesn't have --- or something. Anyway, I have my numba package set an environment variable in Travis builds, which the quaternion package then looks for on installation, and turns off fast-math. This is unfortunate, because it means I'm not actually testing the code as it's actually used. But it means my code builds and tests pass.
There seems to be about one mention of this on the internet. Or not; I can't tell.
Recently I'm learning openCV. I followed the tutorial on openCV website.
http://docs.opencv.org/doc/tutorials/core/how_to_scan_images/how_to_scan_images.html#howtoscanimagesopencv
However, when I compile my code using following command
g++ loadImage.cpp -o loadImage
the command line shows:
fatal error: 'opencv2/core/core.hpp' file not found
#include <opencv2/core/core.hpp>
^
I installed openCV with brew, I think it is OK. Then I use emacs to edit and g++ compile my code directly, is that the problem? I searched some similar problems but they refer to xCode environment. Thanks for your help!
You need to tell g++ where it can find the header files. I recommend you setup either eclipse or any other IDE that can handle that stuff for you (like Qt Creator or many others). You can follow the setup guides for OpenCV for instructions, if needed.
[edit: note that I know that emacs can also be setup to handle things like include and library paths, but I have no idea how, hence my recommendation for a full scale IDE]
You can also specify the path to the includes on the command line with -I, then it should also work. Example:
g++ -I/path/to/OpenCV-2.4.9/build/include loadImage.cpp -o loadImage
There are environment variables you can set so you don't have to specify this for every call (see this page for a complete list, specifically CPATH and it's variants might be of interest.
So I find an answer myself, using cmake! How did I miss that..
http://docs.opencv.org/doc/tutorials/introduction/linux_gcc_cmake/linux_gcc_cmake.html#linux-gcc-usage