Hi, more compilation questions sorry.
In one particular configuration everything is compiling, but the build fails at the last hurdle due to one small linking error:
[100%] Linking CXX executable ../bin/avogadro2
/usr/bin/ld: CMakeFiles/avogadro.dir/mainwindow.cpp.o: undefined reference to symbol '_ZN8Avogadro9Rendering6Camera12setModelViewERKN5Eigen9TransformIfLi3ELi2ELi0EEE'
/usr/bin/ld: /home/matt/avo/openchemistry/build/prefix/lib64/libAvogadroRendering.so.1: error adding symbols: DSO missing from command line
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
The error is the same with gcc and clang, and with both GNU Make files and Ninja (though it appears at different stages of the compilation).
I’ve found info on this sort of error here, further ideas on how to fix it here, and advice here on how to set the necessary flags with CMake. However, configuring CMake using flags on the command line like -DCMAKE_STATIC_LINKER_FLAGS="-Wl, --as-needed" (and the variations with EXE, SHARED, MODULE instead of STATIC) don’t seem to do anything, and adding
openchemistry/CMakeLists.txt
...
set (CMAKE_EXE_LINKER_FLAGS "-Wl,--as-needed")
set (CMAKE_MODULE_LINKER_FLAGS "-Wl,--as-needed")
set (CMAKE_STATIC_LINKER_FLAGS "-Wl,--as-needed")
set (CMAKE_SHARED_LINKER_FLAGS "-Wl,--as-needed")
...
also doesn’t seem to change anything (though I haven’t tried a completely fresh build, just rerunning the build command).
Any ideas?
My guess is that libAvogadroRendering.so isn’t being linked into the executable. (That’s the library which should contain that symbol.) I thought that AvogadroRendering would be linked together into the main libavogadro but I guess not? (I don’t know why you’re hitting this when the GitHub builds don’t.)
In avogadroapp/avogadro/CMakeLists.txt there are a bunch of target_link_libraries to make sure that avogadro (the binary) gets linked properly to VTK, etc.
Add in something like this and see if it helps:
target_link_libraries(avogadro Avogadro::Rendering)
I’d also like to know a bit more about what OS you’re using so we can add a GitHub action to build accordingly.
Cheers for the pointers, I’ll give them a try.
This is a Qt6 build I’m trying, hence it being different to the GitHub action. Though I will note that my PR with Qt6 fixes has passed all the automated building tests including the Qt6 ones.
I’ll also have a look at my fixes and see if any of them were actually the opposite…
I’m assuming because you wanted to make sure this doesn’t happen again? If so, don’t worry, as like I said, this is Qt6. With the patched rapidjson you mentioned, the normal Qt5 build works fine 
As it goes though, I’m on openSUSE Tumbleweed.
But if it was that you wanted another reference system to test automated builds against, then maybe Tumbleweed would be a sensible one to add, it being cutting-edge with the latest everything, but also pretty stable due to the testing framework.
Tumbleweed plus the Ubuntu actions (Ubuntu-20.04 and Ubuntu-latest) that are currently in place would provide good checks on how the building proceeds on distros with different degrees of recency. It would help to catch things like the rapidjson issue! Plus it would then match one of the systems that Avogadro is being developed and tested on, I guess.
This was indeed the case. After swapping a PRIVATE declaration in a target_link_libraries to a PUBLIC one, everything builds!
1 Like