When casting from function pointer which takes some parameters and returns
void to function pointer which returns non-void and may take some
parameters, then gcc throws following warning:
warning: wspiapi.h:50:20: warning: cast between incompatible function types from ‘void (__attribute__((stdcall)) *)(struct addrinfo *)’ to ‘int (__attribute__((stdcall)) *)()’ [-Wcast-function-type]
Avoid this warning by first casting to (void(*)(void)) pointer and then to
final (FARPROC) function pointer. Casting from and to (void(*)(void)) gcc
and clang does not throw incompatible cast warnings.
See: https://gcc.gnu.org/gcc-14/porting_to.html#incompatible-pointer-types
Signed-off-by: Martin Storsjö <martin@martin.st>
_osver, _winmajor, _winminor and _winver global variables are available
since the first crtdll.dll library up to the msvcr80.dll (both i386 and
x64), including OS system version of msvcrt.dll. ARM versions of msvcrt.dll
is missing _winver variable (but others are present). __p_ functions which
return pointers to these variables are missing just in crtdll.dll,
msvcrt10.dll and non-i386 versions of msvcrt.dll.
Provide missing __p_ functions for libraries which provides global
variables and defines _osver, _winmajor, _winminor and _winver via
__p_ functions in header files.
This aligns definitions of these version macros with msvc (which also
defines them via __p_ functions) and also with other definitions in
mingw-w64 header files (which also use __p_ functions instead of global
__MINGW_IMP_SYMBOL).
Signed-off-by: Martin Storsjö <martin@martin.st>
In file msvcrt.def.in is mentioned that symbol __p__iob is provided by
mingw-w64 emulation. But it is not yet. Functions __p__iob() and
__iob_func() returns same pointer to first member of _iob[] array, so
define __p__iob symbol for non-i386 builds as alias to __iob_func symbol.
Symbol __iob_func is present in all non-i386 versions of msvcrt.dll
library.
Signed-off-by: Martin Storsjö <martin@martin.st>
In file msvcrt.def.in is mentioned that symbols __p___mb_cur_max,
__p__pctype and __p__pwctype are provided by mingw-w64 emulation, but
source files which provide them are missing in Makefile.am sections for
building msvcrt.dll import libraries. Fix this problem.
Signed-off-by: Martin Storsjö <martin@martin.st>
Test case:
#include <math.h>
int isnan_wrapper(double value) { return isnan(value); }
Output:
$ g++ -Wconversion -c snippet.cpp
warning: conversion to 'float' from 'double' may alter its value
warning: conversion to 'int' from 'double' may alter its value
First warning is caused by the fact in C++ mode __mingw_choose_expr is
using ternary operator and warning is triggered also by the case which is
not executed.
Second warning is caused by the fact that type of expression
(__builtin_trap(),x) for isnan(x) is double, but return value of
isnan_wrapper() is int. But this expression never returns.
Fix the first problem to use explicit cast for __isnan* calls which
correspondents to matched __mingw_types_compatible_p types.
And fix second problem by changing expression to something which has type
of int.
Bug: https://sourceforge.net/p/mingw-w64/bugs/481/
Signed-off-by: LIU Hao <lh_mouse@126.com>
Windres makes no use of SSE intrinsics, but produces warnings:
C:/MSYS64/mingw32/lib/gcc/i686-w64-mingw32/14.2.1/include/xmmintrin.h:126: digit exceeds base
126 | return __extension__ (__m128){ 0.0f, 0.0f, 0.0f, 0.0f };
Reference: https://gitlab.gnome.org/GNOME/gimp/-/issues/11655
Signed-off-by: LIU Hao <lh_mouse@126.com>
mingw-w64 startup code already provides its own atexit() functions.
Implementation for DLL and EXE builds differs because version for DLL
builds has to be called at the time when unloading DLL library whereas
version for EXE builds is called at process termination. DLL version of
atexit() stores atexit's function pointers into own table which is called
from DLL unload hook. EXE version just calls CRT's _onexit() function.
Some msvcrt def files provide atexit function symbol without DATA keyword,
which is than exported from msvcrt import library. And so it conflicts with
the atexit symbol from startup file and makes atexit function unusable.
UCRT libraries do not have this problem because they provide atexit
function under different name _crt_atexit.
Fix msvcrt symbol conflicts by renaming atexit function to _crt_atexit in
every CRT def file. This will ensure compatibility with UCRT and also that
applications would call atexit function from mingw-w64 startup file and not
from CRT import library.
Also change atexit implementation in exe startup file to directly call
_crt_atexit() function instead of _onexit(). This will simplify usage as
UCRT does not have _onexit() function (mingw-w64 provides only _onexit
wrapper around _crt_atexit) and msvcrt's atexit() function (renamed to
_crt_atexit() in def file) is doing same thing as msvcrt _onexit().
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Here is a patch which fixes bugs #988 and #992 following the commit
7b3379.
This commit introduced a new function winpthreads_init in charge of
setting up the _pthread_get_system_time_best_as_file_time and _pthread_get_tick_count_64
pointers using a runtime detection.
This function is defined with the constructor attribute. The problem is
that every static object making use of a constructor is also tagged with
this constructor attribute and the call ordering is unspecified.
For example, when linking code making use of C++11 chrono objects the
libstdc++ code is called before winpthreads_init but makes of the
clock_gettime function which causes a crash.
A minimal reproduction code can be found here in bug #992.
This bug can be fixed by setting a priority of 0 to the
winpthreads_constructor. It is then called before the static
constructors.
Signed-off-by: LIU Hao <lh_mouse@126.com>
DWMAPI was already defined by dwmapi.h, but it was not actually used
when declaring the functions in that header, so they were missing
DECLSPEC_IMPORT.
This patch replaces HRESULT WINAPI with DWMAPI, and WINBOOL WINAPI with
DWMAPI_(WINBOOL) for the DwmDefWindowProc function that does not return
HRESULT.
Signed-off-by: Daniel Verkamp <daniel@drv.nu>
Signed-off-by: LIU Hao <lh_mouse@126.com>
The DwmFlush() function takes zero parameters, not an undefined number
of parameters.
Signed-off-by: Daniel Verkamp <daniel@drv.nu>
Signed-off-by: LIU Hao <lh_mouse@126.com>
Currently, _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS only affects the
format for wide strings, but include it everywhere for consistency.
Signed-off-by: Martin Storsjö <martin@martin.st>
Currently, _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS only affects the
format for wide strings, but include it everywhere for consistency.
Signed-off-by: Martin Storsjö <martin@martin.st>
Our _CRT_INTERNAL_LOCAL_PRINTF_OPTIONS define contains
_CRT_INTERNAL_PRINTF_LEGACY_WIDE_SPECIFIERS, which affects how
wide strings are formatted - so this should have a functional
effect, fixing an earlier inconsistency with this function.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes compiler error as following.
JUCE/modules/juce_graphics/native/juce_Direct2DResources_windows.cpp:56:81:
error: assigning to 'D2D1_PRESENT_OPTIONS' from incompatible type 'unsigned int'
56 | hwndRenderTargetProps.presentOptions = D2D1_PRESENT_OPTIONS_IMMEDIATELY | D2D1_PRESENT_OPTIONS_RETAIN_CONTENTS;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
This reverts parts of 52c98b1273.
While powf indeed is available in UCRT on i386 too, it's missing
in Wine's i386 ucrtbase.dll (as of Wine 9.15). This probably stems
from the same mistake originally. (Most of the float math functions,
suffixed with -f, are unavailable in the i386 UCRT, but powf is
available.)
This was fixed in upstream Wine in commit
5393ba55464f3346bad7b98e11733348f2b64c6f, which will be part of
the upcoming Wine 9.16.
Thus, to allow built executables to run on current Wine versions,
avoid linking against this function, as a temporary workaround.
After a grace period, to let fixed versions of Wine become more
widely available, we can revert this, to link against powf
on i386 too.
At that point, we can stop including math/powf.c in src_ucrtbase32
in Makefile.am too.
Signed-off-by: Martin Storsjö <martin@martin.st>
List of symbols in ucrtbase.def.in and ucrtbased.def.in are very similar.
So move them into one common file ucrtbase-common.def.in and based on
DEF_DEBUG definition choose if the symbol list is for debug ucrtbased.dll
or release ucrtbase.dll library.
Signed-off-by: Martin Storsjö <martin@martin.st>
ucrtbased.dll is debug version of the ucrtbase.dll and provides additional
debugging functions.
Specify symbols for all 4 platforms: x86, x64, arm32, arm64.
All symbols in ucrtbase.dll are available also in ucrtbased.dll with one
exception for ARM64 version of ucrtbased.dll. It does not provide
__unDName, __unDNameEx and _is_exception_typeof symbols which are available
in non-debug version ucrtbase.dll.
Signed-off-by: Martin Storsjö <martin@martin.st>
This change just split symbols into two sections, it does not add or delete
any symbol.
It looks like that all newer versions of ucrtbase.dll do not change set of
symbols, they do not add any new or remove any existing.
Signed-off-by: Martin Storsjö <martin@martin.st>
