Closed Tobias-Fischer closed 1 year ago
I hope this is fixed with https://github.com/RoboStack/ros-humble/commit/f6fc7c6d6b80fd18dfe7e9c085d4c4f8fd30a0ba
Now we are running into a similar problem for moveit-setup-core-plugins. However, the solution does not seem to be as easy:
Auto build dll exports
Creating library C:/bld/ros-humble-moveit-setup-core-plugins-0_1671081099777/work/build/Release/moveit_setup_core_plugins.lib and object C:/bld/ros-humble-moveit-setup-core-plugins-0_1671081099777/work/build/Release/moveit_setup_core_plugins.exp
configuration_files.obj : error LNK2019: unresolved external symbol "public: static class std::vector<struct moveit_setup::TemplateVariable,class std::allocator<struct moveit_setup::TemplateVariable> > moveit_setup::TemplatedGeneratedFile::variables_" (?variables_@TemplatedGeneratedFile@moveit_setup@@2V?$vector@UTemplateVariable@moveit_setup@@V?$allocator@UTemplateVariable@moveit_setup@@@std@@@std@@A) referenced in function "public: void __cdecl moveit_setup::core::ConfigurationFiles::loadFiles(void)" (?loadFiles@ConfigurationFiles@core@moveit_setup@@QEAAXXZ) [%SRC_DIR%\build\moveit_setup_core_plugins.vcxproj]
moc_start_screen_widget.obj : error LNK2001: unresolved external symbol "public: static struct QMetaObject const moveit_setup::SetupStepWidget::staticMetaObject" (?staticMetaObject@SetupStepWidget@moveit_setup@@2UQMetaObject@@B) [%SRC_DIR%\build\moveit_setup_core_plugins.vcxproj]
moc_configuration_files_widget.obj : error LNK2001: unresolved external symbol "public: static struct QMetaObject const moveit_setup::SetupStepWidget::staticMetaObject" (?staticMetaObject@SetupStepWidget@moveit_setup@@2UQMetaObject@@B) [%SRC_DIR%\build\moveit_setup_core_plugins.vcxproj]
moc_author_information_widget.obj : error LNK2001: unresolved external symbol "public: static struct QMetaObject const moveit_setup::SetupStepWidget::staticMetaObject" (?staticMetaObject@SetupStepWidget@moveit_setup@@2UQMetaObject@@B) [%SRC_DIR%\build\moveit_setup_core_plugins.vcxproj]
%SRC_DIR%\build\Release\moveit_setup_core_plugins.dll : fatal error LNK1120: 2 unresolved externals [%SRC_DIR%\build\moveit_setup_core_plugins.vcxproj]
I guess we need to extend moveit-setup-framework with export visibility headers? This was done for many packages in https://github.com/ros-planning/moveit2/pull/530 but not for moveit-setup-framework. What do you think @traversaro?
Note that set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
already happens in the moveit_package
macro .. :(
Note that
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
already happens in themoveit_package
macro .. :(
That does not work for static variables. For those we need to manually export the visibility.
I’m going to use this issue as a general windows build issue thread. On another build something I haven’t seen before:
RuntimeError: copy_symlink: The file or directory is not a reparse point.:
"C:\Users\runneradmin\conda_pkgs_dir\libignition-physics5-5.2.0-hef61a30_2\Library\lib\ign-physics-5\engine-plugins\ignition-physics-bullet-plugin.dll",
"C:\bld\ros-humble-ros-gz-sim-0_1671085464153\_h_env\Library\lib\ign-physics-5\engine-plugins\ignition-physics-bullet-plugin.dll"
https://github.com/RoboStack/ros-humble/actions/runs/3701570027/jobs/6270998023
this might be one for you @wolfv?
EDIT: See https://github.com/conda-forge/libignition-physics-feedstock/pull/31
Note that
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
already happens in themoveit_package
macro .. :(That does not work for static variables. For those we need to manually export the visibility.
Sorry, I was brief as I was on the phone. Yes, for static variables CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS
does not, work, so you manually need to set the visibility flag, quoting from https://www.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/ :
This should turn all add_library calls that do not explicitly specify build type into shared builds. If there are no global data variables in the project, all libraries will be built as DLLs with no errors. If you run into undefined symbols, check for global data like static data members of classes. The easiest way to handle the global data is to use the CMake GenerateExportHeader module like this:
add_library(mylibrary ${mylibrary_SOURCES}) # add these lines include(GenerateExportHeader) generate_export_header(mylibrary)
// edit the source like this:
#include <mylibary_export.h> class myclass { static mylibrary_EXPORT int GlobalCounter; …
Note, if you use GenerateExportHeader and still want static builds to work, you will need to add a -Dmylibrary_STATIC during static builds. See the generated mylibary_export.h for more details.
In practice, this is a bit more tricky as we also need to make sure that the export header is properly installed, anyhow we can follow the structure of other moveit2 libraries.
Thanks @traversaro! I created a new branch in my moveit2 fork and provided you with access to it: https://github.com/Tobias-Fischer/moveit2/tree/export_headers
Let's see whether this fixes the issue ..
Ok, seems like I found the culprit for the symlink error on Windows as well: https://github.com/conda-forge/libignition-physics-feedstock/pull/31
Both issues have been resolved .. let's see what's next ;)
So we should have ros-humble-desktop-full, ros-humble-moveit2 and ros-humble-navigation2 any second now. Any chance anyone could test whether rviz2 and moveit2 works?
So we should have ros-humble-desktop-full, ros-humble-moveit2 and ros-humble-navigation2 any second now. Any chance anyone could test whether rviz2 and moveit2 works?
I tried rviz2 and it works. Do you have some simple check for moveit2 ? I tried the tutorial, but they do not work on Windows due to common Windows compilation problems (M_PI, ..).
Awesome re rviz, thanks for checking. I’m not sure re moveit - I’ll have a look later
For moveit-setup-framework, we have the following linker error:
I'm not sure why this occurs - rviz_common is added as a dependency correctly in https://github.com/ros-planning/moveit2/blob/e65f457734b3c9dc992d11a382651a058a3bcaa4/moveit_setup_assistant/moveit_setup_framework/CMakeLists.txt#L58
Sorry to bother you again @traversaro, but do you have any idea?