Stub out llvm::sys::fs::detail::directory_iterator_destruct for GCC 16#8559
Conversation
...which appears to instantiate the llvm::sys::fsdirectory_iterator destructor from llvm/Support/FileSystem.h even when the type is not actively used. That destructor calls llvm::sys::fs::detail::directory_iterator_destruct, which is defined in Unix/Path.inc, but which is #if'ed out, causing builds to fail with > [ 87%] Linking CXX shared library lib/libbinaryen.so > /usr/bin/ld.bfd: third_party/llvm-project/CMakeFiles/llvm_dwarf.dir/DWARFUnit.cpp.o: in function `std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() [clone .part.0]': > DWARFUnit.cpp:(.text+0x2665): undefined reference to `llvm::sys::fs::detail::directory_iterator_destruct(llvm::sys::fs::detail::DirIterState&)' > /usr/bin/ld.bfd: DWARFUnit.cpp:(.text+0x2855): undefined reference to `llvm::sys::fs::detail::directory_iterator_destruct(llvm::sys::fs::detail::DirIterState&)' > /usr/bin/ld.bfd: third_party/llvm-project/CMakeFiles/llvm_dwarf.dir/DWARFUnit.cpp.o: in function `llvm::DWARFUnit::~DWARFUnit()': > DWARFUnit.cpp:(.text+0x2c13): undefined reference to `llvm::sys::fs::detail::directory_iterator_destruct(llvm::sys::fs::detail::DirIterState&)' > /usr/bin/ld.bfd: DWARFUnit.cpp:(.text+0x2e2c): undefined reference to `llvm::sys::fs::detail::directory_iterator_destruct(llvm::sys::fs::detail::DirIterState&)' > /usr/bin/ld.bfd: DWARFUnit.cpp:(.text+0x2ff2): undefined reference to `llvm::sys::fs::detail::directory_iterator_destruct(llvm::sys::fs::detail::DirIterState&)' > /usr/bin/ld.bfd: third_party/llvm-project/CMakeFiles/llvm_dwarf.dir/DWARFUnit.cpp.o:DWARFUnit.cpp:(.text+0x4d39): more undefined references to `llvm::sys::fs::detail::directory_iterator_destruct(llvm::sys::fs::detail::DirIterState&)' follow So provide a trivial stub to make the build succeed.
|
Any idea why gcc16 is different here? |
unfortunately not; I had switched to Fedora 44 with |
kripken
left a comment
There was a problem hiding this comment.
Ok, might be a gcc bug somehow, but this seems like a harmless workaround for us here.
|
(I have meanwhile broken this down to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124744 "shared_ptr destructor instantiates unrelated make_shared from inline constructor never called". Lets see what the GCC folks say, and whether this workaround will ultimately be needed or should be reverted.) |
It is not a GCC bug, the code is illformed but no diagnostic required as the undefined references exist. In this case GCC is doing speculatively devirtualization and picking up ones which are not normally used. There is no wrong code happening because the speculatively devirtualization does a check on the vtable entry. Anyways the code itself is illformed. |
|
Very interesting, thanks @stbergmann @pinskia ! I guess we'll leave this workaround in the code. Eventually we may update all this third-party code, and hopefully it won't be needed then. |
...which appears to instantiate the llvm::sys::fsdirectory_iterator destructor from llvm/Support/FileSystem.h even when the type is not actively used. That destructor calls llvm::sys::fs::detail::directory_iterator_destruct, which is defined in Unix/Path.inc, but which is #if'ed out, causing builds to fail with
So provide a trivial stub to make the build succeed.