reedsolomon build failure

[DanBurton]

Ping @NicolasT

Various errors all said the same thing when the stackage build server tried to build reedsolomon:

/tmp/ghc1485_0/ghc_16.s:902:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_zdfShowVectorzuzdcshow_info$def' {.text section}

[NicolasT]

@DanBurton Is there any more build output available somewhere? FWIW, the package uses TravisCI to build/test against LTS2, LTS3, LTS5 and nightly + some extra tests (e.g. validate sdist contains all required files), CircleCI to build/test against current Hackage and AppVeyor to build/test on Windows using LTS5...

This package compiles with -fllvm by default (can be disabled through a Cabal flag). Could it be the LLVM version on your build system isn't compatible with the GHC version being used? Cfr

• Build issues. mikeizbicki/HLearn#72
• https://mail.haskell.org/pipermail/ghc-devs/2014-December/007525.html

I've never seen anything like the snippet you posted, so some more info (or a way to reproduce?) would be really cool. Disabling LLVM through a package flag could fix this, but then the Stackage build would differ from what's default.

[DanBurton]

I'll run it again with the next nightly and capture the whole log for you.

Could it be the LLVM version on your build system isn't compatible with the GHC version being used?

Quite possible.

Disabling LLVM through a package flag could fix this, but then the Stackage build would differ from what's default.

Yes, I'd rather build it in the "default way". Perhaps @snoyberg has thoughts on this?

[snoyberg]

When Stack builds a package, it will actually respect the flags used by Stackage when building, so it should be relatively safe. That said, I'd probably recommend tweaking the default to not use LLVM in the package itself, since if our build server is having trouble with it, likely end users will too.

[DanBurton]

I found the log file from the other day in its entirety:

> /tmp/stackage-build7$ stack unpack reedsolomon-0.0.4.0
Unpacked reedsolomon-0.0.4.0 to /tmp/stackage-build7/reedsolomon-0.0.4.0/
> /tmp/stackage-build7/reedsolomon-0.0.4.0$ runghc -clear-package-db -global-package-db -package-db=/home/stackage/work/builds/nightly/pkgdb Setup configure --package-db=clear --package-db=global --package-db=/home/stackage/work/builds/nightly/pkgdb --libdir=/home/stackage/work/builds/nightly/lib --bindir=/home/stackage/work/builds/nightly/bin --datadir=/home/stackage/work/builds/nightly/share --libexecdir=/home/stackage/work/builds/nightly/libexec --sysconfdir=/home/stackage/work/builds/nightly/etc --docdir=/home/stackage/work/builds/nightly/doc/reedsolomon-0.0.4.0 --htmldir=/home/stackage/work/builds/nightly/doc/reedsolomon-0.0.4.0 --haddockdir=/home/stackage/work/builds/nightly/doc/reedsolomon-0.0.4.0 --flags=
Configuring reedsolomon-0.0.4.0...
> /tmp/stackage-build7/reedsolomon-0.0.4.0$ runghc -clear-package-db -global-package-db -package-db=/home/stackage/work/builds/nightly/pkgdb Setup build
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether make supports nested variables... (cached) yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for gcc option to accept ISO C99... -std=gnu99
checking how to run the C preprocessor... gcc -std=gnu99 -E
checking for gawk... (cached) mawk
checking for a sed that does not truncate output... /bin/sed
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for ar... ar
checking the archiver (ar) interface... ar
checking for ranlib... ranlib
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for C/C++ restrict keyword... __restrict
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for size_t... yes
checking for ssize_t... yes
checking for uint8_t... yes
checking for uint64_t... yes
checking for __attribute__((always_inline))... yes
checking for __attribute__((const))... yes
checking for __attribute__((hot))... yes
checking for __attribute__((ifunc))... yes
checking for __attribute__((force_align_arg_pointer))... no
checking whether C compiler accepts -Werror=unknown-pragmas... yes
checking whether C compiler accepts -Werror=unused-command-line-argument... no
checking whether C compiler accepts -Werror=unknown-warning-option... no
checking whether C compiler accepts -ggdb3... yes
checking whether C compiler accepts -Wall... yes
checking whether C compiler accepts -Wextra... yes
checking whether C compiler accepts -pedantic... yes
checking whether C compiler accepts -Wno-pedantic-ms-format... yes
checking whether C compiler accepts -Wundef... yes
checking whether C compiler accepts -Wunknown-pragmas... yes
checking whether C compiler accepts -O3... yes
checking whether C compiler accepts -floop-parallelize-all... yes
checking whether C compiler accepts -funroll-loops... yes
checking whether C compiler accepts -ftree-vectorize... yes
checking whether C compiler accepts -fprefetch-loop-arrays... yes
checking whether C compiler accepts -frecord-gcc-switches... yes
checking whether C compiler accepts -fPIC... yes
checking whether C compiler accepts -msse2... yes
checking whether C compiler accepts -mssse3... yes
checking whether C compiler accepts -mavx... yes
checking whether C compiler accepts -mavx2... yes
checking whether Clang's `loop unroll` pragma works... no
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for stdint.h... (cached) yes
checking for unistd.h... (cached) yes
checking cpuid.h usability... yes
checking cpuid.h presence... yes
checking for cpuid.h... yes
checking emmintrin.h usability... yes
checking emmintrin.h presence... yes
checking for emmintrin.h... yes
checking tmmintrin.h usability... yes
checking tmmintrin.h presence... yes
checking for tmmintrin.h... yes
checking immintrin.h usability... yes
checking immintrin.h presence... yes
checking for immintrin.h... yes
checking arm_neon.h usability... no
checking arm_neon.h presence... no
checking for arm_neon.h... no
checking whether vqtbl1q_u8 works... no
checking altivec.h usability... no
checking altivec.h presence... no
checking for altivec.h... no
checking whether vec_vsrd works... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for assumed data alignment... 16
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands

----------------------------------------------------------------------
Configure completed successfully.

    Version: 0.0.4.0
    Compiler: gcc -std=gnu99

    Build platform: x86_64-unknown-linux-gnu
    Host platform: x86_64-unknown-linux-gnu
    Enabled backends: generic, sse2, ssse3, avx, avx2

make  all-am
  CC       reedsolomon_dispatch.o
  AR       libreedsolomon.a
  CC       libreedsolomon_generic_a-reedsolomon.o
  AR       libreedsolomon-generic.a
  CC       libreedsolomon_sse2_a-reedsolomon.o
  AR       libreedsolomon-sse2.a
  CC       libreedsolomon_ssse3_a-reedsolomon.o
  AR       libreedsolomon-ssse3.a
  CC       libreedsolomon_avx_a-reedsolomon.o
  AR       libreedsolomon-avx.a
  CC       libreedsolomon_avx2_a-reedsolomon.o
  AR       libreedsolomon-avx2.a
  CC       reedsolomon-gal-mul-stdio.o
  CCLD     reedsolomon-gal-mul-stdio
Building reedsolomon-0.0.4.0...
Preprocessing library reedsolomon-0.0.4.0...
[ 1 of 11] Compiling Data.Vector.Generic.Sized ( src/Data/Vector/Generic/Sized.hs, dist/build/Data/Vector/Generic/Sized.o )
/tmp/ghc1485_0/ghc_16.s: Assembler messages:

/tmp/ghc1485_0/ghc_16.s:81:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_replicateM_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:101:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_generate_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:141:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_index_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:204:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_fromVector_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:240:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_zdfIsListVectorzuzdctoList_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:347:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_zdfIsListVectorzuzdcfromListN_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:392:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_zdfIsListVectorzuzdcfromList_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:412:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_zdfIsListVector_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:842:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_zdwzdcshowsPrec_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:862:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_zdfShowVectorzuzdcshowsPrec_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:882:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_zdfShowVectorzuzdcshowList_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:902:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_zdfShowVectorzuzdcshow_info$def' {.text section}

/tmp/ghc1485_0/ghc_16.s:922:0:
     Error: can't resolve `.rodata' {.rodata section} - `reedszuCnY2X0htMd7BumXlHm89WN_DataziVectorziGenericziSizzed_zdfShowVector_info$def' {.text section}

[NicolasT]

@snoyberg

When Stack builds a package, it will actually respect the flags used by Stackage when building, so it should be relatively safe.

OK, so that might be a work-around.

That said, I'd probably recommend tweaking the default to not use LLVM in the package itself, since if our build server is having trouble with it, likely end users will too.

Hmh... I did some benchmarks during the initial development of this package, and using LLVM made quite a positive impact. I'll try again (code has changed a lot since).

In general, I really think the build environment should be fixed: -fllvm is a standard GHC feature for quite a while now, and whilst it indeed puts a constraint on the system LLVM version, having a broken toolchain is just that: a broken toolchain. Other package might (unconditionally) use -fllvm as well, right?

@DanBurton That clearly looks like an LLVM version mismatch indeed. Thanks for posting the log.