Python failed to build with LINK : error LNK2001: unresolved external symbol on windows using MSVC target ARM64EC

[spacelg]

Hi All,

We try to use msvc to build Python targeting ARM64EC, because there is no ARM64EC configuration in the project files, so we tried to replace the corresponding ARM64 configuration with ARM64EC according to the modification in the PR bpo-36941: Windows build changes for Windows ARM64 (GH-13365), but after rebuilding, it failed in with LINK : error LNK2001: unresolved external symbol on windows using MSVC target ARM64EC, Could you please help look at this issue? Do you have any plans to support windows ARM64EC?

Repro Steps:

1. git clone https://github.com/python/cpython F:\gitP\python\cpython
2. Open a vs2019 x64 cmd && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools\VsDevCmd.bat" -host_arch=amd64 -arch=arm64
3. cd F:\gitP\python\cpython\PCBuild
4. Apply python_ARM64EC.patch (replace the corresponding ARM64 configuration with ARM64EC)
5. build -e -r --no-tkinter -v "/p:PlatformToolset=v142" "/p:WindowsTargetPlatformVersion=10.0.22618.0"

build_arm64ec.log
python_ARM64EC.patch

ErrorMessage:
..
Link:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX64\arm64\link.exe /ERRORREPORT:QUEUE /OUT:"F:\gitP\python\cpython\PCbuild\win32\python3.dll" /INCREMENTAL:NO /NOLOGO /LIBPATH:F:\gitP\python\cpython\PCbuild\win32\ advapi32.lib shell32.lib ole32.lib oleaut32.lib softintrin.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /NODEFAULTLIB:LIBC /MANIFEST:NO /DEBUG /PDB:"F:\gitP\python\cpython\PCbuild\win32\python3.pdb" /SUBSYSTEM:WINDOWS /LTCG /LTCGOUT:"F:\gitP\python\cpython\PCbuild\obj\312win32_Release\python3dll\python3.iobj" /TLBID:1 /NOENTRY /DYNAMICBASE /NXCOMPAT /IMPLIB:"F:\gitP\python\cpython\PCbuild\win32\python3.lib" /MACHINE:ARM64EC /OPT:REF,NOICF /DLL F:\gitP\python\cpython\PCbuild\obj\312win32_Release\python3dll\python_nt.res
F:\gitP\python\cpython\PCbuild\obj\312win32_Release\python3dll\python3dll.obj
10>LINK : error LNK2001: unresolved external symbol PyAIter_Check (EC Symbol) [F:\gitP\python\cpython\PCbuild\python3dll.vcxproj]
10>LINK : error LNK2001: unresolved external symbol PyArg_Parse (EC Symbol) [F:\gitP\python\cpython\PCbuild\python3dll.vcxproj]
10>LINK : error LNK2001: unresolved external symbol PyArg_ParseTuple (EC Symbol) [F:\gitP\python\cpython\PCbuild\python3dll.vcxproj]
10>LINK : error LNK2001: unresolved external symbol PyArg_ParseTupleAndKeywords (EC Symbol) [F:\gitP\python\cpython\PCbuild\python3dll.vcxproj]
10>LINK : error LNK2001: unresolved external symbol PyArg_UnpackTuple (EC Symbol) [F:\gitP\python\cpython\PCbuild\python3dll.vcxproj]
...

[kadler]

I think you need to adjust the output of the macros here: https://github.com/python/cpython/blob/main/PC/python3dll.c#L11-L14

ARM64EC uses a different symbol decoration

For ARM64EC functions with C linkage (whether compiled as C or by using extern "C"), a # is prepended to the decorated name.

Maybe adjust the decoration macro like so: https://github.com/python/cpython/blob/main/PC/python3dll.c#L5-L9

#ifdef _M_IX86
#define DECORATE "_"
#elif defined(_M_ARM64EC)
#define DECORATE "#"
#else
#define DECORATE
#endif

[picnixz]

@zooba Is ARM64EC an architecture CPython is meant to support? or is this kind of target an exotic one? (the patch seems small enough, so maybe we could do something on our side?)

[zooba]

We're not intentionally supporting it right now, but only because nobody has tried to say we should. I'd be interested to hear the reasoning.

If the patch is really that simple then I wouldn't be opposed to taking it.

[kadler]

@picnixz ARM64EC is ARM64 code which is emulation compatible. This means it has an ABI which is can be used to intermix with (emulated) x64 code. You can read more about it here: https://learn.microsoft.com/en-us/windows/arm/arm64ec

Or even more in-depth here: http://www.emulators.com/docs/abc_arm64ec_explained.htm

[picnixz]

Thank you for the resources but I'm no Windows expert at all :) Now, AFAICT, it looks like Windows 11 is required (I think the minimal Windows we're supporting is Windows 8, or maybe even 10, I don't remember). However, if the only change we need to do is this #elif defined(_M_ARM64EC)-guard, then I think we can add it (but still not officially support it).

The question now is more: is it something that is becoming a trend, or something that has lots of use cases in the wild, and where we could improve user experiences by supporting this? Is there also any chance that we need to guard some other places in the code that may not work on ARM64EC for some reasons? (like mimalloc internals or any code that is currently guarded by _M_IX86-macros?)?

[kadler]

One benefit of ARM64EC would be that you could say use an ARM64EC version of Python to use pyodbc to load an ODBC driver which does not yet support ARM64 but does support x64.

[kadler]

Thank you for the resources but I'm no Windows expert at all :) Now, AFAICT, it looks like Windows 11 is required (I think the minimal Windows we're supporting is Windows 8, or maybe even 10, I don't remember).

Well, ARM64 wasn't supported on Windows till Windows 10 anyway, so Windows 8 support isn't really a factor there.

However, if the only change we need to do is this #elif defined(_M_ARM64EC)-guard, then I think we can add it (but still not officially support it).

I don't know if there's other changes that need to be addressed. Certainly the JIT support would be affected. I also haven't tested this suggestion I offered to @spacelg. I was just looking to see if ARM64EC was supported here, since I work on an ODBC driver and we're gathering information about what environments we might be loaded in to in an ARM64 Windows environment in order to determine what we need to support if we wanted to support this platform.

The question now is more: is it something that is becoming a trend, or something that has lots of use cases in the wild, and where we could improve user experiences by supporting this?

I think Microsoft is moving this way since it allows a more seamless transition to supporting ARM64 Windows. You can start with all x64 code and slowly recompile parts to be ARM64EC over time and you are not held back by third party plugins which only support x64. However, it does mean that any applications that did make the jump to ARM64 prior to ARM64EC are now incompatible with it (and it's not supported on Windows 10).

IMO Microsoft should have started with this ABI instead of the ARM64 ABI since the ARM64 ABI doesn't give much benefits over ARM64EC while making it significantly easier to port/interoperate existing x64 applications.

Is there also any chance that we need to guard some other places in the code that may not work on ARM64EC for some reasons? (like mimalloc internals or any code that is currently guarded by _M_IX86-macros?)?

ARM64EC code will compile with as if it was x86_64 with _M_AMD64 and _M_X64 set with a further _M_ARM64EC flag set so you can explicitly check this condition. So any place you check for x86_64, you may want/need to add a special case for _M_ARM64EC as well.

[zooba]

I think Microsoft is moving this way since it allows a more seamless transition to supporting ARM64 Windows. You can start with all x64 code and slowly recompile parts to be ARM64EC over time and you are not held back by third party plugins which only support x64.

I think to be properly useful for us, we would need a new platform name win_arm64ec and include win_amd64 as a permitted tag/suffix in that build. The x64 build should get it as well (and flip the priority when running emulated). Without that, I think you'll really have to do some fairly dirty hacks (lying about the platform) to get this to be useful. Otherwise our own platform checks will prevent you making use of it.

That said, I'm okay with those changes coming in as needed. If people want to experiment and need this change to unblock themselves, then let's just do it. Other changes can be discussed on their merits.

[kadler]

I think to be properly useful for us, we would need a new platform name win_arm64ec and include win_amd64 as a permitted tag/suffix in that build. The x64 build should get it as well (and flip the priority when running emulated). Without that, I think you'll really have to do some fairly dirty hacks (lying about the platform) to get this to be useful. Otherwise our own platform checks will prevent you making use of it.

Yes, I agree that this would need to be a separate platform name in order to be truly usable. Presumably changes would be needed in pip to support installing packages built for x64 as well when running ARM64EC.

I don't have much opinion on whether all that effort is worthwhile, though. Right now it's hard to see how much traction Windows ARM64 has.