Avogadro 1.97.0 doesn't run on Windows 11 ARM

General Discussion Support
21

Okay, here’s a semi-hacky way to make progress:

include_directories(${CMAKE_CURRENT_BINARY_DIR}/../../rendering)

I might have that somewhat off. The basic idea is to add the relative path to the rendering header.

22

Ok yes perfect, adding along the lines of:

target_link_libraries(Navigator PRIVATE Avogadro::Rendering Avogadro::QtOpenGL)

target_include_directories(Navigator
  PRIVATE
    ${CMAKE_CURRENT_BINARY_DIR}/../../rendering
    ${CMAKE_CURRENT_BINARY_DIR}/../../qtopengl)

solves the problem.

Just so it’s recorded somewhere, I had to add similar code to CMakeLists.txt for many of the files in qtplugins:

  • AlignTool
  • BondCentric
  • Editor
  • Focus
  • LabelEditor
  • Manipulator
  • MeasureTool
  • Navigator
  • PlayerTool, also had to add Qt6::OpenGL and Qt6::OpenGLWidgets as dependencies
  • ResetView, also had to add Qt6::OpenGLWidgets as a dependency
  • Selection
  • Surfaces, also had to add Qt6::OpenGL as a dependency

As noted, some things required extra dependencies to work, so I added them on a case by case basis using e.g. find_package(Qt6 REQUIRED COMPONENTS OpenGL OpenGLWidgets), hope that’s ok.

The naming of BondCentric and Selection seemed a little inconsistent with MeasureTool, AlignTool etc. given that the actual files are called bondcentrictool.cpp and selectiontool.cpp, but there’s probably a reason for that.

After also adding Qt6::OpenGL and Qt6::OpenGLWidgets as dependencies within the if(QT_VERSION EQUAL 6) conditional in avogadroapp/avogadro/CMakeLists.txt the whole thing successfully compiles! :tada:

The graphical bugs I get on Wayland with the Qt5 version are still there though, so there’s plenty still to do. I will take a look at the whole GLEW thing to begin with I guess. But the fact it compiles and runs seems like a significant first step.

23

Wait, I thought you were trying the Windows / ARM build? Or are you saying that Windows is showing graphical bugs like the Linux / Wayland version?

I’d suggest submitting a pull request and we can go from there - some of this is probably a bug in the header searches.

If you want to rename the directories, I’d be happy to take a pull request. I suspect it was just some initial naming inconsistencies which no one has bothered to change.

Thanks for the work - it sounds like Windows / ARM will be a bit more exciting in 2024, and no doubt there are others interested in using Avogadro on a Surface.

24

Nope, for now this has all been under Linux. I’ll have a go at Windows at some point soon.

25

From the Qt blog:

On the desktop, we have been working on Windows and Linux support for ARM architecture. The Qt 6.6 distribution does not include binary packages for those platforms, but you can make your own build of Qt 6.6 for those platforms using the same process as for x86 architecture. With Qt 6.7 we plan to make official ARM packages available for all desktop operating systems.

Since Qt 6.7 will likely see an April release I may just wait until then to deal with the Windows arm64 version. If the Qt6 build of Avogadro is at some point up and running as Win x64, macOS universal, and Linux x64 builds, I feel like arm64 shouldn’t be an issue.

Do you currently build for Windows by cross-compiling? That would allow me to cross-compile from my Linux machine and test my builds with Windows’ x64-on-arm64 emulation, which currently doesn’t work. I’m not having a lot of fun trying to set up Windows as a dev environment :smiling_face_with_tear:

If I do further work on Qt6, where would be a sensible thread to discuss it?

26

I’d create a new thread.

As for Windows compiles, we use GitHub actions to build everything. In theory you can tell VS x86 to cross-compile for Windows ARM, but I’ve never been able to test it.