Bug#877567: llvm-toolchain-3.9 FTBFS on mipsel

Adrian Bunk bunk at debian.org
Mon Oct 2 21:15:57 UTC 2017


Source: llvm-toolchain-3.9
Version: 1:3.9.1-17
Severity: serious

https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-3.9&arch=mipsel

...
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.29.1 internal error, aborting at ../../bfd/merge.c:910 in _bfd_merged_section_offset

/usr/bin/ld: Please report this bug.

collect2: error: ld returned 1 exit status
tools/llvm-shlib/CMakeFiles/LLVM.dir/build.make:274: recipe for target 'lib/libLLVM-3.9.so.1' failed
make[4]: *** [lib/libLLVM-3.9.so.1] Error 1


In #874674 it was discovered that this is just a bad
error handling for "out of memory" in ld.


llvm-toolchain-3.9 (1:3.9.1-16) unstable; urgency=medium
...
  [ Matthias Klose ]
...
  * On amd64, s390x, arm64 and ppc64el, build with -g1 instead of -g.
...
 -- Sylvestre Ledru <sylvestre at debian.org>  Fri, 08 Sep 2017 11:57:07 +0200

This is also what debian/rules does, and it is pretty weird:

ifneq (,$(filter $(DEB_HOST_ARCH),amd64 arm64 ppc64el s390x))
  opt_flags += -g1
else
  opt_flags += -g
endif

-g is equal to -g2, so this change reduces the amount of debug
information generated on some 64bit architectures - these are
architectures where -g is supposed to not cause any problems.


mipsel being the only failing release architecture makes sense
considering that -g is used on 32bit, and mipsel is missing in
the list of gsplit dwarf architectures.


There are three alternative approaches, either would make sense
and should fix the mipsel build (untested):

1. go back to -g everywhere and remove ENABLE_SPLIT_DWARF_ARCHS,
   that's then actually required on all 32bit architectures:

ifeq ($(DEB_HOST_ARCH_BITS),32)
  CXXFLAGS_EXTRA += -gsplit-dwarf
endif

2. remove all gsplit dwarf usage and reverse the -g1 handling
   so that it makes sense:

ifeq ($(DEB_HOST_ARCH_BITS),32)
  opt_flags += -g1
else
  opt_flags += -g
endif


3. remove all gsplit dwarf usage and use -g1 on all architectures:

opt_flags += -g1



More information about the Pkg-llvm-team mailing list