This is used by clang to distinguish between MSVC and windows-itanium
targets. We override default option (usually meant for native builds)
to make sure that we use the right target.
This allows 32-bit packages to be found when the user has specified
PKG_CONFIG_PATH for some other reason.
This also mirrors the way e.g. i686-linux-gnu-pkg-config is implemented on
Debian, and possibly other distributions as well.
This also prevents 64-bit .pc files from being found. This was originally
intended as a benefit [1], but can contribute to misdetection of headers which
are not actually multiarch (e.g. GStreamer, although at the time that [1] was
written that was a preëxisting problem). In general a distribution which
provides .pc files for one architecture should be expected to provide them for
any architecture that it actually provides libraries for; even if that was not
true of Debian in 2017, it is now. I moreover assert it is better to fail to
find a present library than to incorrectly find the wrong one.
Note that we can't easily use i686-linux-gnu-pkg-config, as would otherwise be
preferable, for reasons also described in [1].
[1] https://www.winehq.org/pipermail/wine-devel/2017-June/118002.html
Building the loader targeting 10.7 (to generate an LC_UNIXTHREAD binary)
seems to fix an issue in the Mac driver with 10.13 and earlier where
window layers wouldn't update correctly.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52354
Some programs, such as Final Fantasy IV (3D remake), expect strncmp
to return exactly +/-1 when the strings are not equal.
Signed-off-by: Shaun Ren <sren@codeweavers.com>
Clang 16 is defaulting -Wincompatible-function-pointer-types to
an error instead of a warning. This isn't an issue for most of Wine,
but the error shows up in a lot of cases if doing a non-PE build for
ARM (32 bit, 64 has no such issues), in particular around the integration
of libxml2 and faudio.
The root cause of the issue is that some functions are specified with
e.g. __attribute__((pcs("aapcs-vfp"))) - which is equal to the
default calling convention when compiling with -mfloat-abi=hard - but
Clang's warning doesn't treat such function pointers as equal. (This
could maybe be considered a bug or limitation in Clang though.)
There's also some smaller amount of cases where our attributes
actually do conflict, where we mix __attribute__((pcs("aapcs"))), i.e.
arm softfloat calling convention, with the default calling convention
(which is set to hardfloat), but they drown in the noise from the
other ones.
Therefore, on arm, try to downgrade this diagnostic back to a warning,
not an error - while keeping the warnings visible.
Signed-off-by: Martin Storsjö <martin@martin.st>
