To use MSYS2 shell, how to change the gcc toolchain PATH to "C:\TDM-GCC-32" instead of using the default MinGW-w64 one ?
How to tell MSYS2 to use "C:\TDM-GCC-32" toolchain instead of the default ?
Thank you for your understanding.
You can add that toolchain to your path by running this command in an MSYS2 Bash shell:
export PATH=/c/TDM-GCC-32/bin:$PATH
I'm assuming the TDM-GCC-32 folder has a "bin" folder inside it with executables. If that's not the case, you will need the command above.
Note that, in general, adding a folder to your PATH with arbitrary executables and DLLs could cause problems with MSYS2, because those executables and DLLs might be used instead of their default counterparts with the same name.
Also note that the binaries generated by TDM-GCC might not necessarily be compatible with the binaries generated by MSYS2's MinGW toolchain.
Related
I am cross-compiling a C library using CMake and a toolchain file. My toolchain file sets CMAKE_SYSROOT to the appropriate value so compilation works with no issues. However, when installing, the library does not install to the directory pointed to by CMAKE_SYSROOT. I can achieve that effect by running make install DESTDIR=xxx though.
I understand that there are two separate concepts here:
The cross-compilation toolchain, which consists of binaries that can be run on my local architecture
The CMAKE_SYSROOT which is the root directory of a target-architecture filesystems, containing header files and libraries, passed to e.g. gcc through the --sysroot flag.
I have two questions:
Is it a good idea to conflate the sysroot where my cross-compilation toolchain lives, with the sysroot where all my cross-compiled libraries will be installed? It feels to me like it should be the same, but am not sure, and to CMake it appears they are distinct concepts. Update: answered in the comments below, these are indeed distinct concepts.
What is the modern CMake way to specify the installation directory when cross-compiling like described above? Update: I believe this should be the same as CMAKE_SYSROOT, and I feel CMake should offer a way to only define this once somewhere.
Thanks!
There is no interference between sysroot and install directory (prefix).
Sysroot is given by CMAKE_SYSROOT variable and denotes prefix for tools used during build process.
Install directory(prefix) is given by CMAKE_INSTALL_PREFIX variable and denotes the path, where the project will be used upon installation. E.g. with install prefix /usr/local the project's executable foo expects to be run as /usr/local/bin/foo.
Note, that with default installation procedure, CMake installs files to the host machine. For install files onto the target machine, this procedure is needed to be adjusted. Parameter DESTDIR=xxx for make install is a way for install files directly to the target machine. Another way is to create a package (e.g. with CPack) on host, and install that package on target machine.
Note, that in the above paragraph it is irrelevant, whether cross-compilation took a place or not: it is possible to build the project on one machine and install it to the other, but similar one, without any cross-compilation.
What is the current process to use the mingw toolchain that is included with cygwin?
There use to be a -mno-cygwin option used with gcc.
The mingw versions have x86_64-w64-mingw32- or i686-w64-mingw32- added to their exe names. Currently I just use these directly but I want to use cmake.
Cygwin also includes cmake. How would I configure it to use the mingw toolset that is included with cygwin? I also see some Qt5 *.cmake modules included in the Qt5 libraries for mingw.
Thanks.
I've found a temporary workaround. Just define these two environment variables:
set CC=/usr/bin/x86_64-w64-mingw32-gcc.exe
set CXX=/usr/bin/x86_64-w64-mingw32-g++.exe
Define them before running the cmake that is included with cygwin.
Seems to work.
I have a difficult time in understanding the difference between CMAKE_INSTALL_PREFIX and CMAKE_INSTALL_RPATH.
If I understand well, CMAKE_INSTALL_PREFIX is the prefixed directory that will be installed. Therefore, if I use the following script for installation:
project(hello)
add_library(hello hello.h hello.cpp)
set(CMAKE_INSTALL_PREFIX "c:/ABC/DEF")
INSTALL(TARGETS hello EXPORT hello_export
RUNTIME DESTINATION bin
LIBRARY DESTINATION bin
ARCHIVE DESTINATION lib
FRAMEWORK DESTINATION bin
INCLUDES DESTINATION include
)
Then the static library will be installed in C:/ABC/DEF/lib.
Then, my question is what's the point of using CMAKE_INSTALL_RPATH?
On a system which supports paths of the form c:/ABC/DEF (i.e. Windows), none. Windows binaries don't have a notion of rpath.
On systems which do have DT_RPATH and DT_RUNPATH (= those which use ELF binaries), the CMake variable CMAKE_INSTALL_RPATH is used to set up the value of DT_RPATH (or DT_RUNPATH) tags which will be written into the binaries at installation.
This is explained at CMake RPATH handling.
On Unix systems, dynamic libraries are searched for in a system-defined list of directories. (/etc/ld.so.conf -- Windows does this in its own way that is so convoluted that it usually boils down to "just use PATH". 😉)
If you install a library (like the one you just compiled) in a custom directory, not in that list, it will not be found if you run a dependent executable. RPATH is one way to fix this.
See the Wiki page linked above for details.
Firstly, CMAKE_INSTALL_PREFIX determines a "root" for the installed location of headers, libraries, executables, and other resources.
On a system which does not support the notion of a "search hierachy" for dependencies, CMAKE_INSTALL_RPATH is not used. However, on ELF-based systems (e.g. Linux) and Mach-based systems (e.g. macOS 10.5 and later) a set of additional locations to search can be set in executables and dynamic libraries (e.g. .so/.dylib files); this is the "Rpath" and you can set it during cmake's install phase, either for all targets by setting CMAKE_INSTALL_RPATH or for individual targets by setting INSTALL_RPATH on that target.
Static libraries are not dynamic (obviously!) so, CMAKE_INSTALL_RPATH has no utility at all for static libraries.
When installing dynamic objects, CMake will write the Rpath into the dynamic object provided CMAKE_SKIP_RPATH and CMAKE_SKIP_INSTALL_RPATH are both false. By default, the Rpath written will be set to CMAKE_INSTALL_PREFIX followed by the library destination, e.g. CMAKE_INSTALL_PREFIX/lib. On Linux systems, this would by default see an Rpath of /usr/local/lib written as Rpath.
You can examine the Rpath on Linux thus:
readelf -d libmylib.so
which produces something like:
0x000000000000000f (RPATH) Library rpath: [/usr/local/lib]
or on macOS:
otool -l libmylib.dylib | grep -A 2 LC_RPATH
which produces something like:
cmd LC_RPATH
cmdsize 40
path #loader_path/../Frameworks (offset 12)
To override the install Rpath you can set the variable CMAKE_INSTALL_RPATH. E.g. on Linux:
set(CMAKE_INSTALL_RPATH "\$ORIGIN/../lib")
or on macOS:
set(CMAKE_INSTALL_RPATH "#loader_path/../lib")
Trying to change FindSDL.make to work with SDL2. The problem is that using mingw it doesn't find SDL2_INCLUDE_DIR, even though SDL2 is installed.
I've change the whole file, but the problems is in this line:
find_path(SDL2_INCLUDE_DIR
NAMES
SDL.h
PATH_SUFFIXES
include/SDL2
)
Thought it should look up MinGW folder, but it looks like it doesn't.
Actually, even this one doesn't work:
find_path(TEST_PATH stdio.h)
So what is the proper way to use find_path under mingw on Windows? Can it be related to mingw install path (preferred one is C:\MinGW, but I've installed it to E:\Programs\MinGW)?
Should I always explicitly write -DCMAKE_INCLUDE_PATH=<my path to mingw>\include or use environment variable that points to mingw folder and use it as a HINT to find_path?
I'm using cmake and cpack to build my project and build packages. I'm creating a few executables in my project, let's call them EXE1 and EXE2.
When creating different versions of these executables, I want to name to reflect the version of the executable (let's say EXE1_1.0.0). I can change the name of the output for a target by doing set_target_properties.
However, now when doing an install, I want to do create a symlink to this versioned name of the executable, i.e. I want to have
the "versioned" executable installed in bin directory, i.e. EXE1_1.0.0
create a symlink to the "versioned" executable, i.e. create symlink EXE1, which points to EXE1_1.0.0
Can someone suggest me how to do this?
Second question is:
How to install configuration files /etc/MYPROJECT/ directory? What DESTINATION I need to use for configuration files, like I use bin for executables and lib for libraries? Is using an absolute path like /etc an acceptable practice with cmake?
I asked this question on cmake mailing list subsequently, and this is the response I received:
The validity of the answer will depend on which CMake version you use
and which set of platform you want to support.
Symlinks are not that portable
a) Creation may not be [currently] done portably but if you are
targeting Unix you can use cmake -E create_symlink to create one.
b) Depending on the CPack generator you use and CMake/CPack version
symlinks may be embedded in the package or not.
i.e. CPack pre 2.8.7 cannot create ZIP archive which contains
symlinks CPack 2.8.8 can do that now.
Then you can use an install(SCRIPT ... or install(CODE ...) to do that
at install time.
Another option if you are using RPM is to use package specific post
install script. cpack --help-variable
CPACK_RPM_POST_INSTALL_SCRIPT_FILE
this last solution will off course only work for CPack RPM.
For second question
You can use absolute destination path, they should be handled just
fine by CPack DEB and RPM, I don't know for other.
If your software should be installed on Windows this is won't work
with archive generator (ZIP, TGZ, etc...) and/or NSIS.
May be you can do something like:
if(UNIX AND NOT APPLE) set(CONFDEST "/etc/${CMAKE_PROJECT_NAME}")
else() set(CONFDEST "etc") endif()
install(FILES yourconffile DESTINATION ${CONFDEST})