[ellert]

This Pull request:

Changes or fixes:

While building ROOT 6.42.00-rc1 the linking of rootcling_stage1 fails with

/usr/bin/ld.bfd: interpreter/llvm-project/llvm/lib/libLLVMCodeGen.a(GCMetadataPrinter.cpp.o):(.data.rel.ro.local._ZTVN4llvm17GCMetadataPrinterE[_ZTVN4llvm17GCMetadataPrinterE]+0x20): undefined reference to `llvm::GCMetadataPrinter::beginAssembly(llvm::Module&, llvm::GCModuleInfo&, llvm::AsmPrinter&)'
/usr/bin/ld.bfd: interpreter/llvm-project/llvm/lib/libLLVMCodeGen.a(GCMetadataPrinter.cpp.o):(.data.rel.ro.local._ZTVN4llvm17GCMetadataPrinterE[_ZTVN4llvm17GCMetadataPrinterE]+0x28): undefined reference to `llvm::GCMetadataPrinter::finishAssembly(llvm::Module&, llvm::GCModuleInfo&, llvm::AsmPrinter&)'
/usr/bin/ld.bfd: interpreter/llvm-project/llvm/lib/libLLVMCodeGen.a(GCMetadataPrinter.cpp.o):(.data.rel.ro.local._ZTVN4llvm17GCMetadataPrinterE[_ZTVN4llvm17GCMetadataPrinterE]+0x30): undefined reference to `llvm::GCMetadataPrinter::emitStackMaps(llvm::StackMaps&, llvm::AsmPrinter&)'
collect2: error: ld returned 1 exit status

This commit addresses the issue by moving them from being inline methods in the header file to being implemented methids in the source file.

Seen on Fedora 44 and Fedora rawhide both using gcc 16.2.1.

Checklist:

• tested changes locally
• updated the docs (if necessary)

[ferdymercury]

Thanks, that would modify though LLVM and yet another patch, which is not optimal.

would adding a flag such as -fkeep-inline-functions or -fno-devirtualize avoid the linking error without having to modify LLVM ?

[hahnjo]

Thanks, that would modify though LLVM and yet another patch, which is not optimal.

(just to note, I checked and didn't find any upstream modifications to these two files)

While building ROOT 6.42.00-rc1 the linking of rootcling_stage1 fails with [...]

Seen on Fedora 44 and Fedora rawhide both using gcc 16.2.1.

Hm, this is curious because we have these two platforms in our CI setup. I also don't see anything obviously wrong with inline virtual methods, the compiler should handle them correctly. As this comes from upstream LLVM without modifications from our side, do you see the same when building (vanilla) Clang?