CMake on ubuntu is giving me the following error
CMake Error at blah/CMakeLists.txt:19 (ADD_LIBRARY)
Cannot find source file:
/usr/lib/libQtGui.so
The relevant part of CMakeLists.txt is this
FIND_PACKAGE (Qt4 REQUIRED)
INCLUDE(${QT_USE_FILE})
INCLUDE_DIRECTORIES (${QT_INCLUDES})
QT4_WRAP_CPP (QT_SRCS ${HEADERS})
ADD_LIBRARY (blah ${CPP} ${QT_SRCS} ${QT_LIBRARIES})
A little investigation shows that libQtGui.so and its friends live in /usr/lib/i386-linux-gnu (which is correct) instead of /usr/lib as CMake thinks it does.
This build environment worked fine a few months ago. No source or config files have changed, but the software packages have been routinely updated.
What has changed? How can I fix this?
As noted in the answer to this question, the problem is that Ubuntu 12.04 installs libraries to nonstandard paths.
The fix is
export LIBRARY_PATH=/usr/lib/i386-linux-gnu/
export C_INCLUDE_PATH=/usr/include/i386-linux-gnu
export CPLUS_INCLUDE_PATH=/usr/include/i386-linux-gnu
Related
I am trying to install HHVM on an Ubunut 14.04 machine using this guide:
https://docs.hhvm.com/hhvm/installation/building-from-source#ubuntu-15.04-vivid
However, when running the cmake -DMYSQL_UNIX_SOCK_ADDR=/var/run/mysqld/mysqld.sock . step i am retuned an error like this:
CMake Error in third-party/CMakeLists.txt:
Cannot find source file:
INTERFACE
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
CMake Warning (dev) in third-party/CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface. Run "cmake --help-policy CMP0022" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.
Target "boost" has an INTERFACE_LINK_LIBRARIES property. This should be
preferred as the source of the link interface for this library but because
CMP0022 is not set CMake is ignoring the property and using the link
implementation as the link interface instead.
INTERFACE_LINK_LIBRARIES:
/usr/lib/x86_64-linux-gnu/libboost_context.so;/usr/lib/x86_64-linux-gnu/libboost_filesystem.so;/usr/lib/x86_64-linux-gnu/libboost_program_options.so;/usr/lib/x86_64-linux-gnu/libboost_regex.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libpthread.so
Link implementation:
(empty)
This warning is for project developers. Use -Wno-dev to suppress it.
-- Configuring incomplete, errors occurred!
See also "/home/mihai/hhvm/CMakeFiles/CMakeOutput.log".
See also "/home/mihai/hhvm/CMakeFiles/CMakeError.log".
This issue is not happening on an Ubuntu 16.04 machine. I have searched up and down for a solution and found nothing.
Thank you,
Mihai
I suspect that you need a newer version of cmake. It looks like the add_library(name INTERFACE ...) command was added some time after v2.8.12 (which is what ships with ubuntu 14.04).
I wasnt't sure whether to put it on StackOverflow or AskUbuntu, but decided to post it here.
I have a problem building my app. I'm using CMake for building and one of the PkgConfig packages it depends on is linux. And when I'm trying to build it, it shows this error:
-- package 'linux' not found
When I'm removing the linux package from the dependencies, it complains about some Vala libraries isn't found. And the only way it is working is removing linux from the dependencies, then running cmake, then putting it to the dependencies again, then running make, then everything works fine (I don't know why).
I suppose I don't have some Ubuntu package installed and I don't have linux*.pc file, but I can't figure out what to do with it.
Can you help me with it?
UPD: Here is part of my CMakeFiles.txt file that raises the error:
find_package (PkgConfig)
message(STATUS "PKG_CONFIG_PATH: \"" ${PKG_CONFIG_PATH}\")
set (CORE_PKG
linux
gstreamer-1.0
gtk+-3.0
glib-2.0>=2.32
gio-2.0
json-glib-1.0
webkit2gtk-4.0>=2.6.1
libxml-2.0
gdk-x11-3.0
gstreamer-video-1.0
libnotify
libsoup-2.4
gee-0.8
)
pkg_check_modules (CORE_DEPS REQUIRED ${CORE_PKG})
I have a working cross-compiler toolchain, thanks to crosstool-ng :) -- however, crosstool-ng is very sparsely documented, and I am brand new to cross-compiling. The specific host and target are not, I think, important in this context.
I have some basic questions about the directory structure. The toolchain was installed into a directory named after the target. Inside that are a set of directories:
arm-unknown-linux-gnueabi
bin
include
lib
libexec
share
I presume this is for the actual cross-compiler bits, since the compilers in bin/ do work for this purpose. Notice that there is an inner arm-unknown-linux-gnueabi/ directory, ie, the path in there is ../arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi. Inside that there is another tree:
bin
debug-root
include
lib
lib32
lib64
sysroot
The lib* directories are symlinks into sysroot/. The stuff in bin seems to be the same set of cross-compile tools as in the parent directory /bin:
> bin/gcc -v
Using built-in specs.
COLLECT_GCC=./gcc
Target: arm-unknown-linux-gnueabi
Configured with: /usr/x-tool/.build/src/gcc-4.7.2/configure
--build=x86_64-build_unknown-linux-gnu
--host=x86_64-build_unknown-linux-gnu
--target=arm-unknown-linux-gnueabi
So my first question is: what are these for? And what is this directory for?
My second question then is: how should sysroot/ be used? It's apparently for support libraries native to the target platform, so I presume if I were building such a library I should use that as the --prefix, although it would amount to the same thing as using the parent directory, since lib* is symlinked...this "directory in the middle" with a bin and symlinks down to sysroot is confusing. I believe (some) autotools style packages can be configured "--with-sysroot". What is the significance of that, if I see it, and how should it be used in relation to other options such as --prefix, etc?
For your first question, as toolchain installed directory:
bin/arm-unknown-linux-gnueabi-gcc
arm-unknown-linux-gnueabi/bin/gcc
They are the same, indeed hard links.
You can use arm-unknown-linux-gnueabi-gcc by CC=arm-unknown-linux-gnueabi-gcc, e.g.
export PATH=<toolchain installed dir>/bin:$PATH
CC=arm-unknown-linux-gnueabi-gcc ./configure
make
Or
export PATH=<toolchain installed dir>/arm-unknown-linux-gnueabi/bin:$PATH
./configure
make
I always used the first form, and I am not sure if the latter form works.
For your second question, in my experience, you don't need to concern about sysroot. cross-compiler will find the correct C header files in sysroot/usr/include automatically.
Except that you want to cross-compile some libraries and install them into sysroot, you can get it by
export PATH=<toolchain installed dir>/bin:$PATH
CC=arm-unknown-linux-gnueabi-gcc ./configure --prefix=<toolchain installed dir>/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot
make
make install
Starting at 38:39 of the talk Anatomy of Cross-Compilation Toolchains by Thomas Petazzoni, the speaker gives an in-depth walk through of the output directory structure.
I am trying to install atk-2.4.0 and I get the error:
'pkg-config --modversion glib-2.0' returned 2.32.3, but GLIB (2.26.1)
*** was found!
I also tried updating PKG_CONFIG_PATH to include the path of glib-2.0.pc but still same error appears. Could anyone help me how to find where 2.26.1 was installed I am relatively new to Ununtu? Thanks.
Posting comments as response:
From find /usr/ -iname "*glib*.pc" it is found that there .pc file related to glib is available in /usr/lib/pkgconfig & /usr/local/lib/pkgconfig. Checking the system package management it appears that version 2.26.1 is installed from the repositories. The path for installation of glib from repositories is generally /usr/lib (This may vary a bit in case of 64 bit systems wherein there are different folders for 32 bit & 64 bit libraries). Thus it appears that glib also has been installed from source (guessing by installation path /usr/local/lib) which of version 2.32.2. If you need version 2.32.2 set PKG_CONFIG_PATH to /usr/local/lib/pkgconfig & LD_LIBRARY_PATH to /usr/local/lib/
Hope this helps!
You have to synchronize you PKG_CONFIG_PATH and LD_LIBRARY_PATH environment variables. Assuming that your prefix is /usr/local the followings should be set:
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
LD_LIBRARY_PATH=/usr/local/lib
You may also need to set other variables to compile glib dependent softwares:
ACLOCAL_PATH=/usr/local/share/aclocal/
PATH=/usr/local/bin:$PATH
I experienced a (for me) strange behaviour today: Using QMake with the PkgConfig-options etc. I was able to link the opencv libraries, but then I switched to CMake using PkgConfig. Once I tried to build my software, the linker complained that it was not able to find the library libcvaux, which pkg-config returns asked to deliver the libraries for opencv (pkg-config --libs opencv).
In /usr/lib I found a libcvaux.so.{version}, but no "plain" entry libcvaux.so. So what I did was to create a symlink, and now it works.
Now I wonder why it worked before. Is there something to pass ld an option saying "use the newest version, and you get the version by looking at the numbers behind the so suffix"? Or is it more some kind of bug that the maintainers of the opencv package forgot to add this symlink? Because e.g. libcv or libhighgui have such symbolic links.
Thank you!
From the ldconfig manpage:
ldconfig checks the header and file
names of the libraries it encounters
when determining which versions should
have their links updated.
Maybe an earlier ldconfig run deleted the link.