Passing -no-pie to the linker breaks inline-java.

[facundominguez]

Describe the bug

Passing -no-pie to the linker as in #1388 breaks inline-java builds on nix with NixOS/nixpkgs@5d4d7c24.

To Reproduce

Clone tweag/inline-java@471fdcb and edit the WORKSPACE file to have rules_haskell point at #1388. Then run nix-shell --pure --run "bazel build //..." An error like the following will appear:

BUILD.bazel:130:22: HaskellCabalLibrary @stackage//:base-orphans failed (Exit 1) cabal_wrapper fai
led: error executing command bazel-out/host/bin/external/rules_haskell/haskell/cabal_wrapper lib:base-orphans base-orphans-0.8.2 true external/stackage/base-orphans-0.8.2/Setup.hs external/stackag
e/base-orphans-0.8.2 ... (remaining 8 argument(s) skipped)Use --sandbox_debug to see verbose messages from the sandbox
/nix/store/ydk00ssq4fyx78rpmdmq1hcmz0iw575f-binutils-2.31.1/bin/ld: /nix/store/bqbg6hb2jsl3kvf6jgm
gfdqy06fpjrrn-glibc-2.30/lib/crt1.o: in function `_start':/build/glibc-2.30/csu/../sysdeps/x86_64/start.S:104:0: error:
     undefined reference to `main'
/nix/store/ydk00ssq4fyx78rpmdmq1hcmz0iw575f-binutils-2.31.1/bin/ld: /nix/store/mq4wqd24pqhppda7vkp
wbl0rpf8c446b-ghc-8.10.1/lib/ghc-8.10.1/base-4.14.0.0/libHSbase-4.14.0.0-ghc8.10.1.so: undefined r
eference to `stg_writeTVarzh'
/nix/store/ydk00ssq4fyx78rpmdmq1hcmz0iw575f-binutils-2.31.1/bin/ld: /nix/store/mq4wqd24pqhppda7vkp
wbl0rpf8c446b-ghc-8.10.1/lib/ghc-8.10.1/base-4.14.0.0/libHSbase-4.14.0.0-ghc8.10.1.so: undefined r
eference to `reportStackOverflow'
/nix/store/ydk00ssq4fyx78rpmdmq1hcmz0iw575f-binutils-2.31.1/bin/ld: /nix/store/mq4wqd24pqhppda7vkp
wbl0rpf8c446b-ghc-8.10.1/lib/ghc-8.10.1/base-4.14.0.0/libHSbase-4.14.0.0-ghc8.10.1.so: undefined r
eference to `performMajorGC'

I tried this in centos7, but I think the OS is not affecting the choice of compilers.

We need a solution for ghc, so it works correctly with the gcc that bazel provides. If it turns out that ghc needs to be patched, we will also need a solution to workaround the problem until the ghc fix is released.

[robinbb]

@aherrmann @facundominguez What do you think of making a release which does not correct this issue but which documents it? This is in order to unblock the release.

[facundominguez]

inline-java won't work with that release, but perhaps the cases that need the current behavior are worth the effort. I couldn't tell.

[robinbb]

@facundominguez Can we use an older commit of rules_haskell in inline-java as a workaround? (Is the commit for rules_haskell already pinned, there?)

[facundominguez]

It is pinned, indeed.

[robinbb]

It is pinned, indeed.

That's great. So, we could release a new rules_haskell without actually breaking inline-java (in which the Bazel support is actually experimental ATM anway), right? If so, perhaps we should release with a warning, as you suggested @aherrmann .

If you folks (who are closer to this problem than I am) agree that we should release with the warning, I can prepare the documentation change that includes a warning, if you like, and do the release.

[aherrmann]

If so, perhaps we should release with a warning, as you suggested @aherrmann .

To clarify, I mean a note in the release notes. We could also add a section to the README's troubleshooting section. Users can either stick to a commit prior to #1388 or add a patch that removes the -optl-no-pie flags added in that PR if they require some other later feature.

For additional context on the issue, see the note added by #1388.

The release process is documented in MAINTAINERS.md.

---

Regarding this issue, I tried out an autodetection mechanism implemented in Bazel that checks whether the cc from the active cc toolchain supports -no-pie. However, that doesn't resolve the inline-java issue, i.e. passing -no-pie causes the build to fail even if cc supports the flag. My understanding from looking at the GHC sources was that GHC passes -no-pie when it is supported by gcc. So, I wonder if we're missing an additional condition.

[mboes]

The version of inline-java @facundominguez points to in the description uses GHC 8.10.1. So like #1413 and #1327, the issue isn't inline-java specific - it's that #1388 broke support for building Cabal packages with GHC 8.10.

[mboes]

@facundominguez this should be fixed by #1424. Can you confirm?

[facundominguez]

Works for me. I just updated master in inline-java.

[aherrmann]

Closing as this seems to be fixed thanks to #1424.