gcc currently assumes the stack alignment for i686-w64-mingw32 is 16, which is
essentially wrong. It works around this in most cases by applying -mstackrealign
when SSE is in use. However, this doesn't address the case of manually aligned
types (i.e. DECLSPEC_ALIGN), and it also for some reason doesn't seem to apply
when -mavx512f is in use, which seems to be an independent gcc bug.
The correct solution on the gcc end is not to assume that the stack is 4-byte
aligned. -mpreferred-stack-boundary=2 achieves exactly this, and there is motion
upstream to address this by effectively making this setting the default. Since
this will take time to propagate downstream, though, it seems prudent to address
this bug locally by essentially applying the same fix downstream.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55007
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55899
This fixes a regression from 450c358881dbc6dcfb2692b8f4debb7db8fdc54b;
after testing for -Wl,-z,defs, CFLAGS was restored from an
incorrect variable, leaving CFLAGS essentially empty.
This would break builds for e.g. arm with Clang, where -mthumb would
be essential for being able to build some inline assembly snippets
correctly.
This also had the effect of dropping the default "-g -O2" arguments
from CFLAGS.
Signed-off-by: Martin Storsjö <martin@martin.st>
The header is unused, and the header check fails with:
configure:7860: checking for PCSC/pcsclite.h
configure:7860: gcc -m32 -c -g -O2 conftest.c >&5
In file included from conftest.c:50:
[...]/include/PCSC/pcsclite.h:45:10:
fatal error: wintypes.h: No such file or directory
45 | #include <wintypes.h>
| ^~~~~~~~~~~~
Fixes: d405a688ba
For example, currently, if --enable-archs=i386,x86_64 is used, and there is an
x86_64 cross compiler present but no i386 cross compiler, Wine will silently
remove i386 from the list of cross-compiled architechtures, and only compile
PE code for x86_64. This seems quite undesirable.
I am not aware of any practical reason for this to happen. Debian does ship
i686 and x86_64 MinGW compilers in separate packages, though, so it is possible
in theory.
It's a clean-room reimplementation that mimics Windows 10 program's output format.
It prints all the information that is available via KerbQueryTicketCacheMessage.
Also tested to work on Windows if dynamically linked + built with winegcc.
For further extension of the functionality, implementing
KerbQueryTicketCacheEx{,2,3}Message is required.
A zerofill section is the only way to reserve address space and prevent
system frameworks from using it, including preventing allocations
before any preloader code runs:
- starting with Ventura, dyld allocates private memory from 0x1000-0x81000.
This breaks EXEs that have an image base of 0x10000.
- Rosetta allocates memory starting at 0x100000000, which breaks EXEs based there.
- starting with Monterey, for proper 10.7 binaries (which include a __program_vars section),
libSystem initializes itself before the preloader runs. This fragments the <4GB
address space which is needed for Wow64.
This will need to be adjusted if any EXEs based at 0x200000000 or higher
are found.
