Hi,
Not really a complaint at all as it isn’t a big deal to me, but more of a heads up. Possibly you are already aware! In any case, it’s low down on the priority list.
I have a Surface Pro X that runs Windows 11 on ARM. Obviously only programs compiled for ARM run natively, but with Windows 11 it has support for emulation of both 32-bit and 64-bit x86 programs and generally the emulation works pretty well. Unfortunately Avo 1.97 doesn’t run - it just shows a completely white window (with titlebar) for a few seconds before disappearing. Changing between safe/strict emulation in the emulation settings didn’t help either.
I know you’ve been working on an arm64 version for Macs running on M1/M2, I don’t know enough about the architectures to know how transferable the code is.
Environment Information
Avogadro version: 1.97.0 (from Windows installer via two.avogadro.cc)
Operating system and version: Windows 11 Home 22H2 (build 22621.607)
PC: Surface Pro X SQ1, 8GB
I’d need to look into how to compile for ARM using Visual Studio. It’s going to be a bit tricky, since Qt (which we use for the GUI) only supports arm64 as a Windows target with the latest release: Qt for Windows | Qt 6.4
The Mac binaries are built here on my laptop / desktop.
In short, it should be possible, but it might take some time.
Fair enough, and I imagine migration to Qt 6 is something that isn’t even going to be thought about for several years.
The emulation in ARM Windows is normally pretty good (hasn’t failed me for anything else) so it might be easier just to work out why it isn’t running properly in emulation. Is there any way I can debug by starting it in powershell or cmd or something?
No, we’ll probably do it soon … just after we get 2.0 released. At that point, it shouldn’t be too hard to update (e.g. for 2.1).
Possibly. At the very least, we’d know at what point it crashed.
Since the Qt6 porting was merged for 1.98, is there any progress on this? The Windows x86 version of 1.98.1 still crashes on arm64 Windows 11, and I haven’t been able to work out why.
I guess maybe if I try to build it myself that might give a clue?
There’s a bunch of work for Qt6, not least of which is the final cmake / “deploy” scripts. We need a Qt6 version that puts everything in place.
If you’re willing to give it a try, I can send some notes.
Ah ok, I understood that the port was complete, apologies.
Sadly I have essentially no knowledge of C++ so I have a long way to go before I am at the point I can attempt something like that.
Though if you send me the notes anyway, I can have a look at whether anything is within my capabilities! Find and replace of imports is something I can do, for example…
It’ll be some cmake work. The first step would be to compile using -DQT_VERSION=6 along the lines of this pull request: Add a build matrix for Qt 6.5 by ghutchis · Pull Request #1282 · OpenChemistry/avogadrolibs · GitHub
IIRC, the problem is that there’s no support for Qt6 in generating the deploy script.
The avogadroapp CMake files need to add in qt_generate_deploy_app_script | Qt Core 6.6.0 which should take care of many things.
I started looking at this, with my first step being compiling with the -DQT_VERSION=6 option. I am already making reasonable progress in that I could fix most thrown errors by updating deprecated code to its Qt6 equivalent. I think I’m pretty close to a compiled program, but have come unstuck at the following:
[ 81%] Performing configure step for 'avogadroapp'
loading initial cache file ~/avo/qt6_build/avogadroapp-prefix/tmp/avogadroapp-cache-Debug.cmake
CMake Deprecation Warning at CMakeLists.txt:10 (cmake_policy):
The OLD behavior for policy CMP0080 will be removed from a future version
of CMake.
The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.
-- Determined Source Version : 1.98.1-10-gf1cfe78
-- Configuring done (0.2s)
CMake Error at ~/avo/qt6_build/prefix/lib64/cmake/avogadrolibs/AvogadroLibsTargets.cmake:225 (set_target_properties):
The link interface of target "Avogadro::QtOpenGL" contains:
Qt::OpenGLWidgets
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
Call Stack (most recent call first):
~/avo/qt6_build/prefix/lib64/cmake/avogadrolibs/AvogadroLibsConfig.cmake:23 (include)
avogadro/CMakeLists.txt:3 (find_package)
I suspect the name of something in avogadrolibs/avogadro/qtopengl/CMakeLists.txt is wrong, but I can’t work out what. I tried swapping out Qt::OpenGLWidgets for Qt6::OpenGLWidgets in the code below:
avogadro_add_library(QtOpenGL)
target_link_libraries(QtOpenGL Avogadro::Rendering Avogadro::QtGui Qt::Widgets)
if(QT_VERSION EQUAL 6)
target_link_libraries(QtOpenGL Qt::OpenGLWidgets)
endif()
but that just results in the same error with the output The link interface of target "Avogadro::QtOpenGL" contains: Qt6::OpenGLWidgets etc.
libQt5OpenGL, libQt5OpenGL-devel, libQt6OpenGL6, libQt6OpenGLWidgets6, qt6-opengl-devel, and qt6-openglwidgets-devel are all installed, if that helps (though of course the package names vary from distro to distro – I’m on Tumbleweed)
Any ideas?
You probably need something like this (see QOpenGLWidget Class | Qt OpenGL)
find_package(Qt6 REQUIRED COMPONENTS OpenGLWidgets)
target_link_libraries(mytarget PRIVATE Qt6::OpenGLWidgets)
Ok yes, I tried things along those lines but not quite the right thing. It seems that PRIVATE is required.
It gets a little further now, but now I run into the problem that many of the header files in avogadrolibs/avogadro/rendering try to include “avogadrorenderingexport.h”, but this doesn’t exist anywhere that I can see. I tried changing it to simply avogadrorendering.h, but then I get so many resulting errors of various things not having been declared or are missing from classes etc. that I can’t see that being the intended import target.
The various avogadro…export.h headers are created by cmake, e.g. avogadro/rendering/CMakeLists.txt … it should end up in your build directory, e.g.
./avogadrolibs/avogadro/rendering/avogadrorenderingexport.h
Ok yes, I can see that now. avogadrorenderingexport.h does seem to be generated successfully, as expected.
I am struggling to understand CMake’s output but it seems like Rendering actually builds successfully; the compilation fails during building of qtplugins, when avogadro/qtplugins/aligntool/CMakeFiles/AlignTool.dir/aligntool.cpp.o is being built, which kicks off a chain of dependencies which ends with avogadrorenderingexport.h not being found.
I wonder if the problem is a reference to the source directory somewhere when it should be looking in the binary directory.
I am building in ~/avo/qt6_build/ and the source directory is ~/avo/openchemistry/
The error message looks like:
[ 42%] Building CXX object avogadro/qtplugins/aligntool/CMakeFiles/AlignTool.dir/aligntool.cpp.o
In file included from ~/avo/openchemistry/avogadrolibs/avogadro/qtopengl/glwidget.h:13,
from ~/avo/openchemistry/avogadrolibs/avogadro/qtplugins/aligntool/aligntool.cpp:13:
~/avo/openchemistry/avogadrolibs/avogadro/rendering/glrenderer.h:9:10: fatal error: avogadrorenderingexport.h: No such file or directory
9 | #include "avogadrorenderingexport.h"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
As I said, ~/avo/qt6_build/avogadrolibs/avogadro/rendering/avogadrorenderingexport.h exists.
Any ideas? I’ve scoured the CMakeLists.txt files and picked ChatGPT’s brains, but am no closer to solving the problem.
Given that avogadro/rendering/CMakeLists.txt starts with:
find_package(OpenGL REQUIRED)
find_package(GLEW REQUIRED)
if(WIN32 AND NOT BUILD_SHARED_LIBS)
add_definitions(-DGLEW_STATIC)
endif()
add_library(Rendering)
...
…is this anything to do with glew?
Right, but if the build directory isn’t put into the search path for headers, it won’t find it.
I’m not sure how you’re building … ninja?
Maybe try running with -DCMAKE_VERBOSE_MAKEFILE=ON so we can see what paths are used in compilation.
I’m very sorry that so far me helping is mostly just requiring technical support – I am doing my best to work out things by myself, I swear!
Sure, I got as far as working that out. But I tried to compare to similar file structures in the other directories under avogadro with avogadro*export.h files, and couldn’t see work out why in qtgui etc. the build directory is in the header search path, but not in rendering 
I was using whatever the default is, so I guess cmake > make > gcc? I haven’t compiled much before (xtb once before they had binaries…), but am struggling through…
I tried building using ninja:
~/avo/qt6_build> cmake -G Ninja -DQT_VERSION=6 -DBUILD_MOLEQUEUE=OFF -DCMAKE_VERBOSE_MAKEFILE=ON ../openchemistry/
~/avo/qt6_build> cmake --build .
and get basically the same error still.
I also merged the code changes in your PR #1282 into my fork, just for reference.
You’re porting the build system - it’s not trivial and I assumed it would take a bunch of work.
I want to see the actual call to the compiler (gcc / Visual Studio / whatever) before the error message. It should be something like:
gcc … -I ~/avo/qt6_build/avogadrolibs/avogadro/ -I …
..
In file included from ~/avo/openchemistry/avogadrolibs/avogadro/qtopengl/glwidget.h:13,
from ~/avo/openchemistry/avogadrolibs/avogadro/qtplugins/aligntool/aligntool.cpp:13:
~/avo/openchemistry/avogadrolibs/avogadro/rendering/glrenderer.h:9:10: fatal error: avogadrorenderingexport.h: No such file or directory
…
The key thing is to understand what paths it’s including and what it’s not.
With ninja it all gets put on one line so I’ve added some newlines:
[6/302] Building CXX object avogadro/qtplugins/aligntool/CMakeFiles/AlignTool.dir/aligntool.cpp.o
FAILED: avogadro/qtplugins/aligntool/CMakeFiles/AlignTool.dir/aligntool.cpp.o
/usr/bin/c++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_STATICPLUGIN -DQT_WIDGETS_LIB
-I/home/a/avo/qt6_build/avogadrolibs/avogadro/qtplugins/aligntool
-I/home/a/avo/openchemistry/avogadrolibs/avogadro/qtplugins/aligntool
-I/home/a/avo/qt6_build/avogadrolibs/avogadro/qtplugins/aligntool/AlignTool_autogen/include
-I/home/a/avo/openchemistry/avogadrolibs/avogadro
-I/home/a/avo/qt6_build/avogadrolibs/avogadro
-I/home/a/avo/openchemistry/avogadrolibs
-I/home/a/avo/qt6_build/avogadrolibs
-I/home/a/avo/qt6_build/avogadrolibs/avogadro/qtgui
-I/home/a/avo/qt6_build/avogadrolibs/avogadro/io
-I/home/a/avo/qt6_build/avogadrolibs/avogadro/core
-I/home/a/avo/qt6_build/avogadrolibs/avogadro/qtopengl
-isystem /home/a/avo/qt6_build/prefix/include/eigen3
-isystem /usr/include/qt6/QtWidgets
-isystem /usr/include/qt6
-isystem /usr/include/qt6/QtCore
-isystem /usr/lib64/qt6/mkspecs/linux-g++
-isystem /usr/include/qt6/QtGui
-Wno-deprecated-declarations -g -Wnon-virtual-dtor -Wno-long-long -Wcast-align -Wchar-subscripts -Wall -Wpointer-arith -Wformat-security -Woverloaded-virtual -fno-check-new -fno-common -pedantic -Wshadow -Wextra -Werror=return-type -std=c++17 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -MD
-MT avogadro/qtplugins/aligntool/CMakeFiles/AlignTool.dir/aligntool.cpp.o
-MF avogadro/qtplugins/aligntool/CMakeFiles/AlignTool.dir/aligntool.cpp.o.d
-o avogadro/qtplugins/aligntool/CMakeFiles/AlignTool.dir/aligntool.cpp.o
-c /home/a/avo/openchemistry/avogadrolibs/avogadro/qtplugins/aligntool/aligntool.cpp
In file included from /home/a/avo/openchemistry/avogadrolibs/avogadro/qtopengl/glwidget.h:13,
from /home/a/avo/openchemistry/avogadrolibs/avogadro/qtplugins/aligntool/aligntool.cpp:13:
/home/a/avo/openchemistry/avogadrolibs/avogadro/rendering/glrenderer.h:9:10: fatal error: avogadrorenderingexport.h: No such file or directory
9 | #include "avogadrorenderingexport.h"
I suppose -I~/avo/qt6_build/avogadrolibs/avogadro/renderer is conspicuous in its absence…
Yes, exactly. Try adding this to the CMakeLists.txt:
target_link_libraries(AlignTool PRIVATE Avogadro::QtOpenGL)
becomes
target_link_libraries(AlignTool PRIVATE Avogadro::Rendering Avogadro::QtOpenGL)
It seems like a number of the tools include Rendering but don’t have it in the CMakeLists.txt, so you might need to do this for a bunch of plugins if it works.
I actually tried that already and sadly it produces an identical error.
I also tried adding
target_link_libraries(AlignTool PRIVATE Avogadro::Rendering Avogadro::QtOpenGL)
target_include_directories(AlignTool PRIVATE avogadro/rendering)
but to no avail.