EinarElen
commented
2 months ago I think you will see a similar effect if you build with clang instead of GCC
Open tomeichlersmith opened 2 months ago
EinarElen
commented
2 months ago I think you will see a similar effect if you build with clang instead of GCC
tvami
commented
2 months ago I think you will see a similar effect if you build with clang instead of GCC
Yes, I can confirm that. But takes similarly long time.
tomeichlersmith
commented
2 months ago I was able to create a very small repo reproducing the error: https://github.com/tomeichlersmith/ldmx-factory-test-bench much faster to compiler and play around with :smile:
tomeichlersmith
commented
2 weeks ago I thought I was able to figure out what was happening. Look at the repo I created above for the details, but the TLDR is that static variables are library-local unless we explicitly tell the linker to allow for dynamic symbols (i.e. sharing/exporting symbols) such that the library we load can share the same singleton as the executable. I don't know why this was only showing itself as an error when trying to enable LTO since I also can observe the error without LTO.
However, while this appears to replicate the issue observed here and is resolved by adding the ENABLE_EXPORTS property to the executable, applying this strategy here does not work. I made the following edits and then tried rebuilding with clang and LTO and the same error occurrs.
diff --git a/Framework/CMakeLists.txt b/Framework/CMakeLists.txt
index e6e30670..10e1abb8 100644
--- a/Framework/CMakeLists.txt
+++ b/Framework/CMakeLists.txt
@@ -81,7 +81,8 @@ set_target_properties(
Framework
PROPERTIES CXX_STANDARD 17
CXX_STANDARD_REQUIRED YES
- CXX_EXTENSIONS NO)
+ CXX_EXTENSIONS NO
+ ENABLE_EXPORTS TRUE)
# the following writes the LinkDef file using the CMake global variables
# namespaces and dict that are lists appended to by the register_event_object function
@@ -128,6 +129,7 @@ install(FILES ${CMAKE_CURRENT_BINARY_DIR}/libFramework_rdict.pcm DESTINATION lib
add_executable(fire ${PROJECT_SOURCE_DIR}/app/fire.cxx)
target_link_libraries(fire PRIVATE Framework::Framework)
install(TARGETS fire DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
+set_property(TARGET fire PROPERTY ENABLE_EXPORTS TRUE)
# Setup the test
setup_test(dependencies Framework::Framework)
diff --git a/SimCore/CMakeLists.txt b/SimCore/CMakeLists.txt
index c80435e4..b66eed99 100644
--- a/SimCore/CMakeLists.txt
+++ b/SimCore/CMakeLists.txt
@@ -92,7 +92,8 @@ setup_library(module SimCore
set_target_properties(SimCore
PROPERTIES CXX_STANDARD 17
CXX_STANDARD_REQUIRED YES
- CXX_EXTENSIONS NO)
+ CXX_EXTENSIONS NO
+ ENABLE_EXPORTS TRUE)
setup_python(package_name LDMX/SimCore)
diff --git a/cmake/BuildMacros.cmake b/cmake/BuildMacros.cmake
index 3716712e..c2bd1f55 100644
--- a/cmake/BuildMacros.cmake
+++ b/cmake/BuildMacros.cmake
@@ -143,6 +143,7 @@ macro(setup_library)
enable_compiler_warnings(${library_name})
enable_ipo(${library_name})
enable_clang_tidy(${library_name} ${WARNINGS_AS_ERRORS})
+ set_property(TARGET ${library_name} PROPERTY ENABLE_EXPORTS TRUE)
# Define an alias. This is used to create the imported target.
set(alias "${setup_library_module}::${setup_library_module}")
Describe the bug The SimCore plugin factory is found unaware of declared plugins when LTO is enabled.
To Reproduce Steps to reproduce the behavior:
and then you see
Desired behavior It'd be cool to be able to enable LTO.
Additional context So, there are actually two different plugin factories in ldmx-sw.
__attribute(init_priority(500))and__attribute__(constructor(1000)))staticvariables to force certain behaviors at library-load-time.The Framework/PluginFactory appears to be working when LTO is enabled since we get to attempting to create the TrackerSD. This implies that the Framework/PluginFactory was already used to declare and create the simulation processor. This causes me to focus attention on SimCore/Factory which works out since I originally designed it. I placed some printouts including the address of the Factory so we can observe the separate Factories being created for the different types. This is what I see.
So LTO does not prevent the declaration process from happening (which is what I assumed was going wrong), but - for some reason - a new Factory is created when attempting to create the TrackerSD instead of using the one that was already created during library-load for declaration. My guess is that I'll need to read-up on the actual meaning of
staticvariable in the context of astaticclass member function. Oofdah.I'll probably try to create a separate testing area since it takes so long to recompile after changing the templated Factory.h header. See my gist about this Factory for more links and probably where I'll put results.