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. |
…m-opt (#936) Migrate off manually calling wasm-bindgen-cli and wasm-opt. I originally migrated the original toolchain (wasm-bindgen-cli + wasm-opt from cargo), but wasm-opt hasn't had an update since 0.116.1 (2024-03) since it was moved to the binaryen project, which is now at 0.130. The recommended toolchain has become wasm-pack (https://github.com/wasm-bindgen/wasm-pack). See https://blog.rust-lang.org/inside-rust/2025/07/21/sunsetting-the-rustwasm-github-org/. This resolves the issue on Arch BTW, where... something happens on GCC 16 while attempting to compile wasm-opt. See WebAssembly/binaryen#8559. This commit also greatly simplifies the build steps, because wasm-pack will pick to run wasm-opt depending on the build variant.
...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.