missing Windows on Arm64 natives in CDT #969
Comments
|
Thanks @chirontt - that would be great. We use Docker and cross-compile Windows for x86-64 at the moment. See for example here where we install gcc-mingw-w64-x86-64 and the building documentation for natives How it works is that as part of a PR you provide the DLLs as built with the docker images and explained in the above documentation. Our build verifies, by rebuilding, that the DLLs in your commit match the sources with this script as part of the this GHA workflow There are some challenges we need to overcome to update this workflow for WoA, mostly that we are based on Ubuntu 18.04 LTS at the moment, which I assume doesn't have WoA cross compilers. The timing is good as CDT 12.0 is the next release, so updating this build infrastructure to a new version of Ubuntu is well timed. If you can contribute the sources and identify if such a cross-compiler exists in the Ubuntu ecosystem, I can handle the infra changes. If you want to even make the Dockerfile changes, it would be welcome too. Please let me know how else I can support you on this task. |
To be explicit, at the moment we do not within the project. The Eclipse Foundation does, and if there is no cross-compile option in the same way we are doing it now, we can look at some manual builds on that infrastructure (and automate it if it becomes useful) |
This wouldn't work for WoA, as the current/latest GCC 14 compiler itself doesn't support output of WoA binaries; it will be supported in GCC 15 though in next year's release. In the meantime we have to use a different compiler in WoA, and in my PR #971 I describe in details the MSYS2/CLANGARM64 shell which provides a unixy environment, plus a LLVM-based MinGW compiler package, to successfully re-compile the CDT binaries in WoA. Alternatively, to do cross-compiling from a Windows x64 host, this llvm-mingw compiler may work. And it also provides a Ubuntu tarball, so it might be able to cross-compile to WoA from Linux! I need more research on this compiler. |
|
Does GitHub have any runners that would be suitable? e.g. can we have a GitHub action that builds these files? |
|
If you meant the Windows Arm64 runner then it's only available for "Team and Enterprise Cloud plans", not for the free tiers. Here's the relevant issue about it: actions/runner-images#10820 |
|
Based on (from #971 (comment))
it sounds like it isn't relevant anyways. If it does become relevant, we have access to some non-free resources within the project. |
Refactors the initialization code of PTY to allow code to avoid loading WinPTY if it isn't needed. The previous code would load WinPTY even if ConPTY was in use. To achieve this the code was refactored to have cleaner state with a new field ptyType that replaces isConPTY, isWinPTY and hasPTY. The initialization code has This is needed so that WoA can run without needing to port the unneeded WinPTY library Part of eclipse-cdt#969
Refactors the initialization code of PTY to allow code to avoid loading WinPTY if it isn't needed. The previous code would load WinPTY even if ConPTY was in use. To achieve this the code was refactored to have cleaner state with a new field ptyType that replaces isConPTY, isWinPTY and hasPTY. The initialization code has This is needed so that WoA can run without needing to port the unneeded WinPTY library Part of eclipse-cdt#969
- add a new fragment 'org.eclipse.cdt.core.win32.aarch64' containing re-compiled Arm64 natives suitable for the Windows on Arm64 platform. - add the 'serial.dll' binary re-compiled for Windows on Arm64. - add the win32/win32/aarch64 environment triplet to various Maven build scripts to support building CDT software for that environment. The updated dlls/exes are not included in this commit and will be provided in subsequent commits with the corresponding update to build infrastructure Fixes eclipse-cdt#969
Refactors the initialization code of PTY to allow code to avoid loading WinPTY if it isn't needed. The previous code would load WinPTY even if ConPTY was in use. To achieve this the code was refactored to have cleaner state with a new field ptyType that replaces isConPTY, isWinPTY and hasPTY. This is needed so that WoA can run without needing to port the unneeded WinPTY library. In particular, the winpty.dll and pty.dll are no longer used on WoA. Part of eclipse-cdt#969
- add a new fragment 'org.eclipse.cdt.core.win32.aarch64' containing re-compiled Arm64 natives suitable for the Windows on Arm64 platform. - add the 'serial.dll' binary re-compiled for Windows on Arm64. - add the win32/win32/aarch64 environment triplet to various Maven build scripts to support building CDT software for that environment. The updated dlls/exes are not included in this commit and will be provided in subsequent commits with the corresponding update to build infrastructure Part of #969
Refactors the initialization code of PTY to allow code to avoid loading WinPTY if it isn't needed. The previous code would load WinPTY even if ConPTY was in use. To achieve this the code was refactored to have cleaner state with a new field ptyType that replaces isConPTY, isWinPTY and hasPTY. This is needed so that WoA can run without needing to port the unneeded WinPTY library. In particular, the winpty.dll and pty.dll are no longer used on WoA. Part of #969
- add a new fragment 'org.eclipse.cdt.core.win32.aarch64' containing re-compiled Arm64 natives suitable for the Windows on Arm64 platform. - add the 'serial.dll' binary re-compiled for Windows on Arm64. - add the win32/win32/aarch64 environment triplet to various Maven build scripts to support building CDT software for that environment. The updated dlls/exes are not included in this commit and will be provided in subsequent commits with the corresponding update to build infrastructure Part of #969
Refactors the initialization code of PTY to allow code to avoid loading WinPTY if it isn't needed. The previous code would load WinPTY even if ConPTY was in use. To achieve this the code was refactored to have cleaner state with a new field ptyType that replaces isConPTY, isWinPTY and hasPTY. This is needed so that WoA can run without needing to port the unneeded WinPTY library. In particular, the winpty.dll and pty.dll are no longer used on WoA. Part of #969
- add a new fragment 'org.eclipse.cdt.core.win32.aarch64' containing re-compiled Arm64 natives suitable for the Windows on Arm64 platform. - add the 'serial.dll' binary re-compiled for Windows on Arm64. - add the win32/win32/aarch64 environment triplet to various Maven build scripts to support building CDT software for that environment. The updated dlls/exes are not included in this commit and will be provided in subsequent commits with the corresponding update to build infrastructure Part of #969
Refactors the initialization code of PTY to allow code to avoid loading WinPTY if it isn't needed. The previous code would load WinPTY even if ConPTY was in use. To achieve this the code was refactored to have cleaner state with a new field ptyType that replaces isConPTY, isWinPTY and hasPTY. This is needed so that WoA can run without needing to port the unneeded WinPTY library. In particular, the winpty.dll and pty.dll are no longer used on WoA. Part of #969
- add a new fragment 'org.eclipse.cdt.core.win32.aarch64' containing re-compiled Arm64 natives suitable for the Windows on Arm64 platform. - add the 'serial.dll' binary re-compiled for Windows on Arm64. - add the win32/win32/aarch64 environment triplet to various Maven build scripts to support building CDT software for that environment. The updated dlls/exes are not included in this commit and will be provided in subsequent commits with the corresponding update to build infrastructure Part of #969
Refactors the initialization code of PTY to allow code to avoid loading WinPTY if it isn't needed. The previous code would load WinPTY even if ConPTY was in use. To achieve this the code was refactored to have cleaner state with a new field ptyType that replaces isConPTY, isWinPTY and hasPTY. This is needed so that WoA can run without needing to port the unneeded WinPTY library. In particular, the winpty.dll and pty.dll are no longer used on WoA. Part of #969
Refactors the initialization code of PTY to allow code to avoid loading WinPTY if it isn't needed. The previous code would load WinPTY even if ConPTY was in use. To achieve this the code was refactored to have cleaner state with a new field ptyType that replaces isConPTY, isWinPTY and hasPTY. This is needed so that WoA can run without needing to port the unneeded WinPTY library. In particular, the winpty.dll and pty.dll are no longer used on WoA. Part of #969
|
@jonahgraham I'm checking out the CDT's But I've seen some disturbing behaviours of
i.e. force the disabling of
and the two terminals share the same I/O for all commands executed in either of them!
Can you reproduce the problem with your Windows |
Yes. The version on winpty is ancient in CDT and when I last tested it it worked fine on a Windows 7 box. The issue is that Windows Console team have been very active in the last few years and it seems the way we (winpty really) is launching the hidden console is not working anymore. If I was a little braver I would rip out winpty implementation entirely. |
BTW and FWIW that is exactly how winpty is supposed to work, just that the window should be hidden. What winpty does is shuffle data back and forth from the hidden window to the integrated window. |
That is fine that you are doing it locally - I am working on ensuring a fully signed/etc version works too. The build is running now after a few false starts and hopefully this one will run to conclusion and there aren't any other small updates that I need to do. I will let you know when it is ready, but you can have a look on https://download.eclipse.org/tools/cdt/builds/cdt/ - there shoudl be a new |
I spun it up on a Windows 11 box and if you use conhost instead of Windows Terminal the window is correctly hidden. WinPTY is only realistically useful if you also use conhost, so that makes sense. This is the Windows setting you have to change to reproduce this:
(And with that I hope that is the last time I have to deal with WinPTY until we decide to delete it from the sources!) |
|
The build was successful. @chirontt can you please try out this p2 site and let me know if it seems ok https://download.eclipse.org/tools/cdt/builds/cdt/support_windows_on_arm64/ |
|
Yes, that p2 site works fine. I use a fresh Eclipse SDK 4.34 package for WoA, and update it with that p2 site to install the needed CDT features/plugins. The |
- add a new fragment 'org.eclipse.cdt.core.win32.aarch64' containing re-compiled Arm64 natives suitable for the Windows on Arm64 platform. - add the 'serial.dll' binary re-compiled for Windows on Arm64. - add the win32/win32/aarch64 environment triplet to various Maven build scripts to support building CDT software for that environment. The updated dlls/exes are not included in this commit and will be provided in subsequent commits with the corresponding update to build infrastructure Part of #969
Refactors the initialization code of PTY to allow code to avoid loading WinPTY if it isn't needed. The previous code would load WinPTY even if ConPTY was in use. To achieve this the code was refactored to have cleaner state with a new field ptyType that replaces isConPTY, isWinPTY and hasPTY. This is needed so that WoA can run without needing to port the unneeded WinPTY library. In particular, the winpty.dll and pty.dll are no longer used on WoA. Part of #969
|
Thanks @chirontt for the contribution and testing the result. I have now merged the fix into main |
Description
Eclipse IDE for C/C++ Developers, version 2024-12, is now available for Windows on Arm64 (WoA):
But running it on a WoA box shows some deficiencies:
Terminalview and choosing theLocal Terminalseems OK (i.e. theCMDwindow is showing properly in a view), but any command entered to that view would show nothing, due to exceptions thrown in the Eclipse console:but the Eclipse console shows some exceptions:
From the above exceptions, I guess those
winptyandspawnerbinaries (for WoA) are not available in the Eclipse IDE package, causing e.g. theTerminalnot working.Version Information
Additional context
Browsing the CDT source code, I notice that there is no WoA native fragment equivalent to the existing one for
x84_64(org.eclipse.cdt.core.win32.x86_64/os/win32/x86_64) so I guess thosepty.dll,spawner.dll,starter.exe,winpty.dll,winpty-agent.exebinaries need be recompiled for WoA, for a neworg.eclipse.cdt.core.win32.aarch64fragment.I will submit a PR for this new fragment for WoA. But the sticky point is: how will the CDT team re-compile those binaries for WoA? (I can't submit the WoA binaries built by me, for obvious security reason.) Does the team have access to a WoA box to build them?
The text was updated successfully, but these errors were encountered: