Warning is:
In file included from misc/delay-f.c:11:
mingw-w64-headers/include/delayimp.h:64: warning: "FACILITY_VISUALCPP" redefined
#define FACILITY_VISUALCPP ((LONG)0x6d)
In file included from mingw-w64-headers/include/winbase.h:2817,
from mingw-w64-headers/include/windows.h:70,
from misc/delay-f.c:10:
mingw-w64-headers/include/winerror.h:88: note: this is the location of the previous definition
#define FACILITY_VISUALCPP 109
This same header from Visual Studio has such a definition commented out,
suggesting that it should be defined in winerror.h. We notice that delayimp.h
can't be used without including Windows SDK headers first, so don't redefine
`FACILITY_VISUALCPP` if one has already been defined.
Signed-off-by: LIU Hao <lh_mouse@126.com>
Warning is:
In file included from mingw-w64-headers/include/windows.h:70,
from libsrc/dxerr.c:15,
from libsrc/dxerr8w.c:20:
mingw-w64-headers/include/winbase.h:2171: warning: "FindResource" redefined
#define FindResource __MINGW_NAME_AW(FindResource)
In file included from mingw-w64-headers/include/winbase.h:24,
from mingw-w64-headers/include/windows.h:70,
from libsrc/dxerr.c:15,
from libsrc/dxerr8w.c:20:
mingw-w64-headers/include/libloaderapi.h:62: note: this is the location of the previous definition
#define FindResource FindResourceW
Fix it by conditionally defining FindResource in winbase.h directly as
FindResourceA for non-UNICODE builds and let libloaderapi.h to define
FindResource as FindResourceW for UNICODE builds.
Signed-off-by: LIU Hao <lh_mouse@126.com>
Warning is:
In file included from mingw-w64-headers/include/windows.h:70,
from crt/crtexewin.c:6,
from crt/ucrtexewin.c:14:
mingw-w64-headers/include/winbase.h:2084: warning: "EnumResourceNames" redefined
#define EnumResourceNames __MINGW_NAME_AW(EnumResourceNames)
In file included from mingw-w64-headers/include/winbase.h:24,
from mingw-w64-headers/include/windows.h:70,
from crt/crtexewin.c:6,
from crt/ucrtexewin.c:14:
mingw-w64-headers/include/libloaderapi.h:80: note: this is the location of the previous definition
#define EnumResourceNames EnumResourceNamesW
Fix it by conditionally defining EnumResourceNames in winbase.h directly as
EnumResourceNamesA for non-UNICODE builds and let libloaderapi.h to define
EnumResourceNames as EnumResourceNamesW for UNICODE builds.
libloaderapi.h is automatically included in winbase.h, so caller of
winbase.h would have definition of EnumResourceNames for both UNICODE and
non-UNICODE builds.
Caller of libloaderapi.h would have only UNICODE definition of
EnumResourceNames because api-ms-win-core-libraryloader-l1-2-2.def and
kernel32_onecore.def do not provide non-UNICODE EnumResourceNamesA symbol.
Signed-off-by: LIU Hao <lh_mouse@126.com>
Warning is:
In file included from mingw-w64-headers/include/winerror.h:4920,
from mingw-w64-headers/include/winbase.h:2817,
from mingw-w64-headers/include/windows.h:70,
from intrincs/RtlSecureZeroMemory.c:2:
mingw-w64-headers/include/fltwinerror.h:12: warning: "FACILITY_USERMODE_FILTER_MANAGER" redefined
#define FACILITY_USERMODE_FILTER_MANAGER 0x1f
In file included from mingw-w64-headers/include/winbase.h:2817,
from mingw-w64-headers/include/windows.h:70,
from intrincs/RtlSecureZeroMemory.c:2:
mingw-w64-headers/include/winerror.h:38: note: this is the location of the previous definition
#define FACILITY_USERMODE_FILTER_MANAGER 31
WinSDK10 header file fltWinError.h contains #ifndef guard. Do same.
Signed-off-by: LIU Hao <lh_mouse@126.com>
C99 wcsrtombs and wcrtomb symbols are natively available since msvcr80 and
also in all ARM versions of msvcrt.dll.
Signed-off-by: Martin Storsjö <martin@martin.st>
C95 mbrtowc, mbsrtowcs and mbrlen symbols are natively available since
msvcr80 and also in all ARM versions of msvcrt.dll.
Signed-off-by: Martin Storsjö <martin@martin.st>
Clang 19 has removed all support for 3dnow, see
f0eb5587ce
and
https://github.com/llvm/llvm-project/pull/96246.
Since this commit, including the mm3dnow.h header still works,
but it produces a warning about the header being deprecated.
As 3DNow! has been deprecated for a very long time, stop
including this header, for all compiler configurations.
This issue was reported in
https://github.com/mstorsjo/llvm-mingw/issues/443.
Signed-off-by: Martin Storsjö <martin@martin.st>
Makefile.in regeneration not included, per request.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
Provide __MINGW_IMP_SYMBOL(_HUGE) via UCRT import library and unify math.h
header file to always define _HUGE via __MINGW_IMP_SYMBOL(_HUGE).
Signed-off-by: Martin Storsjö <martin@martin.st>
Currently mingw-w64 does not define or provide _commode in header files,
so this guard does not change current behavior.
But in case that in future some mingw-w64 header file starts providing
global _commode macro (as expansion to __p__commode() funcion call), add
guard for local _commode variable which undefines _commode. Same what is
done for _fmode. This ensures that _commode in crtexe.c would always refers
to local _commode variable.
Signed-off-by: Martin Storsjö <martin@martin.st>
* Regenerate symbols from the original ARM32 version
* Add symbols introduced in Visual C++ 2012 Update 1
* Include aliases from crt-aliases.def.in
Signed-off-by: Martin Storsjö <martin@martin.st>
msvcr120_clr0400.dll is private copy of msvcr120.dll library for .NET CLR
runtime. It is not for application usage. Applications should use
msvcr120.dll instead of msvcr120_clr0400.dll.
So remove msvcr120_clr0400.def file and in future changes include
msvcr120.def file.
Signed-off-by: Martin Storsjö <martin@martin.st>
First versioned msvcrt library for ARM32 is msvcr110.dll. Libraries
msvcr80.dll, msvcr90.dll, msvcr90d.dll and msvcr100.dll do not exist.
Signed-off-by: Martin Storsjö <martin@martin.st>
When using GNU ld or GNU dlltool, it is needed to mark ordinal-only export
with NONAME keyword. Otherwise the import library would use export by name,
instead of by ordinal.
Signed-off-by: Martin Storsjö <martin@martin.st>
This code block detected that the return value is from other library
function. It does not mean that function forwards to another one.
For example lot of times gendef detected that the call is GetLastError()
from kernel32.dll. But it does not mean that the function was forwarded to
GetLastError(). It just means that one of the code branch was propagating
return value from GetLastError().
Signed-off-by: Martin Storsjö <martin@martin.st>
gendef by default always scans current directory for other hint .def files
which are later parsed. This default behavior is sometimes problematic, so
add an option --no-include-current-dir which disables scanning of the
current directory for other hint .def files.
Signed-off-by: Martin Storsjö <martin@martin.st>
Decorated I386 fastcall functions have symbols with "@NAME@SIZE" pattern.
Normally function symbols from libraries are exported undecorated, symbol
name matches the function name. But some libraries export I386 fastcall
functions with decorated symbol names.
For example msvcr80.dll library exports symbol "@_calloc_crt@8" for which
gendef without this change generates line "@_calloc_crt@8@8", which cannot
be easily used by applications. With this change it generates line
"@_calloc_crt@8 == @_calloc_crt@8" which allows applications to call
fastcall function _calloc_crt(void *ptr, size_t size).
Signed-off-by: Martin Storsjö <martin@martin.st>
Decorated I386 stdcall functions have symbols with "_NAME@SIZE" pattern.
Normally function symbols from libraries are exported undecorated, symbol
name matches the function name. But some libraries export I386 stdcall
functions with decorated symbol names.
For example msvcrt20.dll library exports symbol "__seh_longjmp_unwind@4"
and gendef without this change generated line "__seh_longjmp_unwind@4@4",
which cannot be easily used by applications. With this change it generates
line "_seh_longjmp_unwind@4 == __seh_longjmp_unwind@4" which allows
applications to call stdcall function _seh_longjmp_unwind(void *jmp).
Signed-off-by: Martin Storsjö <martin@martin.st>
binutils (objdump) accepts PE binaries (EXE/DLL) with zero value in
OptionalHeader's Magic field. Do same in gendef. Such I386 DLL binaries are
distributed as part of the Win32s.
Signed-off-by: Martin Storsjö <martin@martin.st>
msvcr120_app.dll compared to msvcr120.dll is missing not only _getpid symbol
but it is missing also other symbols for which are specified underscore
aliases in crt-aliases.def.in file.
Change NO_GETPID_ALIAS macro to CRTAPP and conditionally disable all
symbols for CRTAPP in crt-aliases.def.in file which are not present in
msvcr120_app.dll library.
Signed-off-by: Martin Storsjö <martin@martin.st>
msvcr120_app.def.in file contains incorrect list of ARM32 symbols.
Seems that the list of symbols was generated from the ARM32 msvcrt.dll
library and not from the ARM32 msvcr120_app.dll library.
List of ARM32 symbols is imported from the vclibs_redist_packages.zip
package (Visual C++ 2013 Runtime for Sideloaded Windows 8.1 apps):
https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist
List of I386 and X64 symbols from that package already matches the
msvcr120_app.def.in file.
Signed-off-by: Martin Storsjö <martin@martin.st>
msvcr120_app.dll library does not provide __p__environ() and
__p__wenviron() functions, but provides _environ[] and _wenviron[] arrays.
So include mingw-w64 emulation of __p__environ() and __p__wenviron()
functions via _environ[] and _wenviron[] arrays into msvcr120_app import
library.
Signed-off-by: Martin Storsjö <martin@martin.st>
MS Visual C++ also access these variables via __p_*() functions which
return pointer to those variables. Do same in mingw-w64 startup code.
UCRT, msvcr120_app.dll and non-i386 versions of msvcrt.dll do not export
__p_*() functions. So provide them via mingw-w64 import libraries.
Signed-off-by: Martin Storsjö <martin@martin.st>
Every executable references only one of those symbols. So if symbols are
split into separate files, linker includes only the one which is used.
(While splitting, simplify the use of headers as well.)
crtdll.dll and msvcrt10.dll do not have entry point for wide wmain() and
therefore they do not need __winitenv init symbol. So do not provide
__winitenv symbol for these two CRT import libraries.
Signed-off-by: Martin Storsjö <martin@martin.st>
File mingw-w64-crt/misc/initenv.c provides same implementation of __initenv
and __winitenv symbols as file mingw-w64-crt/misc/__initenv.c.
So remove duplicate file.
Signed-off-by: Martin Storsjö <martin@martin.st>
Global variable __badioinfo is exported from VC42+ CRT import libraries.
It is not exported from UCRT.
So it is not available in UCRT, msvcrt40.dll and older CRT versions.
Symbol is just a global ioinfo structure with bad (-1) file descriptor.
Provide this structure also in import libraries for older CRT versions and
UCRT, so the symbols will be in all CRT import libraries.
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbol __badioinfo represents a variable of structure type. Not a pointer
to structure and neither not a pointer to array of structures.
Signed-off-by: Martin Storsjö <martin@martin.st>
