I just wonder how you can know how to properly case the libraries in vcpkg?
i.e.
find_package(gtest REQUIRED) will fail but
find_package(GTest REQUIRED) will pass
What I mean is if I list the installed packages I get them in lowercase letters, i.e.
CMake suite maintained and supported by Kitware (kitware.com/cmake).
~/Proj$ cd vcpkg
~/Proj/vcpkg$ ./vcpkg list
fftw3:x64-linux 3.3.10#3 FFTW is a C subroutine library for computing the...
gtest:x64-linux 1.11.0#3 GoogleTest and GoogleMock testing frameworks
vcpkg-cmake-config:x64-linux 2021-12-28
vcpkg-cmake:x64-linux 2021-12-20
So if I for instance want to add fftw3, how can I tell which case it is?
find_package(fftw3 REQUIRED) fails...
Assuming you are correctly adding -DCMAKE_TOOLCHAIN_FILE=$HOME/Proj/vcpkg/scripts/buildsystems/vcpkg.cmake to your build, then what you're observing has nothing to do with vcpkg in particular.
find_package is as case-sensitive as the filesystem you're on. On Windows, gtest will happen to work, but the real name is GTest, so only that one works on Linux. The name of the fftw3 package is, similarly, FFTW3.
Vcpkg very helpfully tells you this, too:
$ ./vcpkg install fftw3:x64-linux
...
The package fftw3 provides CMake targets:
find_package(FFTW3 CONFIG REQUIRED)
target_link_libraries(main PRIVATE FFTW3::fftw3)
find_package(FFTW3f CONFIG REQUIRED)
target_link_libraries(main PRIVATE FFTW3::fftw3f)
find_package(FFTW3l CONFIG REQUIRED)
target_link_libraries(main PRIVATE FFTW3::fftw3l)
$ ./vcpkg install gtest:x64-linux
...
The package gtest provides CMake targets:
find_package(GTest CONFIG REQUIRED)
target_link_libraries(main PRIVATE GTest::gmock GTest::gtest GTest::gmock_main GTest::gtest_main)
Related
I installed the timezone-series Haskell module using cabal install timezone-series-0.1.5.1.
I then defined a module named Main.hs that starts with:
import Data.Time.LocalTime.TimeZone.Series -- from timezone-series-0.1.5.1
when I run ghc Main.hs, GHC throws the following error:
/home/ubuntu/Main.hs:2:1: error:
Failed to load interface for ‘Data.Time.LocalTime.TimeZone.Olson’
I tried explicitly including the cabal directory in GHC's search path using:
ghc -i/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/ Main.hs
This resulted in the correct path being searched, but GHC is only looking for files ending in the suffix ".hs":
Locations searched:
...
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.hs
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.lhs
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.hsig
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.lhsig
Cabal installed interface files instead however:
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Olson.hi
From line 318 of GHC's source code it looks like GHC ignores "*.hi" files unless it is called in single-shot mode (with the -c flag). Is this correct? (See: https://github.com/ghc/ghc/blob/67a5a91ef5e61f3b3c84481d8a396ed48cd5d96e/compiler/GHC/Unit/Finder.hs)
How can I get GHC to import this module?
An help will be greatly appreciated!
My suggested ways of installing packages in order of my preference:
Make a cabal package and add timezone-series you want to install to the build-depends field as described in the cabal manual.
Use the experimental cabal-env tool to basically automate the process of point 3 below, but then with the global environment. This makes a new build-plan every time you install a new package, so it is like removing the package environment and building it again with all the old packages and the new package added to it. You can add specific constraints like this: cabal-env "timezone-series == 0.1.5.1".
Install a package into local package environment with cabal --package-env . --lib timezone-series. You can add as many packages as you want after the --lib option to install more than one package. If you later want to use a different set of packages simply remove the .ghc.environment.* file that is generated and rerun the installation with a new set of packages. GHC will automatically use these package environment files that are in the current or parent directories. You can specify specific constraints with the --constraint option like this: --constraint "timezone-series == 0.1.5.1".
Use cabal install --lib timezone-series to install it directly into the global environment (~/.ghc/x86_64-linux-8.0.2/environments/default), this will fail if a conflicting package was installed earlier. When you run into errors you can remove that package environment and try again.
Finally, I want to note that GHC 8.0.2 is quite old, so I would advise you to upgrade if you don't have a specific reason for using that version.
It's possible deploy bcc --> https://iovisor.github.io/bcc/
... on centos /redhat SO?
someone knows what's the problem to compile bcc tools from centos? (all dependencies are installed), but when I execute the last step:
cmake .. -DCMAKE_INSTALL_PREFIX=/usr
Returns:
[root#ebpf build]# cmake -DCMAKE_INSTALL_PREFIX=/usr ..
-- Latest recognized Git tag is v0.3.0
-- Git HEAD is 007d28c534e1a98e6017ac9f4c8cb1c0f5244388
-- Revision is 0.3.0-007d28c5 CMake Error at CMakeLists.txt:22 (find_package): Could not find a package configuration file provided
by "LLVM" with any of the following names:
LLVMConfig.cmake
llvm-config.cmake
Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
"LLVM_DIR" to a directory containing one of the above files. If
"LLVM" provides a separate development package or SDK, be sure it
has been installed.
-- Configuring incomplete, errors occurred! See also "/root/bcc/build/CMakeFiles/CMakeOutput.log".
for llvm issue. just run below CLI:
cp /usr/share/llvm/cmake/LLVM-Config.cmake /usr/share/llvm/cmake/llvm-config.cmake
I am creating an object tracking program which rely on OpenCV. Thus I want to be able to test it with different versions of OpenCV but I have linking errors.
I installed the last version of OpenCV (a69b435c928f422fb5f99c02cf2dcae57dcf820a) in the following folder : /usr/local/opencv/opencv-trunk instead of the usual /usr/local.
Then I followed also the official tutorial to use OpenCV with CMake in Linux, but I had the following "normal" error :
CMake Error at CMakeLists.txt:11 (find_package):
By not providing "FindOpenCV.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "OpenCV", but CMake did not find one.
Could not find a package configuration file provided by "OpenCV" with any of the following names:
OpenCVConfig.cmake
opencv-config.cmake
Add the installation prefix of "OpenCV" to CMAKE_PREFIX_PATH or set "OpenCV_DIR" to a directory containing one of the above files. If "OpenCV" provides a separate development package or SDK, be sure it has been installed.
-- Configuring incomplete, errors occurred!
So I did what was suggested and added the following line in my CMakeLists.txt :
# Find independently installed OpenCV libraries
set(OpenCV_DIR "/usr/local/opencv/opencv-trunk/share/OpenCV")
This is the complete CMakeLists.txt file :
# Find independently installed OpenCV libraries
set(OpenCV_DIR "/usr/local/opencv/opencv-trunk/share/OpenCV")
cmake_minimum_required(VERSION 2.8)
project( DisplayImage )
add_executable( DisplayImage DisplayImage.cpp )
find_package( OpenCV REQUIRED )
include_directories( ${OpenCV_INCLUDE_DIRS} )
target_link_libraries( DisplayImage ${OpenCV_LIBS} )
Now I have the following error and I don't find how to deal with it.
CMake Error at CMakeLists.txt:12 (find_package):
Found package configuration file:
/usr/local/opencv/opencv-trunk/share/OpenCV/OpenCVConfig.cmake
but it set OpenCV_FOUND to FALSE so package "OpenCV" is considered to be NOT FOUND.
-- Configuring incomplete, errors occurred!
If you have already faced that issue in such context your solutions are welcomed ;)
If you are running IntelliJ or any other IDE, just try re-building CMake cache (or just remove your build directory and run cmake utility again).
I believe this is not the best practice - to set the configuration variable like OpenCV_DIR hard-coded in the CMakeLists.txt. Try setting it manually, as an environment variable to the cmake utility:
OpenCV_DIR=/usr/local/Cellar/opencv3/3.1.0_2/share/OpenCV/ cmake ..
or set your IDE to make this for you:
(My problem is about distribute binaries without haskell-platform, ghc, cabal, ...)
I need deploy a well cabal formed haskell application (a Yesod scaffolded) but I have disk space restrictions.
GHC size is about 1Gbytes, store all cabal source code, packages, etc... require more disk space, etc...
Obviously, haskell-platform, ghc, ... is about development (not deployment).
In my specific case I can generate
cabal clean && cabal configure && cabal build
and run succesfully (some like)
./dist/build/MyEntryPoint/MyEntryPoint arg arg arg
But, what about dependencies?, how move it to production environment? (together my "dist" compilation)
Can I put binary dependencies without cabal? How?
Thank you very much!
By default, ghc uses static linking of the Haskell libraries. So the resulting binary is independent of the Haskell ecosystem. If your program does not need any data files, just copy the binary out from ./dist/build/MyEntryPoint/MyEntryPoint to the host
If you also have data files (e.g templates, images, static html pages) that are referenced by the binary using the data path finding logic of Cabal, you can use Setup copy as follows (using happy as an example):
/tmp/happy-1.18.10 $ ./Setup configure
Warning: defaultUserHooks in Setup script is deprecated.
Configuring happy-1.18.10...
/tmp/happy-1.18.10 $ ./Setup build
Building happy-1.18.10...
Preprocessing executable 'happy' for happy-1.18.10...
[ 1 of 18] Compiling NameSet ( src/NameSet.hs, dist/build/happy/happy-tmp/NameSet.o )
[..]
[18 of 18] Compiling Main ( src/Main.lhs, dist/build/happy/happy-tmp/Main.o )
Linking dist/build/happy/happy ...
/tmp/happy-1.18.10 $ ./Setup copy --destdir=/tmp/to_be_deployed/
Installing executable(s) in /tmp/to_be_deployed/usr/local/bin
/tmp/happy-1.18.10 $ find /tmp/to_be_deployed
/tmp/to_be_deployed
/tmp/to_be_deployed/usr
/tmp/to_be_deployed/usr/local
/tmp/to_be_deployed/usr/local/bin
/tmp/to_be_deployed/usr/local/bin/happy
/tmp/to_be_deployed/usr/local/share
/tmp/to_be_deployed/usr/local/share/doc
/tmp/to_be_deployed/usr/local/share/doc/happy-1.18.10
/tmp/to_be_deployed/usr/local/share/doc/happy-1.18.10/LICENSE
/tmp/to_be_deployed/usr/local/share/happy-1.18.10
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/GLR_Lib-ghc-debug
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/GLR_Lib-ghc
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/GLR_Lib
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/GLR_Base
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/HappyTemplate-arrays-coerce-debug
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/HappyTemplate-arrays-ghc-debug
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/HappyTemplate-arrays-debug
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/HappyTemplate-arrays-coerce
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/HappyTemplate-arrays-ghc
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/HappyTemplate-arrays
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/HappyTemplate-coerce
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/HappyTemplate-ghc
/tmp/to_be_deployed/usr/local/share/happy-1.18.10/HappyTemplate
/tmp/happy-1.18.10 $ rsync -rva /tmp/to_be_deployed/ production.host:/
[..]
If you do not want to install into /usr/local then pass the desired prefix to Setup configure.
This works well if the target host is otherwise similar (same versions of C libraries such as gmp and ffi installed). If you also need to statically link some C library, see the question that hammar has linked in his comment.
I am using CMake to build a program on linux. The program compiles successfully and runs from the project build directory. The program is linked with a custom library in the directory ${HOME}/build/lib
I have an install stage with:
install(TARGETS ProgName RUNTIME DESTINATION bin)
When I run make install the program gets put in the correct place, but the cmake installer removes the runtime path from the binary.
-- Install configuration: "Debug"
-- Installing: *binary name*
-- Removed runtime path from "*binary name*"
I have read articles on the internet discussing the misuse of the LD_LIBRARY_PATH variable so I like to keep mine limited to system library locations if possible. I am not sysadmin so I cannot add the location to the default linker search path either.
Does anyone know how I can keep the development-time linking paths when installing or at least customising which paths are added to the runtime?
Cheers
Note: if you don't want to modify the cmake scripts themselves, setting property around, you can launch you cmake with a directive asking to not remove the runtime path:
See "Variables that Control the Build", with variable: "CMAKE_SKIP_RPATH"
If true, do not add run time path information.
If this is set to TRUE, then the rpath information is not added to compiled executables.
The default is to add rpath information if the platform supports it. This allows for easy running from the build tree.
To omit RPATH in the install step, but not the build step, use CMAKE_SKIP_INSTALL_RPATH instead.
If the deliveries already contained the right runtime path, that directive will avoid cmake to do any modification to the current runtime path included in said deliveries.
cmake -DCMAKE_SKIP_RPATH=ON xxx.cmake
You should look at set_target_properties command and the property BUILD_WITH_INSTALL_RPATH
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set_target_properties
This works for CMake 2.8
set_target_properties(foo PROPERTIES INSTALL_RPATH_USE_LINK_PATH TRUE)
where foo is the target you defined earlier:
project(foo)
add_executable(foo ...)
...
install(TARGETS foo DESTINATION bin)
...
Before
% sudo make install
Install the project...
-- Install configuration: ""
-- Installing: /opt/mystuff/bin/foo
-- Removed runtime path from "/opt/mystuff/bin/foo"
After
% sudo make install
Install the project...
-- Install configuration: ""
-- Installing: /opt/mystuff/bin/foo
-- Set runtime path of "/opt/mystuff/bin/foo" to "/opt/zzyzx/lib:/opt/bar/lib/x86_64"