In my CMakeLists.txt
include (CheckFunctionExists.cmake)
When I run ccmake (I am following the official tutorial)
CMake Error at CMakeLists.txt:10 (include):
include could not find load file:
CheckFunctionExists.cmake
However, I have the file specified:
sw3#pc90313-sw3:~/learn_cmake/build$ find / -name CheckFunctionExists.cmake 2>/dev/null
/usr/share/cmake-2.8/Modules/CheckFunctionExists.cmake
I am using a cmake installation form the Ubuntu 13.04 repository:
sw3#pc90313-sw3:~/learn_cmake/build$ cmake --version
cmake version 2.8.10.1
If the absolute path is specified, everything works out well and a working makefile is generated. However, this workaround is far from ideal (and diverges from the tutorial). Where could the problem be?
The path is called ${CMAKE_ROOT}. So the proper include command for system files is
include (${CMAKE_ROOT}/Modules/CheckFunctionExists.cmake)
, mentioned later in the tutorial.
Related
I build sample code with cross compile linaro. I have two situations
Situation 1:
I download gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf from linaro website and extract it to path /home/xxx/opt/toolchains. I also
export
PATH=$PATH:/home/xxx/opt/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf/bin
Then i use eclipse for testing some simple example codes with Cross Settings /home/xxx/opt/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf/bin. But when i compile, i get this error.
/home/xxx/opt/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.5.0/../../../../arm-linux-gnueabihf/bin/ld:
cannot find crt1.o: No such file or directory
/home/xxx/opt/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.5.0/../../../../arm-linux-gnueabihf/bin/ld:
cannot find crti.o: No such file or directory
I found and know that crti.o and crt1.o in /home/xxx/opt/toolchains/gcc-linaro-5.5.0-2017.10-x86_64_arm-linux-gnueabihf/arm-linux-gnueabihf/libc/usr/lib.
Situation 2:
When i follow another way. The first, i install
sudo apt-get install gcc-arm-linux-gnueabihf
Then in eclipse path of Cross Settings i config /usr/bin/ and build. Everything is OK.
So with situation 1, How I setup correctly in Eclipse? Thank for your support.
I just installed Cmake from git clone wget http://www.cmake.org/files/v2.8/cmake-2.8.3.tar.gz in a new folder on a Linux server. The compilation worked but cmake command is not recognized from other paths. Should I copy the entire contents of cmake-2.8.0 folder to usr/local/bin? Or is the contents of bin folder that need to be copied?
Thanks
On Linux and other Unix-based systems, a common arrangement is to install packages to /opt and add relevant entries to the PATH environment variable to make them available. This is intended for packages not provided by the native package manager or distribution. By choosing an appropriate directory structure, this can be done in a way which also allows different versions to be installed simultaneously and the user can pick which one they want by adding the relevant directory to the PATH.
For the specific case of CMake asked about in the question, you can use a directory structure like /opt/cmake/<version> and then add the relevant /opt/cmake/<version>/bin directory to your PATH (e.g. /opt/cmake/3.8.2/bin for the 3.8.2 CMake release). You can even just download the official pre-built CMake tarballs, unpack them and move the top level directory into the /opt/cmake area as the particular version you downloaded. I've used this successfully on Linux, MacOS and Solaris, as I'm sure have many others.
Note that once you've run CMake on a particular source tree, the cmake executable doesn't need to be on the PATH any more. If cmake needs to be re-run, the build will do so itself and it records the full path to the cmake executable in its own cache, so the PATH isn't even consulted (this is essential in ensuring the same version of CMake continues to be used for all builds regardless of the PATH, since PATH can change between login sessions, etc.). You would only need cmake on your PATH if you intend to invoke cmake manually or for the first time you run it on a source tree, but in both of these cases you can always just use the full path to the cmake executable if you preferred.
I should also add that the entire set of files provided in the CMake package are required, not just the bin directory. CMake makes extensive use of files in its other directories, such as the various modules it comes with. If you are building CMake from source, you may want to build the package target so you get a relocatable tarball or similar which will contain everything that should be included when you provide a CMake package on your system.
After the build, use 'sudo make install'. This will make sure the correct libraries and binaries are copied to their proper places.
Usually this will install the binary to /usr/local/bin.
Make sure the PATH variable has this included.
sudo make install did not copy to /usr/local/bin/ for some reason, so I copied the content of CMAKE /bin. to usr/local/bin an it worked.
cp –a bin/. /usr/local/bin/
When I tried to run an installer that uses GLEW as one of its dependencies, I got:
fatal error: GL/glew.h: No such file or directory
Downloaded glew1.10 from the official site and installed according to given instructions.
After that I got the same error again- did some research and copied glew.h to /usr/include/GL/glew.h. Ran the installer again and this time got:
/usr/bin/ld: error: cannot find -lGLEW
To my understanding this is a a common error in Linux for many projects and many libraries, probably I should copy some files from the source folder or add some path to an environment variable, what should i do?
I know that there are apt-get packages- libglew1.6-dev and libglew1.6, but its built upon glew1.6, which works but is probably out-dated for what i'm trying to build.
The automatic installer is node.js's npm, and what causes this error is trying to install node-webgl module.
Solved.
As it turned out, the installation seems to have placed the needed files inside /usr/lib64, and the linker searched for those files inside /usr/lib/ which probably is the right behavior in most cases.
Since i'm not familiar with node.js's npm (and with linking in general), my fix was as follows:
sudo cp /usr/lib64/libGLEW* /usr/lib/
sudo cp /usr/lib64/pkgconfig/* /usr/lib/pkgconfig/
Meaning, I reconstructed the same hirarchy inside the /usr/lib folder. This is probably not a best practice, but it works.
I am using Debian OS and I'm trying to point to cmake where is my Qt4.
I try to build qjson library and with its CMakeLists.txt:
http://pastebin.com/fKNp0Qgy
I get:
Qt5 not found, searching for Qt4
qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such file or directory
CMake Error at /usr/share/cmake-2.8/Modules/FindQt4.cmake:1386 (message):
Found unsuitable Qt version "" from NOTFOUND, this code requires Qt 4.x
Call Stack (most recent call first):
CMakeLists.txt:55 (FIND_PACKAGE)
-- Configuring incomplete, errors occurred!
I'm not familiar with CMake and Qt config, but I'm curious what setting force CMake FIND_PACKAGE to look into '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake' for qmake.
I have installed Qt 4.8.5 from source and I have Qt4 bin folder in completely different directory.
just try "sudo apt-get install qt-sdk" it works for me
I solved my problem.
Looking for QT_SELECT with grep command I found that QT_SELECT is related to /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf file. From the "default" file name I assumed that it is what is seen as QT_SELECT. Other configs presented with qtchooser -l are in /usr/share/qtchooser/ and /usr/lib/x86_64-linux-gnu/qtchooser directories.
Such a config file has two lines with paths. I just changed these lines, first pointing to my Qt bin directory and second pointing to my Qt lib directory. Then I could see that qtchooser -print-env shows QTTOOLDIR and QTLIBDIR to my Qt.
Then I could easily build qjson library with CMake, Qt4 was found correctly.
In my experience, this problem is most easily solved by putting the folder containing qmake in your PATH environment variable.
Here is the answers
https://askubuntu.com/questions/540746/ubuntu-14-04-qt5-development-libraries/540757#540757
Seems
apt-file search Qt5CoreConfig.cmake was what I was missing. This got me:
qtbase5-dev: /usr/lib/x86_64-linux-gnu/cmake/Qt5Core/Qt5CoreConfig.cmake
Installing that seems to lead to CMake finding Qt5. qmake still reports the same problem when directly called though...some remnant from qt4 still installed it seems...
As for the qmake problem, this is fixed by:
sudo apt-get install qt5-default
In my case it was just that qtchooser was missing the "default" configuration.
I figured cmake is just executing qtchooser and looking for a "default" configuration file name.
You can install any configuration file by doing the following:
qtchooser -install <arbitrary_name> <path_to_qmake>
In my case I simply provided "default" as the arbitrary name... this created the default.conf file in the appropriate locations and all is well. I don't think there is a limit to how many named versions of qt you have.
If you do this as root it should work for all users.
On my old RHEL distro, this did it for me:
sudo yum install qt-devel.x86_64
Just the qt-base one wouldn't work with cmake.
1) Where is your qtchooser configuration file?
$: locate qtchooser | grep conf
2) From the list of conf files, probably there is one call "default.conf"
This one is a link to one of the others (4.conf or qt4.conf or 5.conf or qt5.conf).
Choose the one that makes sense too you, and create a link to it.
Suppose your default file path is
/usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf
Create backup:
$: cd $(dirname /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf)
$: cp -av default.conf default.conf_backup
Let's say you target is
/usr/lib/x86_64-linux-gnu/qtchooser/qt5.conf
Then:
$: sudo ln -s /usr/lib/x86_64-linux-gnu/qtchooser/qt5.conf default.conf
3) Is the path to your qmake right?
Check qmake location
$: locate qmake | grep bin
Is the same one as indicated in your modified qtchooser/default.conf?
$: cat /usr/lib/x86_64-linux-gnu/qtchooser/qt5.conf
If the answer is YES, then you are done.
If the anser is no, then you need to modify the file:
Create backup:
$: cd $(dirname /usr/lib/x86_64-linux-gnu/qtchooser/qt5.conf)
$: cp -av qt5.conf qt5.conf_backup
Edit file and change path to your qmake location
$ sudo vi qt5.conf
Now it should be done.
Simplest solution was add a link in the directory that the gem expected to find it. On Ubuntu 14.04 it qmake lives in /usr/bin. Simple solution.
I previously had some troubles updating old code that still needed a not supported compiler and expensive libraries to a version with gfortran in Eclipse on Windows. I let it rest for a while and recently I took a whole other approach, rebuilding the program from scratch, developping on a ubuntu machine, but now I want to bring it back to a windows machine so that my co-workers can contribute on it.
The status:
Program compiles, runs and gives good results on an ubuntu machine with the GCC GNU compiler
Windows 7 machine, 64bit
Cygwin installation (for gnu fortran) with lapack and liblapack-devel (however, I don't use these, because I compile blas and lapack manually)
(C:/cygwin/lib added to windows Path)
Original Issue:
The program compiles in cygwin (by calling the make-command, calling the make command with the makefile situated here: http://thijsvandenbrande.be/phd/hamfemInstall/makefile
This returns the file hamfem.exe which returns the following error when runned by double-clicking on it in windows: The program can't start because cyglapack-0.dll is missing from your computer. Try reinstalling the program to fix this problem.
When running the executable from cygwin, by calling the ./hamfem.exe command the executable starts to run. However, I want a solution so that I can give this executable to my co-workers so that they can change the input files (located in a folder in that has a relative path to the executable).
Going further on the comments below, I tried the next things:
Adding the exact path to the C:\cygwin\lib\lapack\cyglapack-0.dll file in windows path and even rebooting afterwards doesn't help.
adding a -static to the makefile before calling the library, resulting in dependency errors because I use two commands of the lapack library that depend on quite a lot of other commands (DPBTRF and DPBTRS). These commands are used in the mainprog.f90 module. The error: /usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../liblapack.a(dpbtrf.f.o): In function 'dpbtrf':
/usr/src/debug/lapack-3.4.2-1/SRC/dpbtrf.f:277: undefined reference to 'dtrsm_'
and a couple of more lines stating the dependencies.
add the liblapack.a file to the src folder, but compiler always goes back to the lapack in cygwin
On the website of lapack you can normally download the functions with their dependencies (example DPBTRF), but these are not available anymore. Does anyone have another idea how to include these two functions and their dependencies in a static library-file that I can compile beforehand and add to the src-folder?
Current (semi-)Fix
The next thing worked (a bit) for me: following the instructions on http://gcc.gnu.org/wiki/GfortranBuild to manually build libblas.a and liblapack.a in the /usr/src folder of Cygwin and refering to this folder in the makefile. The updated makefile can be found here: http://thijsvandenbrande.be/phd/hamfemInstall/makefileNew
The code compiles nicely on Windows by running the make command from cygwin (next step in the process, running it out of Eclipse) and i get a .exe file that can be run by double clicking it and that keeps running if I move it with its folder to another location. Because this process is quite labour intensive, figuring it all out, I added the answer here below, stating the commands you have to parse to cygwin in order to make it work.
For your information: my file structure looks like this (after the build, I move the .exe file one folder up, both in the linux version as the windows version):
hamfem.exe
in
input.txt
NGCR_building01.txt
out
(empty folder for output files of the routine)
src
hamfem.f90 (main file)
mainprog.f90 (file that contains the commands from lapack)
...(a bunch of other modules)
makefile
I figured things out myself, with some pointers from all over stackoverflow. In order for others to help them resolve similar issues, I would like my work method here so that the question is fully documented.
The issue can be resolved by clean building the Lapack library !and the Blas library on your local machine in cygwin and pasting the liblapack.a and libblas.a file to the library folder that you refer to in the makefile. The errors that were casted by calling Lapack staticly where a result of some routines of Blas used in the two commands.
These are the steps I followed:
download the lapack.tgz and blas.tgz files from the website and past them in the C:\Cygwin\usr\src folder
Extract these files with the following commands in cygwin:
cd /usr/src
tar -xvzf lapack.tgz
tar -xvzf blas.tgz
Build the two library files with the commands shown below in Cygwin. Compiling Lapack can take a while and will result in some errors in the end because of some missing links in the test files. These tests are run for accuracy tools. A more detailed look into the make.inc file is needed to resolve these issues.
cd $HOME
cd /usr/src/BLAS
make
mv blas_LINUX.a ../libblas.a
cd ../lapack-3.4.2
mv make.inc.example make.inc
make
mv liblapack.a ../liblapack.a
check the makefile included in this repository for the correct linking to the libraries. These should say /usr/src and -static -llapack -lblas, the other options are for the linux compiler.