Dear cafe, I am baffled to learn that stack does not provide builds as reproducible as advertised. I have a project that depends on pandoc. It builds fine on my Debian 9 machine. Then I check out the project on a Debian 8 machine. Downloading and building pandoc-2.7.3 with the latest stack-2.1.3 on the Debian 8 machine runs fine. Now I create a new project, using the same stack.yaml as in the pandoc-2.7.3 package, except now pandoc-2.7.3 is an extra-dep. The project's only module contains nothing but: module Test where import Text.Pandoc Building this project with the same stack results in a linker error: pandoc > Preprocessing executable 'pandoc' for pandoc-2.7.3.. pandoc > Building executable 'pandoc' for pandoc-2.7.3.. pandoc > [1 of 2] Compiling Main pandoc > [2 of 2] Compiling Paths_pandoc pandoc > Linking .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/pandoc/pandoc ... pandoc > collect2: error: ld returned 1 exit status pandoc > `gcc' failed in phase `Linker'. (Exit code: 1) This seems to be independent of the LTS version (the stack.yaml in pandoc-2.7.3 says lts-13.17 although lts-13.17 contains pandoc-2.5 and pandoc-2.7.3 is available only in 14.9). Can somebody hint what I am doing wrong? Should I file a bug report? Thanks Olaf
On 2019-10-16 7:57 a.m., Olaf Klinke wrote:
pandoc > collect2: error: ld returned 1 exit status pandoc > `gcc' failed in phase `Linker'. (Exit code: 1)
Building with Stack still has to use some system libraries, and I assume a difference between Debian 8 and Debian 9 is tripping this up. Can you get more info about what the linker error is? You should be able to see more in the log files.
On 16/10/2019 16:22, Neil Mayhew wrote:
On 2019-10-16 7:57 a.m., Olaf Klinke wrote:
pandoc > collect2: error: ld returned 1 exit status pandoc > `gcc' failed in phase `Linker'. (Exit code: 1)
[...] Can you get more info about what the linker error is?
Indeed, the linker exiting with status 1 without any stderr message sounds like your linker is crashing. Consider `stack build --cabal-verbose`, and if that doesn't provide the necessary level of detail yet, take the last `ghc` invocation it makes, run that directly and add `-v` to that to get GHC's verbose output, which will show you the full linker invocation (which you may then, again, run directly, thus drilling down to the tool that exits with an error unexpectedly). Alternatively, you may use `strace -fy` on the top-level to get a full understanding of all IO that any process involved does, but it will be verbose.
On Thu, 2019-10-17 at 01:41 +0200, Niklas Hambüchen wrote:
On 16/10/2019 16:22, Neil Mayhew wrote:
On 2019-10-16 7:57 a.m., Olaf Klinke wrote:
pandoc > collect2: error: ld returned 1 exit status pandoc > `gcc' failed in phase `Linker'. (Exit code: 1)
[...] Can you get more info about what the linker error is?
Indeed, the linker exiting with status 1 without any stderr message sounds like your linker is crashing.
Consider `stack build --cabal-verbose`, and if that doesn't provide the necessary level of detail yet, take the last `ghc` invocation it makes, run that directly and add `-v` to that to get GHC's verbose output, which will show you the full linker invocation (which you may then, again, run directly, thus drilling down to the tool that exits with an error unexpectedly).
Alternatively, you may use `strace -fy` on the top-level to get a full understanding of all IO that any process involved does, but it will be verbose.
I just updated the resolver in my stack.yaml from lts-12.26 to lts- 13.11 and suddenly pandoc broke again, on the very same machine that happily builds pandoc when using lts-12.26. While fiddling with the various ways of keep-tmp-files as suggested above, ghc and stack filled my disk, so I went and cleaned some cache. And suddenly the build worked! Could it be that the linker error, too, is simply due to lack of disk space? The machine I first encountered the error on has an SSD of only 20GB with 2GB for /tmp. I had to temporarily re-locate /tmp to another partition to get ghc installed at all. Occasionally stack build --cabal-verbose gave me explicit errors about no space left on device, only the linker error does not mention it. That said, the stack FAQ [1] mentions changing the temporary directory but then says nothing about the build dir on non-NIX systems. Doesanyone know more? Olaf [1] https://docs.haskellstack.org/en/stable/faq/#can-i-change-stacks-default-tem...
participants (3)
-
Neil Mayhew -
Niklas Hambüchen -
Olaf Klinke