MS documentation for _onexit function says:
In the case when _onexit is called from within a DLL, routines registered
with _onexit run when the DLL is unloaded, after DllMain is called with
DLL_PROCESS_DETACH.
And for this functionality msvc statically links _onexit functionality for
DLL builds, and do not let applications to use msvcrt.dll's _onexit symbol
directly.
Fix this issue in mingw-w64 by redefining _onexit function to calls private
mingw-w64 atexit() function, which already distinguish between EXE and DLL
builds. Include this _onexit function into every CRT import library and
disable original _onexit symbol in all def files.
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
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>
msvcr120 and UCRT provides native nextafter symbol. So do not define
duplicate symbol nextafter via crt-aliases.def.in file for these import
libraries.
Signed-off-by: Martin Storsjö <martin@martin.st>
Long double type for msvc is 64-bit but for gcc it is 80-bit.
So these long double functions are not compatible with gcc.
Comment them in all msvcr120 def files for x86 platform.
Signed-off-by: Martin Storsjö <martin@martin.st>
All msvcr120 DLL libraries provides C99 nextafter() function. i386
msvcr120d.def.in already contains it. In other def files it is missing.
Signed-off-by: Martin Storsjö <martin@martin.st>
_wctype is global variable exported from DLL library, so mark it with
DATA and removes false-positive function stdcall @size decoration.
Signed-off-by: Martin Storsjö <martin@martin.st>
This file contains definitions of symbol aliases for any CRT library. It is
already used by msvcrt, crtdll and ucrt. So rename msvcrt-common.def.in to
crt-aliases.def.in as new name better match the purpose of the file.
Signed-off-by: Martin Storsjö <martin@martin.st>
File msvcrt-common.def.in adds just symbol aliases, so include it in CRT
def files after having all symbols declared.
Note that some def files use macros from func.def.in file,
so include func.def.in at beginning of the file when needed.
Signed-off-by: Martin Storsjö <martin@martin.st>
Add 4 new macros FIXED_SIZE_SYMBOLS, NO_I64_FIXED_SIZE,
NO_FIXED_SIZE_64_ALIAS and NO_TIME_ALIAS to distinguish
between different crt versions.
This change adds new symbol aliases which were missing.
There is no symbol change or removal.
For reference here is list of changes between individual outputs from:
cpp -x c $FILE -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E 's/\s*;.*//' | LC_ALL=C sort -u
Signed-off-by: Martin Storsjö <martin@martin.st>
These symbols on 64 bit should resolve to _findfirst64i32/_findnext64i32
functions, like in other CRT libraries and header files.
The UCRT 32 bit aliases are kept as they were before (even if
they are known to be incorrect); they are corrected in a separate
later commit.
Signed-off-by: Martin Storsjö <martin@martin.st>
def-include/msvcrt-common.def.in is included into every msvcr*.def.in file.
So move them all common __ms_* symbol aliases which removes definition
duplication.
msvcr* library before version 8.0 have symbols swprintf/vswprintf which
represents pre-C95 variants of these functions without maxlen argument.
Since version 8.0, symbols swprintf/vswprintf are not present anymore,
they were renamed and have have leading underscore.
Distinguish aliased symbol by a new PRE_C95_SWPRINTF macro in .def.in file.
Signed-off-by: Martin Storsjö <martin@martin.st>
These aliases are automatically added by including msvcrt-common.def.in
file into every msvcr*.def.in file.
Signed-off-by: Martin Storsjö <martin@martin.st>
Symbols __p__fileinfo, _ctype, _fileinfo, _ftime, _futime, _mbscat,
_mbscpy, _mbsdup, _strcmpi, _utime, _wutime, difftime, swprintf, vswprintf,
__buffer_overrun, __security_error_handler, __set_buffer_overrun_handler,
_set_security_error_handler and _wctype are not present in any variant of
msvcr80.dll library. So they are not usable in the current form.
Symbols _ftime, _futime, _utime, _wutime, difftime and _strcmpi can be
defined as aliases to other existing symbols. For I386 time functions is
used 32-bit time_t, for X64 time functions is used 64-bit time_t, like in
other msvcr*.dll libraries.
Functions swprintf() and vswprintf() have already replacement inline
variants defined in header file <swprintf.inl>.
Functions __ms_swprintf() and __ms_vswprintf() are defined without size_t
argument, which corresponds to msvcr80.dll's _swprintf() and _vswprintf()
functions. So add appropriate aliases.
But remaining symbols __p__fileinfo, _ctype, _fileinfo, _mbscat, _mbscpy,
_mbsdup and _wctype do not have replacement, so completely remove them from
msvcr80.def.in files.
Also I386 symbols __buffer_overrun, __security_error_handler,
__set_buffer_overrun_handler and _set_security_error_handler do not have
any replacement, so remove them too.
Signed-off-by: Martin Storsjö <martin@martin.st>
All symbols are extracted from the latest version of msvcr80.dll library
which is Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package
MFC Security Update available for download at page:
https://www.microsoft.com/download/details.aspx?id=26347
Signed-off-by: Martin Storsjö <martin@martin.st>
It looks like that lib64/msvcr80.def.in file contains X64 C++ symbols not
from the msvcr80.dll library but from the Windows XP x64 msvcrt.dll
library. X64 version of msvcrt.dll and msvcr80.dll have different C++
symbols but relatively same set of C symbols.
Replace incorrect X64 C++ symbols in lib64/msvcr80.def.in file by the
correct symbols from Visual C++ 2005 SP1 X64 msvcr80.dll library.
Signed-off-by: Martin Storsjö <martin@martin.st>
Trying to use or link DllMain symbol from some random system DLL library is
in most cases a mistake. So hide all DllMain definitions from all def files.
Signed-off-by: Martin Storsjö <martin@martin.st>
If application does not specify its own DllEntryPoint function then the
default DllEntryPoint provided by libmingwex library should be used. And
not from some random system DLL library.
Signed-off-by: Martin Storsjö <martin@martin.st>
