Re: [PATCH] Cygwin: resolve AArch64 linking by linking to onecore instead of kernel32

On 05/06/2026 15:37, Jon Turney wrote:
> On 14/07/2025 14:11, Corinna Vinschen wrote:
>> Hi Radek,
>>
>> On Jul 10 19:14, Radek Barton via Cygwin-patches wrote:
>>> Hello.
>>>
>>> As Windows Arm64 platform does not carry historical compatibility 
>>> layers, the structure of Windows API DLLs is cleaner on Arm64 than on 
>>> x64. For this reason, the x64 linking against `kernel32.dll` is not 
>>> sufficient leading to undefined references to many Windows API 
>>> symbols that are in different DLLs that would have to be added to the 
>>> linking command explicitly.
>>>
>>> To address that, there is a concept of umbrella DLLs (https:// 
>>> learn.microsoft.com/en-us/windows/win32/apiindex/windows-umbrella- 
>>> libraries), that can be added instead. The recommended replacement 
>>> for `kernel32.dll` is `onecore.dll` (https://learn.microsoft.com/en- 
>>> us/windows-hardware/drivers/develop/building-for-onecore#building- 
>>> for-onecore) that should be available since Windows 7.
>>>
>>> In case of Cygwin linking, there is one exception, `pdh.dll` 
>>> (Performance Data Helper, https://learn.microsoft.com/en-us/windows/ 
>>> win32/perfctrs/performance-counters-functions), that is not included 
>>> in the `onecore.dll`.
>>
>> The pdh functions used by Cygwin are NOT linked against.  They are
>> runtime loaded (see autoload.cc, right at the end), so it should not be
>> necessary to link against libpdh.a.  Can you please check again?

>   I assume that -lpdh has been added here because the autoload stubs 
> used during aarch64 development translate into direct linkage.
> 
> Hopefully, it's not necessary with a full autoload implementation .

So, my speculation seems to be correct.

The other issue here is that we can't link against non-well-known DLLs 
here without making ourselves vulnerable to DLL hijacking attacks. (This 
detail probably needs to be noted in a comment here).

It's unclear that to me that the onecore umbrella import library makes 
that guarantee? (So we could accidentally introduce the use of an API 
from a non-well-known DLLs without noticing)

So maybe this needs to be conditional on the arch? Or perhaps the 
solution is to autoload the problematic APIs here?