runQ causes build error "cannot find object file X.dyn_o while linking an interpreted expression", but only for certain stack-yaml

[tsoernes]

I am submitting a...

• bug report
• feature request
• support request => you might also like to ask your question on the mailing list or gitter chat.

Description

Error on stack build when using runQ, but not with runN.

Expected behaviour

No build errors when using runQ.

Current behaviour

cannot find object file ‘.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1/build/dca-exe/dca-exe-tmp/Gridneighs.dyn_o’ while linking an interpreted expression.
Note that the file in question does not contain any runQ statements, rather it is an import of the
only file that contains a runQ statements, which is this: https://github.com/tsoernes/haskelldca/blob/acfe3131334d6fa9ef5d6e39b4809374201c81b9/src/Gridconsts.hs#L15

When using a 'debug-build' stack-yaml (https://github.com/tsoernes/haskelldca/blob/acfe3131334d6fa9ef5d6e39b4809374201c81b9/stack.yaml) the error does happen.

When using a 'release-build' (https://github.com/tsoernes/haskelldca/blob/acfe3131334d6fa9ef5d6e39b4809374201c81b9/stack-release.yaml) the error does NOT happen.

Note two stack-yaml files uses different .stack-work directories.
Have tried stack clean. Have tried to run an Acc program with the flags -fforce-recomp -fflush-cache in case that would dump any temp files associated with building.

I can try to delete the .stack-work or change either of the yaml-files, but keeping in mind that my laptop takes about half an hour or more compiling Accelerate alone, I cannot perform a binary search on the possible build-flag differences.

Steps to reproduce (for bugs)

1. Clone
   git clone https://github.com/tsoernes/haskelldca/tree/acfe3131334d6fa9ef5d6e39b4809374201c81b9
   2a. Build without optimizations, this is where the linking error is supposed to happen:
   stack build
   2b. Build with optimizations, should happen without error:
   stack build --stack-yaml stack-release.yaml

Your environment

• Version used:
• accelerate-1.2.0.0
• accelerate-llvm-1.2.0.0
• accelerate-llvm-native-1.2.0.0
• accelerate-blas-0.2.0.0
• llvm-hs-6.0.0
• llvm-hs-pure-6.0.0
• Backend(s) used and version:
• GHC version: 8.4.3
• Operating system and version: Fedora 28
• Link to your project: https://github.com/tsoernes/haskelldca/tree/acfe3131334d6fa9ef5d6e39b4809374201c81b9

[tmcdonell]

This is very strange, I wonder if this is because profiling is turned on in the debug build? (I don't often build with profiling, so it is the only thing I can think off off hand --- we've had other problems related to profiling builds in the past as well, though I doubt those were specific to this project).

By the way, you can speed the compilation of accelerate a little bit with:

flags:
  accelerate:
    nofib: false

That flag is only required to run the backend test suites. This code seems to provoke some particularly bad behaviour with GHC, however, and takes a long time to compile (see GHC#15488, GHC#15751).

[tsoernes]

Should I try to delete .stack-work? I recompiled all the accelerate+llvm packages today (same flags) for the debug build, but still get the same result.