Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upElm 0.18 violates W^X both during build and with the `elm` executable #179
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
process-bot
Nov 14, 2016
Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!
Here is what to expect next, and if anyone wants to comment, keep these things in mind.
process-bot
commented
Nov 14, 2016
|
Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it! Here is what to expect next, and if anyone wants to comment, keep these things in mind. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
knowmercy
Nov 14, 2016
This is behaving the same way for me. This is an amd64 box running a snapshot from a couple days ago. I've the following installed:
ghc-7.10.3p7
cabal-install-1.22.6.0
knowmercy
commented
Nov 14, 2016
|
This is behaving the same way for me. This is an amd64 box running a snapshot from a couple days ago. I've the following installed: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
evancz
Nov 14, 2016
Contributor
This sounds like a Haskell thing, not an Elm thing. I have no idea how writing programs in Haskell could break this rule.
It'd be helpful to know (1) which version of GHC and (2) what dependencies it thinks it is using. If any of them are weird, that's probably the problem. I'd also look around the Haskell ecosystem in general to see if anyone is getting this. Maybe there's something in unix-compat that is off.
|
This sounds like a Haskell thing, not an Elm thing. I have no idea how writing programs in Haskell could break this rule. It'd be helpful to know (1) which version of GHC and (2) what dependencies it thinks it is using. If any of them are weird, that's probably the problem. I'd also look around the Haskell ecosystem in general to see if anyone is getting this. Maybe there's something in |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
mulander
Nov 14, 2016
Hi @evancz I'm going to redo a clean 0.17. build of elm on this machine to compare. Will grab both build logs and will add them as soon as both finish for comparison.
We are aware that haskell often introduced W^X violations and we try to handle them in OpenBSD ports but the way Elm is built makes it very hard to properly package hence I'm raising awarness that some recent change violated an out of ports build.
mulander
commented
Nov 14, 2016
|
Hi @evancz I'm going to redo a clean 0.17. build of elm on this machine to compare. Will grab both build logs and will add them as soon as both finish for comparison. We are aware that haskell often introduced W^X violations and we try to handle them in OpenBSD ports but the way Elm is built makes it very hard to properly package hence I'm raising awarness that some recent change violated an out of ports build. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
evancz
Nov 14, 2016
Contributor
I am not sure build logs will help me give guidance here. The two things I asked about will help me more. For example, Elm builds with GHC 7.10, but not later versions. That may be the problem.
Here is a cabal.config that comes from running cabal freeze on my elm-compiler. It lists the exact dependencies I used to successfully build elm-compiler on my machine. Perhaps you are trying to build with newer things.
|
I am not sure build logs will help me give guidance here. The two things I asked about will help me more. For example, Elm builds with GHC 7.10, but not later versions. That may be the problem. Here is a |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
mulander
Nov 14, 2016
The version I'm building with is:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3
$ cabal --version
cabal-install version 1.22.6.0
using version 1.22.5.0 of the Cabal library
I just retried building 0.17 moving my previous build aside. It is now failing to build same way as v0.18 so it must have been a change in the minor ghc bump from 7.10.2 which I used previously for elm 0.17.
I guess you can't do much about that, I incorrectly assumed that perhaps a new dependency/change in v0.18 made the W^X violations worse for Elm but alas it appears no.
I'm closing this issue down, don't think you can do much about it on Elm's side.
mulander
commented
Nov 14, 2016
|
The version I'm building with is:
I just retried building 0.17 moving my previous build aside. It is now failing to build same way as v0.18 so it must have been a change in the minor ghc bump from 7.10.2 which I used previously for elm 0.17. I guess you can't do much about that, I incorrectly assumed that perhaps a new dependency/change in v0.18 made the W^X violations worse for Elm but alas it appears no. I'm closing this issue down, don't think you can do much about it on Elm's side. |
mulander
closed this
Nov 14, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
blackgnezdo
Apr 16, 2017
A workaround is to point TMPDIR environment variable at some temporary directory on a filesystem with wxallowed prior to running cabal build. I tested this on OpenBSD 6.1 amd64.
blackgnezdo
commented
Apr 16, 2017
|
A workaround is to point TMPDIR environment variable at some temporary directory on a filesystem with wxallowed prior to running |
mulander commentedNov 14, 2016
•
edited
Edited 1 time
-
mulander
edited Nov 14, 2016 (most recent)
Hi,
I was successfully using Elm 0.17 on OpenBSD -current. The only issue was
elm-replviolating W^X but the rest of the language worked fine.Version 0.18 on the other hand fails to build with W^X violations during build and the
elmbinary (the only one produced from the build) violating it also.W^X violation from
dmesg:Sample build errors: