Closed facundominguez closed 4 years ago
@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.
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.
@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?)
It is pinned, indeed.
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.
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.
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.
@facundominguez this should be fixed by #1424. Can you confirm?
Works for me. I just updated master in inline-java
.
Closing as this seems to be fixed thanks to #1424.
Describe the bug
Passing
-no-pie
to the linker as in #1388 breaksinline-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 runnix-shell --pure --run "bazel build //..."
An error like the following will appear: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 thegcc
that bazel provides. If it turns out that ghc needs to be patched, we will also need a solution to workaround the problem until theghc
fix is released.