binaryen fails to build from source with LTO (link time optimization) enabled

[apoleon]

Hi

I'm hereby forwarding Debian bug #1015358

Version: 116 OS: Debian unstable Compiler: GCC 13

Debian wants to enable link time optimization in the near future but binaryen 116 fails to build from source when LTO is enabled.

The error seems to be caused by third party code in third_party/llvm-project

third_party/llvm-project/./third_party/llvm-project/include/llvm/ADT/edit_distance.h: In function ‘ComputeEditDistance’:
third_party/llvm-project/./third_party/llvm-project/include/llvm/ADT/edit_distance.h:96:12: error: ‘SmallBuffer’ may be used uninitialized [-Werror=maybe-uninitialized]
third_party/llvm-project/./third_party/llvm-project/include/llvm/ADT/edit_distance.h:61:12: note: ‘SmallBuffer’ declared here
lto1: all warnings being treated as errors
make[4]: *** [/tmp/ccrE0idZ.mk:365: /tmp/ccqqy1Bf.ltrans121.ltrans.o] Error 1
make[4]: *** Waiting for unfinished jobs....
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[kripken]

Would it be possible to build there with -DBUILD_LLVM_DWARF=OFF? That would disable using this third-party code, which is only used for Binaryen's partial DWARF support (edit: because it's partial, I don't think many people actually depend on it. we don't build it into binaryen.js for example).

[apoleon]

Hi, then I get another error because Allocator.h is part of the disabled llvm-project directory

In file included from /<<PKGBUILDDIR>>/src/support/suffix_tree.cpp:16:
/<<PKGBUILDDIR>>/src/support/suffix_tree.h:38:10: fatal error: llvm/Support/Allocator.h: No such file or directory
   38 | #include "llvm/Support/Allocator.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~

[kripken]

Hmm, looks related to @ashleynh's work on the suffix tree. Building just that without LLVM errors it seems. Looks like we don't have a flag to disable the suffix tree, and instead we manually disable it in binaryen.js (emscripten) builds, which do not build LLVM:

https://github.com/WebAssembly/binaryen/blob/003a6ffa56d7d1aa4918170236daaded6211d13b/src/support/CMakeLists.txt#L18-L30

Perhaps we should add such a flag? Another option might be to find a workaround in that source file. I'm not sure how to do that, though, since LTO shouldn't affect compile-time errors... so that error is odd. But @apoleon , does this patch fix things for you?

diff --git a/third_party/llvm-project/include/llvm/ADT/edit_distance.h b/third_party/llvm-project/include/llvm/ADT/edit_distance.h
index 4f5134008..784547108 100644
--- a/third_party/llvm-project/include/llvm/ADT/edit_distance.h
+++ b/third_party/llvm-project/include/llvm/ADT/edit_distance.h
@@ -19,6 +19,11 @@
 #include <algorithm>
 #include <memory>
 
+// XXX BINARYEN avoid a compiler warning here
+//     https://github.com/WebAssembly/binaryen/issues/5946
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
+
 namespace llvm {
 
 /// Determine the edit distance between two sequences.
@@ -99,4 +104,7 @@ unsigned ComputeEditDistance(ArrayRef<T> FromArray, ArrayRef<T> ToArray,
 
 } // End llvm namespace
 
+// XXX BINARYEN
+#pragma GCC diagnostic pop
+
 #endif

If it works then it might be the quickest fix here.

[apoleon]

The patch didn't make a difference for me. I still get the same error. But when I set the ENABLE_WERROR flag in CMakeLists to OFF instead, it works. Maybe there is a better solution but as a quick workaround it already helps.