Don't do it in POST_BUILD to avoid multiple parallel builds
stepping on each others toes.
Also don't use copy_if_different, but unconditionally copy it.
The build system should take care of dependencies.
The only generally portable way to do this is to use -std=gnu99,
"#include <stdlib.h>", and write "alloca".
__builtin_alloca does not seem to be available on NetBSD
Using /Zl, the obj files will no longer add a link requirement to the C
runtime libraries. Meanwhile, also add /NODEFAULTLIB for non-UWP MSVC
toolchains.
Because /Zl is a compile option, it can also be used when building a
static SDL3 library, and SDL3_test.
Not destroying the windows, caused a leak in checkkeys when
exiting by clicking somewhere in the window:
Allocation 0: 8 bytes
0x7f46f56d2fe8: SDL_realloc_REAL+0x3d
0x7f46f565deb7: GetMouseInputSource+0x88
0x7f46f565e07b: SDL_PrivateSendMouseButton+0x56
0x7f46f565e5aa: SDL_SendMouseButton+0x44
0x7f46f57fb0a4: pointer_handle_button_common+0x1bb
0x7f46f57fb0f3: pointer_handle_button+0x41
0x7f46f5123be6: ffi_prep_go_closure+0x2c6
0x7f46f51204bf: SDL_InitSubSystem+0x19
0x7f46f512318e: ffi_call+0x12e
On Windows, cmake/xxd.py generates text files with \r\n eol.
Because the in-repo files were stored with \n, and git considered
them as binary files, they were always considered out of date.
An alternative fix could be to let xxd.py generate binary files with \n.
But a .gitattributes file should also avoid people accidentally
converting line endings.
CMake's SDL_build_config.h force disables HAVE_STDIO_H when buiding
winrt in non-libc mode.
Becase CreateFileEx is not available in UWP mode, use CreateFile2
instead.
main features:
- No more sdl-build-options/sdl-shared-build-options/sdl-global-options
- Dependency information is stored on SDL3-collector for sdl3.pc
- Use helper functions to modify the SDL targets;
- sdl_sources to add sources
- sdl_glob_sources to add glob soruces
- sdl_link_dependency to add a link dependency that might also
appear in sdl3.pc/SDL3Config.cmake
- sdl_compile_definitions to add macro's
- sdl_compile_options for compile options
- sdl_include_directories for include directories
They avoid repeated checks for existence of the SDL targets
- A nice feature of the previous is the ability to generate
a sdl3.pc or SDL3Config.cmake that describes its dependencies
accurately.
various:
- remove duplicate libc symbol list
- add CheckVulkan
- remove unused HAVE_MPROTECT
- add checks for getpagesize
This fixes the following errors when a dll attempts to link to SDL3::SDL3-shared:
m.c.obj : error LNK2019: unresolved external symbol __imp___acrt_iob_func referenced in function printf
m.c.obj : error LNK2019: unresolved external symbol __imp___stdio_common_vfprintf referenced in function _vfprintf_l
MSVCRTD.lib(init.obj) : error LNK2019: unresolved external symbol _CrtDbgReport referenced in function _CRT_RTC_INIT
MSVCRTD.lib(init.obj) : error LNK2019: unresolved external symbol _CrtDbgReportW referenced in function _CRT_RTC_INITW
MSVCRTD.lib(error.obj) : error LNK2019: unresolved external symbol strcpy_s referenced in function "void __cdecl _RTC_StackFailure(void *,char const *)" (?_RTC_StackFailure@@YAXPEAXPEBD@Z)
MSVCRTD.lib(error.obj) : error LNK2019: unresolved external symbol strcat_s referenced in function "void __cdecl _RTC_StackFailure(void *,char const *)" (?_RTC_StackFailure@@YAXPEAXPEBD@Z)
MSVCRTD.lib(error.obj) : error LNK2019: unresolved external symbol __stdio_common_vsprintf_s referenced in function _vsprintf_s_l
MSVCRTD.lib(error.obj) : error LNK2001: unresolved external symbol __C_specific_handler_noexcept
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol _wmakepath_s referenced in function "int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)" (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol _wsplitpath_s referenced in function "int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)" (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol wcscpy_s referenced in function "int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)" (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol __vcrt_GetModuleFileNameW referenced in function "struct HINSTANCE__ * __cdecl GetPdbDll(void)" (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol __vcrt_GetModuleHandleW referenced in function "struct HINSTANCE__ * __cdecl GetPdbDll(void)" (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
MSVCRTD.lib(pdblkup.obj) : error LNK2019: unresolved external symbol __vcrt_LoadLibraryExW referenced in function "struct HINSTANCE__ * __cdecl GetPdbDll(void)" (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
On platforms where time_t is a signed 32-bit integer, most notably i386 Linux,
various functions stop working when dealing with a timestamp
beyond January 2038.
glibc has an opt-in mechanism that redefines time_t to be 64-bit,
and correspondingly increases the size of all system data
structures that contain a time_t, such as struct timeval and struct stat.
This is necessary to allow timestamps beyond January 2038 to be represented;
as well as things that obviously deal with timestamps, this affects functions
like stat(), which will fail with EOVERFLOW if asked to inspect a file whose
correct timestamp does not fit in time_t. This in turn can cause unexpected
problems for "filesystem APIs" of the form "if /run/foo exists, then ..."
when accessed by 32-bit code, if the check for existence is done with stat()
rather than access().
Using 64-bit timestamps in glibc is an opt-in and not the default, because
if done carelessly it can change libraries' ABIs. However, SDL mostly doesn't
use system headers or types in its own headers. I
Co-authored-by: Simon McVittie <smcv@collabora.com>
Anonymous Maarten
