[Pkg-d-devel] Bug#857085: terminix FTBFS on armhf: Error executing /usr/bin/ldc2: Segmentation fault

Matthias Klumpp mak at debian.org
Tue May 23 08:16:58 UTC 2017


Cc Sylvestre Ledru as he maintains LLVM and might know best about
changes done in the LLVM toolchain in Debian.

I uploaded an LDC to unstable yesterday with no changes but it's LLVM
dependency changed to build against LLVM 4.0. With that version, the
bug did not happen at all on the buildds.
To be really certain it was gone, I used the harris porterbox again to
see if it compiles the exact version of Terminix correctly now, and
indeed it does.
Then, I tried to build Terminix with the exact LDC version from
Stretch before, and the bug also didn't show (4 builds in a row, just
to be sure - the bug did *always* happen on harris before). I had a
manually compiled version of LDC on that machine still, from previous
attempts to debug the issue, that was compiled with LLVM 3.8 last, and
building with that also didn't show the bug anymore.

So, LDC 1.1.1 built with LLVM 3.8, 3.9 and 4.0 in Stretch and Sid does
not actually show this bug anymore. When jcristau removed LDC from
Stretch (yes, I am still not happy with the amount of
non-communication that was going on here!), the copy in there was
actually already working, because something else in the toolchain
changed and resolved the issue.

So, this of course might be a bug in LDC that now just doesn't get
triggered anymore because something else has changed, but given the
amount of work put in this bug to find the issue in LDC and the code
where this bug actually happens in LDC, I think it's justified to
assume that this is not actually a bug in LDC at all.

So, what's broken? LLVM 3.9 and 3.8 in Stretch received changes
lately, but I do fail to see anything in the changelog that would have
impacted this bug at all:

```
llvm-toolchain-3.9 (1:3.9.1-8) unstable; urgency=medium

  * Really fix "use versioned symbols" for llvm
    Thanks to Julien Cristau for the patch (Closes: #849098)

 -- Sylvestre Ledru <sylvestre at debian.org>  Tue, 25 Apr 2017 15:10:10 +0200

llvm-toolchain-3.9 (1:3.9.1-7) unstable; urgency=medium

  * Limit the archs where the ocaml binding is built
    Should fix the FTBFS
    Currently amd64 arm64 armel armhf i386

 -- Sylvestre Ledru <sylvestre at debian.org>  Sat, 15 Apr 2017 12:03:30 +0200

llvm-toolchain-3.9 (1:3.9.1-6) unstable; urgency=medium

  * Upload in unstable
  * Bring back ocaml. Thanks to Cyril Soldani (Closes: #858626)

 -- Sylvestre Ledru <sylvestre at debian.org>  Fri, 14 Apr 2017 10:02:03 +0200

llvm-toolchain-3.9 (1:3.9.1-6~exp2) experimental; urgency=medium

  * Add override_dh_makeshlibs for the libllvm or liblldb versions
    Thanks to Julien Cristau for the patch
  * change the min version of the libclang1 symbols to 1:3.9.1-6~
  * Fix the symlink on scan-build-py

 -- Sylvestre Ledru <sylvestre at debian.org>  Tue, 28 Mar 2017 06:32:40 +0200

llvm-toolchain-3.9 (1:3.9.1-6~exp1) experimental; urgency=medium

  [ Rebecca N. Palmer ]
  * Allow '!pointer' in OpenCL (Closes: #857623)
  * Add missing liblldb symlink (Closes: #857683)
  * Use versioned symbols (Closes: #848368)

 -- Sylvestre Ledru <sylvestre at debian.org>  Sun, 19 Mar 2017 10:12:03 +0100

llvm-toolchain-3.9 (1:3.9.1-5) unstable; urgency=medium

  * Fix the incorrect symlink to scan-build-py (Closes: #856869)

 -- Sylvestre Ledru <sylvestre at debian.org>  Sun, 12 Mar 2017 10:01:10 +0100
```

There were also GCC updates, and quite a bit of other stuff has
changed as well, but since LDC now compiles the code correctly without
being recompiled itself, I think it's safe to rule out any bug in GCC
(as that's only used to build the C++ parts of LDC, and a
wrong-codegen bug would have persisted in the binaries).

Not exactly sure where to go from here, but unless some major
revelation about this bug happens, I am very inclined to just close it
in a few weeks (and in case something like this happens again, we can
file a new bug).

@Sylvestre: I know it's a long shot, but do you maybe know about
anything in LLVM that could have altered the codegen in any way,
recently in Stretch? From the changelogs, it doesn't really look like
it, but maybe I am missing something. Context on this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857085#41

Cheers,
    Matthias



More information about the pkg-gnome-maintainers mailing list