I have been trying to build RPM packages for libc++ 3.3 on a RHEL 6.4 box. I need both static and shared libraries. So, I learned some basics of cmake and then modified the bundled CMakeList.txt. Got that part to work.
But since in RHEL 6.x, all 64-bit libraries should go to /usr/lib64 instead of /usr/lib, I have been attempting to use the following to get the job done:
(A) During building, I use
SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX})
to have all library files (*.so* and *.a) located in lib64 rather than lib.
(B) Using a ADD_LIBRARY... command as shown below
ADD_LIBRARY(c++ STATIC ...
together with
set_target_properties(c++ PROPERTIES
ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX})
INSTALL(TARGETS c++
ARCHIVE DESTINATION lib${LIB_SUFFIX})
to get the static library installed in /usr/lib64.
(C) In addition, with
INSTALL(FILES ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}/libc++.so DESTINATION lib${LIB_SUFFIX})
INSTALL(FILES ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}/libc++.so.1 DESTINATION lib${LIB_SUFFIX})
INSTALL(FILES ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}/libc++.so.1.0 DESTINATION lib${LIB_SUFFIX})
to have shared libary also installed in /usr/lib64 too.
But a copy of the shared library is still installed in /usr/lib in the resulting RPM. How can I prevent it?
If I were to write a RPM spec file, the _libdir macro automatically handles this. With cmake, given the fact that I am still new to it, I would appreciate a hint/pointer as to the right directive to use.
Actually, with a helpful person in the cmake mailing list, I am now able to rid of the %dir /usr/lib in the generated spec file. It's actually quite simple: just cd to $CMAKE_SOURCE_DIR/lib and edit the CMakeLists.txt there. Append ${LIB_SUFFIX} to the two install DESTINATIONs. Regenerate the Makefile in the build subdirectory, and then make && make package. All library files go into /usr/lib64 as desired.
What I can see:
1) There's a missing space in ARCHIVE_OUTPUT_DIRECTORY${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}), should be ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX})
2) When are your .so files going to be build if you use ADD_LIBRARY(c++ STATIC ...?
Related
When you install many packages through vcpkg (such as vcpkg install cairo), at the end of this process, you are told what find_package and target_link_libraries CMake commands to use in order to link to the package that was installed. And this works fine; you can even re-execute the install command to see these CMake commands again.
However, some packages installed through vcpkg don't have these. After installing Pango for example, there is no list of CMake commands to actually use the library. I found the target CMake file for find_package in several of the vcpkg package directories, but the Pango directory has no CMake file for the package.
For some reason, example code using Pango can still compile (ie: it can find Pango's headers), but it fails to link due to not linking to the right libraries.
So how is this supposed to work? Do I have to list the include directories, library directories, and library files through a variety of CMake interfaces for Pango? Or is there some alternative inclusion mechanism that takes care of the details like most other vcpkg packages?
Note that I'm using Visual Studio 2019's built-in CMake functionality to try to build with these.
find_package finds a particular kind of .cmake file that is usually shipped with vcpkg packages. These .cmake files do the work of setting include directories and libraries to link with.
As such, if a vcpkg package does not include such a file, you will need to essentially do the work that the file would have done. Fortunately, CMake and vcpkg know where the headers and library build files are for the various configurations. What you need to do is find those directories and libraries, then add them to your project (along with any other special compiler options that the package requires, which requires some familiarity with the package).
To find the include directory containing a library's header, use find_path to set a variable, giving it the name of a header file to search for. For example:
find_path(PANGO_INCLUDE_DIR pango/pango.h)
This header directory can then be set as part of the include path:
target_include_directories(project_name_here PRIVATE ${PANGO_INCLUDE_DIR})
Libraries are a bit harder, since you have to track down the full name (minus extensions) of the actual library. And if the package involves multiple libraries, you need to track down all of those which are applicable to you.
Given the name of a library or libraries of interest, you can find them one at a time with find_library, setting those libraries into variables:
find_library(PANGO_LIBRARY pango-1.0)
find_library(PANGOCAIRO_LIBRARY pangocairo-1.0)
You can then link with those libraries via target_link_libraries:
target_link_libraries(cairo_vcpkg PRIVATE
...
${PANGO_LIBRARY}
${PANGOCAIRO_LIBRARY}
)
Indeed, some packages installed via vcpkg do not export a .cmake file like Pango for you and SDL for me.
I want to clarify that I have been trying to use vcpkg for two days, I share with you the cmakelist.txt that I use on my side so that SDL works as if I had used find_package (SDL Required)
cmake_minimum_required(VERSION 3.16)
project(xxxx)
### Specify the C++ standard ###
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED True)
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/CMake)
### To find and use SDL ###
# find path of include and lib
find_path(SDL_INCLUDE_DIR SDL/SDL.h)
find_library(SDL_LIBRARY SDL)
# find pat of manual-link library
set (LIBRARIES_TO_LINK C:/dev/vcpkg/installed:/x64-windows/lib/manual-link)
find_library(SDL1_TEST SDLmain HINTS ${LIBRARIES_TO_LINK})
....
I recently downloaded goattracker2 on Windows 10 and after making some changes to the source code, I need to recompile the program to test it.
I don't have any experience with recompiling.
I had a look at the documentation included in the readme-file:
Recompiling
To recompile for Win32, you need the MinGW development environment,
use the file src/makefile.win as makefile.
To recompile for Linux, use src/makefile.
In both cases you need the SDL development libraries in addition to
the SDL runtime, see http://www.libsdl.org.
Compile first the utilities (datafile & dat2inc) from the src/bme
directory, and place them to your path.
This leaves me with several questions, like
Which programs do I need to download
How do I run or execute the makefile
Where do I need to install the SDL libraries
If anyone has experience with recompiling goattracker, can they provide a step by step tutorial for how to do it?
Get MinGW (I recommend 32bit version) and install.
Download and unpack the SDL Libraries from https://www.libsdl.org/ (depending on your version you might need SDL 1.x)
The SDL Libraries (the *.a files) have to be added in the lib directory of MinGW installation directory (this might be different from the lib dir of MinGW, see this issue)
The header files from SDL (SDL2/ directory MinGW) have to be put where MinGW can find them (this might be different from the include dir of MinGW, see this issue)
Go to the src directory of goattracker and type make -f makefile.win
We have multiple libraries in different folder, The main application needs to build those libraries in other folders and install them to output folder and then the main application needs to link to libraries to build executable.
I am able to build the libraries present in other folders using add_subdirectory() in a loop, but I am not able to install them to output folder by main cmake file. Could anyone help me out on this.
The main application needs to build those libraries in other folders and install them to output folder and then the main application needs to link to libraries to build executable.
It is not necessary in CMake to install libraries in order to link to them. You can build the libraries and have your main executable link to them without installing the libraries. When you need to install your application as a whole, you can install libraries along with the executable if needed i.e. if the libraries are shared ones and not static ones.
One example of how you can organize things: assume you have the following structure in your project:
CMakeLists.txt # root of project
|
|--lib
| |--CMakeLists.txt # library subproject
|
|--app
|--CMakeLists.txt # app subproject
Then your root CMakeLists.txt can look like this:
project(MyProject)
add_subdirectory(lib)
add_subdirectory(app)
The lib subproject's CMakeLists.txt can look like this:
project(MyLib)
set(SOURCES <...>) # specify library's sources
add_library(${PROJECT_NAME} ${SOURCES})
set(MyLib ${PROJECT_NAME} CACHE INTERNAL "")
The last line in the snippet above is aimed to make MyLib variable available everywhere within the project. I found this trick here and used it successfully in my projects. Maybe there are better options here, if anyone knows them, feel free to suggest.
The app's CMakeLists.txt can then look like this:
project(MyApp)
set(SOURCES <...>) # specify app's sources
add_executable(${PROJECT_NAME} ${SOURCES})
target_link_libraries(${PROJECT_NAME} ${MyLib})
I haven't covered the installation here but it's actually straightforward: if your libraries are static ones, you only need to install the executable using install TARGETS. If your libraries are shared ones, you need to install them along with the executable.
This can be considered as a follow-up to CMake MacOS X bundle with BundleUtiliies for Qt application
I want to create a MACOS bundle on CI which can be used by users for an open source project.
What I have:
Main executable
Updater executable
icon file
helper script calling updater then main
data files in a folder (translations etc, some generated at build time)
plugin shared libs
What I've done so far:
add MACOSX_BUNDLE to the executable
add icon to its sources and to RESOURCE property
set MACOSX_BUNDLE_* properties
install everything in a cross-platform way (regular install(TARGETS calls and install(FILES for the resources)
But now I'm stuck on how to get those into the bundle w/o to much manual work.
From the linked question I got something like this:
set(APPS "\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${PROJECT_NAME}.app")
set(LIBS )
set(DIRS "${CMAKE_BINARY_DIR}")
# Path used for searching by FIND_XXX(), with appropriate suffixes added
if(CMAKE_PREFIX_PATH)
foreach(dir ${CMAKE_PREFIX_PATH})
list(APPEND DIRS "${dir}/bin" "${dir}/lib")
endforeach()
endif()
install(CODE "include(BundleUtilities)
fixup_bundle(\"${APPS}\" \"${LIBS}\" \"${DIRS}\")")
But:
Why do I need to pass the *.app path manually? CMake does already know it, doesn't it?
LIBS should contain my plugins, shouldn't it? But what? Paths? Target names?
DIRS is also a mystery to me. No documentation even in CMake 3.12 (I'm still using 2.8.12 though :( )
How to add my generated and regular data files? Probably same or similar to the icon? But what about the generated ones?
Help, pointers to examples, full CMakeLists doing that etc. very welcome.
Note: I'm cross-compiling from linux on the CI and NOT using Qt so e.g. macdeployqt or so is out of question.
Just got stuck on the same issue and google brought me here.
This worked for me:
set(CUR_TARGET myappname)
add_executable(${CUR_TARGET} MACOSX_BUNDLE ${MY_SRC})
set_target_properties(${CUR_TARGET} PROPERTIES
BUNDLE True
MACOSX_BUNDLE_GUI_IDENTIFIER my.domain.style.identifier.${CUR_TARGET}
MACOSX_BUNDLE_BUNDLE_NAME ${CUR_TARGET}
MACOSX_BUNDLE_BUNDLE_VERSION "0.1"
MACOSX_BUNDLE_SHORT_VERSION_STRING "0.1"
MACOSX_BUNDLE_INFO_PLIST ${CMAKE_SOURCE_DIR}/cmake/customtemplate.plist.in
)
The file customtemplate.plist.in is based on the cmake template from the cmake dir subfolder at your_cmake_install_dir/share/cmake/Modules/MacOSXBundleInfo.plist.in
How can I integrate SCIP with MinGW and Msys?
Whilst you are waiting for a real answer, I can already guide you to this page from the official site on how to build SCIP (see below). For actual integration there is a pointer in the faq:
How do I construct a problem instance in SCIP?
First you have to create a SCIP object via SCIPcreate(), then you
start to build the problem via SCIPcreateProb(). Then you create
variables via SCIPcreateVar() and add them to the problem via
SCIPaddVar(). The same has to be done for the constraints. For
example, if you want to fill in the rows of a general MIP, you have to
call SCIPcreateConsLinear(), SCIPaddConsLinear() and additionally
SCIPreleaseCons() after finishing. If all variables and constraints
are present, you can initiate the solution process via SCIPsolve().
Make sure to also call SCIPreleaseVar() if you do not need the
variable pointer anymore. For an explanation of creating and releasing
objects, please see the doxygen documentation.
NOTE: See the directories "examples/MIPsolver/" and "examples/Queens/" for simple examples
Remarks on Building/Installing under Windows using MinGW (from http://scip.zib.de/doc/html/INSTALL.php)
To build your own Windows binaries under Windows, we recommend using
the MinGW-Compiler with MSYS from mingw.org
First install MSYS, then MinGW to the mingw folder inside the msys
folder. Now you need to install the following packages to the mingw
folder:
- zlib (or use ZLIB=false ZIMPL=false since zlib is needed for ZIMPL and ZIMPL-support in SCIP)
- pcre (or use ZIMPL=false since pcre is needed for ZIMPL and ZIMPL-support in SCIP)
- gmplib (or use ZIMPL=false since gmplib is needed for ZIMPL and ZIMPL-support in SCIP)
(After calling "make clean" in the ZIMPL folder you will also need
flex and bison to remake ZIMPL. We recommend NOT to use "make clean"
inside the ZIMPL-folder if you do not have these packages installed.)
You can download these additional packages as precompiled binaries for
example from: http://gnuwin32.sourceforge.net/packages.html
(zlib&pcre) http://cs.nyu.edu/exact/core/gmp/ (gmplib) or compile the
source on your own from the project homepages: http://www.zlib.net/
http://www.pcre.org/ http://www.gmplib.org/ (The command "./configure
--prefix=/mingw ; make ; make install" should succeed without problems and installs the packages into the mingw folder.)
Now "make READLINE=false" should be compiling without errors. Please
note that we do NOT support creating the doxygen documentation or
readline-usage under Windows.
Since there are no real symlinks in MSYS, the include and library
files of SoPlex and ZIMPL are actually copied into the
SCIP-lib-folder. When you recompile ZIMPL or SoPlex after compiling
SCIP you have to copy the libraries manually into the SCIP-lib-folder
and recompile SCIP afterwards.