Fixes for newer ROOT versions on macOS - #156
Merged
Merged
Conversation
Got "error: unknown type name 'uint'; did you mean 'int'?" when building on a recent macOS with Clang from Homebrew.
This avoids weird compile time errors like: *** Break *** bus error [/usr/lib/system/libsystem_platform.dylib] _sigtramp (no debug info) [/usr/lib/dyld] invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const (no debug info) [/usr/lib/dyld] invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const (no debug info) [/usr/lib/dyld] invocation function for block in mach_o::UnsafeHeader::forEachSection(void (mach_o::UnsafeHeader::SectionInfo const&, bool&) block_pointer) const (no debug info) [/usr/lib/dyld] mach_o::UnsafeHeader::forEachLoadCommand(void (load_command const*, bool&) block_pointer) const (no debug info) [/usr/lib/dyld] mach_o::UnsafeHeader::forEachSection(void (mach_o::UnsafeHeader::SectionInfo const&, bool&) block_pointer) const (no debug info) [/usr/lib/dyld] dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const (no debug info) [/usr/lib/dyld] dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const (no debug info) [/usr/lib/dyld] dyld4::JustInTimeLoader::runInitializers(dyld4::RuntimeState&) const (no debug info) [/usr/lib/dyld] dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&) const (no debug info) [/usr/lib/dyld] dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&) const (no debug info) [/usr/lib/dyld] dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&) const (no debug info) [/usr/lib/dyld] dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&) const (no debug info) [/usr/lib/dyld] dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&) const (no debug info) [/usr/lib/dyld] dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&) const (no debug info) [/usr/lib/dyld] dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&) const (no debug info) [/usr/lib/dyld] dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&, lsl::Vector<AuthenticatedValue<dyld4::Loader const*>>&) const (no debug info) [/usr/lib/dyld] dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const::$_0::operator()() const (no debug info) [/usr/lib/dyld] dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const (no debug info) [/usr/lib/dyld] dyld4::prepare(dyld4::APIs&, mach_o::UnsafeHeader const*) (no debug info) [/usr/lib/dyld] dyld4::start(dyld4::KernelArgs*, void*, void*, unsigned long long)::$_1::operator()() const (no debug info) [/usr/lib/dyld] start (no debug info)
This file has always only been used at KATRIN internally, so moving to where it was actually used. This makes sense since the CI pipeline does not touch this file at all, making it very hard to notice issues with it here.
x_min/x_max are always set on the i==0 loop iteration (a port housing always has at least one port), and p0[0]/p0[1] are always set before being read past the discretization loop, but GCC 16 can't prove either invariant under RelWithDebInfo inlining. Initialize them like the neighboring n1/n2 arrays already do. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015FxJDQWXHJjTY21Fc5bP6E
Older ROOT releases (e.g. the prebuilt 6.24.08 used on the Ubuntu 20.04 CI image) don't set ROOT_CXX_STANDARD in their CMake config, so the unconditional FORCE overwrote CMAKE_CXX_STANDARD with an empty string, tripping the "Unsupported C++ standard" check right after it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015FxJDQWXHJjTY21Fc5bP6E
Contributor
|
Thanks for fixing this nasty error! Claude fixed the remaining (very simple) compilation issues. So the PR looks good to me now. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Recent Homebrew versions of ROOT use C++20. That leads to confusing DYDL errors. ROOT requests that one always compiles with exactly their version in the note in https://root.cern/manual/integrate_root_into_my_cmake_project/ . This PR adds logic to ensure that.