Migration a couple of bits to unsigned int.
Note to Zebediah (mainly on second commit of this serie):
- there is also a load of 'uint32_t flags' parameters that I didn't change
(mainly not to change too many things)
Is this something to consider?
- I didn't touch the local variables either.
Maybe it's something to consider also.
--
v2: wined3d: Set location's type to uint32_t.
wined3d: Set flags' type to uint32_t (internal definitions).
wined3d: Set flags's type to uint32_t (external definitions).
https://gitlab.winehq.org/wine/wine/-/merge_requests/1536
On 11/19/22 03:09, Eric Pouech wrote:
> Le 18/11/2022 à 22:45, Alexandre Julliard a écrit :
>> Module: wine
>> Branch: master
>> Commit: c7a97b5d5d56ef00a0061b75412c6e0e489fdc99
>> URL:
>> https://gitlab.winehq.org/wine/wine/-/commit/c7a97b5d5d56ef00a0061b75412c6e…
>>
>> Author: Zebediah Figura <zfigura(a)codeweavers.com>
>> Date: Thu Nov 17 19:32:39 2022 -0600
>>
>> configure: Override PKG_CONFIG_LIBDIR instead of PKG_CONFIG_PATH for
>> 32-bit builds on 64-bit hosts.
>>
>> 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
>>
>> ---
>
> for the record, this patch can break compilation [[ and does <g> ]] when
> the 64bit .pc is installed while the 32bit isn't
>
> (on Fedora, be sure to have the -devel.i686 matching the installed
> -devel.x86_64 packages)
Right. For posterity, there's more discussion on bug 53953 [1]. This
strikes me as probably Fedora's bug, but I think we should probably work
around it in Wine regardless, if nothing else because that's what we've
been doing, and I undid it assuming that Fedora wouldn't be broken.
[1] https://bugs.winehq.org/show_bug.cgi?id=53953