I'm trying to install SDL on MinGW.
I've downloaded SDL from here (the SDL2-devel-2.0.0-mingw.tar.gz link), then copied the contents of SDL2-2.0.0/x86_64-w64-mingw32/{bin,include,lib} into the matching directories in my MinGW installation.
When I try to compile any file that contains #include ‹SDL2/SDL.h› using gcc test.c -lmingw32 -lSDL2main -lSDL2 -mwindows, GCC complains about undefined reference to WinMain#16 and undefined reference to some SDL functions.
SDL2-devel-2.0.0-mingw.tar.gz contains both 32-bit libraries (i686-w64-mingw32 directory) and 64-bit libraries (x86_64-w64-mingw32 directory).
The error was caused by using a 64-bit version of the library with a 32-bit compiler.
Related
I'm restucturing the CMake based build of a cross platform (macOS/Windows, Linux should be added soon) C++ project that has a third party rust library as dependendcy. Until now the rust lib dependency was supplied as precompiled library but I want to make its compilation part of my CMake build.
I got it working on macOS using the CMake makefile exporter by referencing the compiled library as a static imported library target and setting up a custom target with the command to build the rust library through cargo like this
add_library (rustlib STATIC IMPORTED)
add_custom_target (rustlib_cargo
WORKING_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}/Ext/rustlib/c-api
COMMAND cargo rustc --release -- --crate-type staticlib)
# Note: RUSTLIB_OUTPUT is set above refering to the absolute path of the produced platform specific library
set_target_properties (rustlib PROPERTIES IMPORTED_LOCATION ${RUSTLIB_OUTPUT})
add_dependencies (rustlib rustlib_cargo)
On macOS the cargo rustc command is invoked before the targets that link against my rustlib target are built and in case the rust library has been built previously this is detected by cargo and it just skips that compilation steph. But on Windows this fails with the built-in ninja exporter of Microsoft Visual Studio 2019 with an error like this:
ninja : error : '../../../Ext/rustlib/target/release/deps/rustlib.lib', needed by 'SomeTargetLinkingAgainstRustlib', missing and no known rule to make it
If I remove the line set_target_properties (rustlib PROPERTIES IMPORTED_LOCATION ${RUSTLIB_OUTPUT}) the build starts correctly, the rust build gets triggered, but as expected I end up with a linker error as the library to link against is not found. So is there any way to refer to a file that is not existent at configuration time but is guranteed to be created during compilation?
I am using Header Only Libraries. The libraries are included through Cmake. I am using the g++ Compiler.
Now what I am looking for is to compile the c++ source files via windows cmd. In this moment i am using clion to compile.
Does anyone know how to compile the source files?
If i am compiling the files without cmake , I am getting errors because the program cannot find the libraries.
You do not run a source file, you run an executable produced by a compiler from source file(s)
If you are under a Linux for instance enter the path(s) where the libraries are through the environment variable LD_LIBRARY_PATH
[edit after your remark]
I mean compile
To indicate to g++ where the library are to link use the option -L followed by the path of a directory where the libraries are. If your libraries are on different directories use several time the option, one per directory
How to set up custom CUDA directory for enable_language(CUDA)?
From cmake version 3.8~ ,I can use enable_language(CUDA) command.
In my custom cmake file, I set CUDA_TOOLKIT_ROOT_DIR same as cuda custom directory(not an default directory).
But when enable_language(CUDA)command is called, cmake default modules are trying to find CUDA in default directory(somewhere in c:\progrmafiles).
I don't want make my teammate install CUDA toolkit separately.
So i want to include all necessary component and tools for using CUDA in custom directory.
How can i make it done?
Target Environment Info
OS windows 7 x64 (only)
IDE visual studio 2013
cmake version 3.11.4
CUDA version 9.2
If I look at CMakeDetermineCUDACompiler.cmake you can select a specific compiler for enable_language(CUDA) via:
The environment variable CUDACXX (for non-"Visual Studio" environments)
> cmake -E env CUDACXX="<your CUDA path here>" cmake ..
Simply set global variable CMAKE_CUDA_COMPILER
> cmake -D CMAKE_CUDA_COMPILER:FILEPATH="<your CUDA path here>" ..
or in your CMakeLists.txt before your project() or enable_language()
call
if (NOT CMAKE_CUDA_COMPILER)
set(CMAKE_CUDA_COMPILER "${CMAKE_SOURCE_DIR}/<your CUDA relative path here>")
endif()
I'm trying to build a package from Fedora that can run on a RedHat 6 machine. So I need to build and static linking with some library that does not exist in RedHat machine.
I found that I can you -static-libgcc or -static-libstdc++ to link with static version of standard library but I don't know how to do with glibc.
How can I link to static library of glibc with CMake?
I know the question mentions glibc but for C++, since -static-libgcc and -static-libstdc++ are linker options, the correct way to set them in CMake is with target_link_libraries().
So you would set it like this, where MyLibrary is the name of your project:
target_link_libraries(MyLibrary -static-libgcc -static-libstdc++)
Given this, if you want complete static linking of glibc you would likewise pass the -static flag.
target_link_libraries(MyLibrary -static)
If you want more of a global setting:
set(BUILD_SHARED_LIBS OFF)
set(CMAKE_EXE_LINKER_FLAGS "-static")
However, bear in mind that glibc is not designed to be statically linked, and without a great amount of additional work, you won't wind up with a truly static package. Your use case of building "a package from Fedora that can run on a RedHat 6 machine" will not readily work by statically linking glibc.
I'm builds my static library using CMake and ninja. Static library builds from several CMake OBJECT libraries.
And I'm builds executable using qmake and MinGW (4.92, 32bit).
The Problem is, resulting static library not linking with executable. All functions from object libaries is undefined reference.
Without using ninja this problem not reproduces.
This is CMake's bug. Fixed in 3.4 version.
https://cmake.org/Bug/view.php?id=15729