New Issue: Upgrade bundled version of 'libunwind' / 'CHPL_LIBUNWIND=bundled' fails to build with 'CHPL_LLVM=bundled'

17597, "bradcray", "Upgrade bundled version of 'libunwind' / 'CHPL_LIBUNWIND=bundled' fails to build with 'CHPL_LLVM=bundled'", "2021-04-23T22:01:27Z"

A user ran into an issue where setting CHPL_LLVM=bundled and CHPL_LIBUNWIND=bundled resulted in build errors like:

libtool: link: /home/mppf/w/master/third-party/llvm/install/linux64-x86_64-gnu/bin/clang -g -fexceptions -Wall -Wsign-compare -o Lperf-simple Lperf-simple.o  ../src/.libs/libunwind.a -lc -lgcc -llzma

/usr/bin/ld: ../src/.libs/libunwind.a(dyn-info-list.o):/home/mppf/w/master/third-party/libunwind/libunwind-1.1/src/mi/dyn-info-list.c:28: multiple definition of `_U_dyn_info_list';
../src/.libs/libunwind.a(Linit.o):/home/mppf/w/master/third-party/libunwind/libunwind-1.1/src/x86_64/Ginit.c:50: first defined here

clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

Investigating, @mppf found https://bugs.gentoo.org/706560 [bugs.gentoo.org] and Fix gcc 10 build (or -fno-common) by djwatson · Pull Request #166 · libunwind/libunwind · GitHub [github.com] which suggested to him that upgrading to a newer bundled version would probably resolve this issue.

A workaround for the time being is to apply the following patch:

diff --git a/third-party/libunwind/Makefile b/third-party/libunwind/Makefile
index 7887a30dbf..797f34434b 100644
--- a/third-party/libunwind/Makefile
+++ b/third-party/libunwind/Makefile
@@ -31,7 +31,7 @@ $(LIBUNWIND_SRC_DIR):
 
 configure-libunwind: FORCE
        mkdir -p $(LIBUNWIND_BUILD_DIR)
-       cd $(LIBUNWIND_BUILD_DIR) && $(LIBUNWIND_SUBDIR)/configure CC='$(CC)' CFLAGS='$(CFLAGS)' CXX='$(CXX)' CXXFLAGS='$(CFLAGS)' $(CHPL_LIBUNWIND_CFG_OPTIONS)
+       cd $(LIBUNWIND_BUILD_DIR) && $(LIBUNWIND_SUBDIR)/configure CC='$(CC)' CFLAGS='-fcommon $(CFLAGS)' CXX='$(CXX)' CXXFLAGS='-fcommon $(CFLAGS)' $(CHPL_LIBUNWIND_CFG_OPTIONS)

but we'd rather upgrade our bundled version to see if it resolves the issue rather than applying this workaround.

This issue also raises the question for me what additional testing we should be doing to become aware of this kind of bit-rot before users encounter it.