This adds an optional github actions workflow, with a number of
smoke test verifications of mingw-w64:
- With an existing release of llvm-mingw, rebuild all the runtimes
- This done for the CRT configurations ucrtbase, ucrt and msvcrt
- Run the llvm-mingw smoke tests on Windows (testing compilation
for all 4 architectures, testing running on x86)
- Run the libcxx testsuite on Windows (i686 and x86_64)
- Test cross-building ffmpeg for all 4 architectures
- Test building and running ffmpeg with its testsuite on Windows
(i686 and x86_64)
- Test building a GCC cross compiler from scratch
- Test cross-building a Windows hosted GCC using the GCC above
- Run a small set of basic tests with the GCC toolchain
This allows doing some amount of automatic testing of mingw-w64,
covering most common build configurations, avoiding regressing
any of these cases.
While mingw-w64 isn't primarily hosted on github, this wouldn't
be a mandatory/integrated testsuite per se. But many mingw-w64
developers do use github and can benefit from this test setup,
and by having it in-repo, it's easier to coordinate updates to
the test configuration when that is needed. It also makes it
easier for others to contribute more testing configurations.
Signed-off-by: Martin Storsjö <martin@martin.st>
They are natively available since msvcr80.dll, they are not available in
msvcrt.dll. Provide compatibility emulation into all import libraries where
they are not available.
Compatibility emulation needs to use _msize() or _aligned_msize() functions
to figure out the previous size and properly clear the expanded memory as
*calloc functions require.
Memory allocated by these mingw-w64 emulation functions can be normally
released by the appropriate CRT free() or _aligned_free() function.
Signed-off-by: Martin Storsjö <martin@martin.st>
Function _aligned_msize() is available only in msvcr80+ and UCRT. It is not
available in msvcrt.dll system os library.
Now when the mingw-w64 aligned functions use same alignment and gap
calculation we can use mingw-w64 __mingw_aligned_msize() function as
implementation for CRT's _aligned_msize() function.
Signed-off-by: Martin Storsjö <martin@martin.st>
MS CRT libraries (UCRT, msvcr70+ and os system msvcrt) for functions
_aligned_malloc() and _aligned_offset_malloc() allocate the source buffer
slightly smaller than the mingw-w64 functions in mingw-aligned-malloc.c.
This is because the alignment gap can be used for the user data too.
Do exactly same math calculation in the mingw-w64 implementation as is UCRT
doing. Same calculation is in msvcr70 and probably also in system msvcrt
library (at least different _msize() tests confirms it).
This will allow to call __mingw_aligned_msize() on buffer allocated by
MS CRT _aligned_malloc() function from msvcrt.dll, msvcr70.dll and
msvcrt71.dll CRT libraries. This is very useful because these CRT libraries
do not have _aligned_msize() function and hence mingw-w64 could emulate it
via __mingw_aligned_msize().
Signed-off-by: Martin Storsjö <martin@martin.st>
Its API is same as MS CRT _aligned_msize() function.
It can be used only on the memory allocated and returned by the
__mingw_aligned_offset_malloc() and __mingw_aligned_offset_realloc()
functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
Functions _aligned_free(), _aligned_malloc(), _aligned_offset_malloc(),
_aligned_offset_realloc() and _aligned_realloc() are available since
msvcr70.dll. For older CRT import libraries provide emulation via
mingw functions __mingw_aligned_free(), __mingw_aligned_malloc(),
__mingw_aligned_offset_malloc(), __mingw_aligned_offset_realloc() and
__mingw_aligned_realloc(). msvcrt.dll will use system implementation if
available, otherwise transparently fallback to mingw version.
Signed-off-by: Martin Storsjö <martin@martin.st>
There is already declaration for msvcrt _aligned_offset_malloc() function,
so add export also declaration for mingw __mingw_aligned_offset_malloc()
function.
At the same time, remove also uneeded declaration of this function from
mingw-w64-crt/misc/mingw-aligned-malloc.c file and use the new one from
malloc.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was changed erroneously in
95ad23696f57b0f966525b574096bd53d48c773a; fabsf is only available
on arm/aarch64 - it doesn't have anything to do with whether
we are compatible with UCRT regarding long doubles.
Also fix _o_fabsf in ucrtbase-common.def.in which also was changed
erroneously in the same way.
Signed-off-by: Martin Storsjö <martin@martin.st>
Calls to this are synthesized by the linker where it is used for calling
into import libraries, this is referred to as an 'Adjustor Thunk' in
ARM64EC documentation.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
These are populated by the linker, and then used by the loader and
emulator at runtime to allow for ARM64EC <-> X86_64 interoperability.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
This introduces basic ARM64EC build support by reusing a modified ARM64
configuration. In the future, the goal is to include both native and
ARM64EC object files in aarch64 archives.
This setup is still subject to change.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
These macros are to be used with `fesetenv()`, so they belong there.
Having these `selectany` variables in 'fenv.h' causes them to be defined with
external linkage in every source file which includes 'fenv.h'. They can also
be exported inappropriately from a DLL, which either is built with
`--export-all-symbols`, or does not contain explicit `dllexport` and is not
built with a DEF file.
Signed-off-by: LIU Hao <lh_mouse@126.com>
This partially reverts dbb60ad07c29830, which accidentally removed __x86_64__
check. The change is not needed for ARM64EC, which defined __x86_64__ too.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Previously, GNU make would delete the implicit intermediate .a/.def
files after building, see [1] for details.
Not deleting them does inflate the size of the build directory a
little bit, but only very marginally (from 201 to 213 MB for a
build with GCC for x86_64).
By keeping them around, they are easier to inspect if debugging
some aspect of them. (Although I haven't really needed to do
this - this isn't the main motivation.)
By not removing them, a build of mingw-w64-crt doesn't end with
a huge wall of text of make doing "rm <all-implicit-files>",
making it easier to observe the output of the other compile
commands instead.
[1] https://www.gnu.org/software/make/manual/html_node/Chained-Rules.html
Signed-off-by: Martin Storsjö <martin@martin.st>
If configuring mingw-w64-crt with the autoconf/automake config
option --enable-silent-rules, the default automake rules will
print e.g. " CC misc/lib64_libmsvcrt_extra_a-wctype.o"
when compiling such a file. However, any custom makefile rules
will still be printed as usual.
Respect the --enable-silent-rules flag on our custom rules;
by adding $(AM_V_GEN) on rules, it will print e.g.
" GEN lib64/msvcrt.def" instead of the command, if
configured with that flag, or if building with "make V=0".
By adding $(AM_V_at) on rules, that command won't be printed
at all, when building with silent rules.
By enabling silent rules, the output is much less verbose, and
it is easier to spot e.g. compiler warnings.
See [1] for more details on automake silent rules.
[1] https://www.gnu.org/software/automake/manual/html_node/Automake-Silent-Rules.html
Signed-off-by: Martin Storsjö <martin@martin.st>
On ARM64EC, function declarations have additional nuances:
- Function names are mangled by prefixing them with "#"
- An unmangled symbol is defined as a weak anti-dependency alias to the mangled
symbol
- An entry thunk is generated to convert from the x86_64 calling convention to
the ARM64EC calling convention, used by the emulator
- A .hybmp section entry is generated to associate the function with its entry
thunk
The compiler can handle all of this if provided with the necessary information.
Naked functions are the most convenient way to achieve this.
Use naked functions only on Clang. GCC doesn’t support them on ARM targets and
has broken behavior on x86_64 by emitting .seh_endprologue.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
mingw-w64-crt implements a number of functions that the compiler considers
built-in. Currently, we must be cautious about compiler optimizations, as they
may not align with our intentions. In theory, the compiler could optimize an
implementation of such a function back into a call to itself.
Rather than second-guessing the optimizer and reimplementing problematic
functions in assembly, disable built-in functions globally for mingw-w64-crt.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
In preparation for building the CRT with -fno-builtin. This allows the compiler
to zero memory without making an actual library call.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
In preparation for building the CRT with -fno-builtin. This allows the compiler
to zero memory without making an actual library call.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
In preparation for building the CRT with -fno-builtin. This allows the compiler
to zero memory without making an actual library call.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
In preparation for building the CRT with -fno-builtin. This allows the compiler
to zero memory without making an actual library call.
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
This function is available since MSVCR110.
Required for https://sourceforge.net/p/mingw-w64/mailman/message/59164037/
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Co-authored-by: LIU Hao <lh_mouse@126.com>
Signed-off-by: LIU Hao <lh_mouse@126.com>
The _S_IFBLK macro, used to identify block special files in file systems, is
being updated from 0x3000 to 0x6000. This change aligns mingw-w64 with the more
commonly used value across Unix-like systems and other C libraries.
The old value of 0x3000 may have caused compatibility issues when working with
code that assumes the standard 0x6000 value for S_IFBLK.
This update improves cross-platform compatibility and consistency with other
systems, making it easier to write portable code that deals with file type
identification. It also reduces potential confusion and errors that might arise
from the non-standard value.
One of these is for example python. This is only an example. It does not change
the fact that python should be more careful about actual value implementation.
Note that the current value implies character device + FIFO instead of
character device + directory.
Link: f819900245/Python/fileutils.c (L1197)
Link: 81e4f8d68c/include/uapi/linux/stat.h (L13)
Signed-off-by: Daniel Starke <daniel-email@gmx.net>
Signed-off-by: LIU Hao <lh_mouse@126.com>
