-
Notifications
You must be signed in to change notification settings - Fork 843
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenBSD installer / instructions #416
Comments
Certainly, that would be great! The main thing we need is access to a On Thu, Jun 25, 2015, 8:07 PM Martijn Rijkeboer notifications@github.com
|
I haven't made it, but here is the bindist that OpenBSD's GHC is using: |
OK, I've pushed commits to both update stack with an OS key for OpenBSD, and add an entry for that bindist to the metadata file. Unfortunately, the LTS Haskell snapshots all require at least GHC 7.8.4, so this won't be compatible. You can use the |
There is a OpenBSD package for GHC 7.8.4, but it is not a bindist, but a full package: |
I've also asked one of the maintainers of OpenBSD's GHC package if it's possible to get a 7.8.4 and |
I will work towards having OpenBSD available on AMD64 so I can better serve testing and such here. ATM, I only have OpenBSD on i386, and GHC is complete broken there. |
I received the following from one of the maintainers of OpenBSD GHC package:
Please don't use the bindists from dead-parrot.de (or from any
It depends on your definition of 'hard' ;-)
It should be possible, at least for 7.8.4, with some knowledge about Note that the version number of the built bootstrapper / bindist To get a full-fledged bindist, you'll have to fiddle with the
lines. I don't know wether just removing them all would work, you'll For ghc-7.10, you'd have to change the lang/ghc port to build 7.10, BTW: if I switch to 7.10 some day, you'll no longer be able to Also be aware that you'll have to build and distribute new bindists Ciao, ps: feel free to quote this mail or parts of it on the gitub issue |
Similarly, Kili was able to provide me with some clarification for GHC OpenBSD i386/AMD64:
|
Due to time constraints I am unfortunately not able to put time into this in the near future. |
With some help from kili I was able to compile the bootstraps for OpenBSD current and 5.8. I'm not sure if this is the way to go but for now it would be nice if the bootstraps linked below could be used for stack. OpenBSD current/AMD64:
OpenBSD 5.8/AMD64:
The server hosting them should have enough bandwidth. |
Very cool @mrijkeboer, would you be able to post a gist or doc somewhere that shows your path thru to success, even rough cut is great because we can try to reproduce and solidify the process. Thanks for pushing on this! |
Nice! Do these bindists install with the standard |
Also, are the |
@mrijkeboer I've tried the
For my own reference, here's what I did starting from a bare OpenBSD installation
|
I was able to get
This is GHC 7.8.4 only (since openbsd-5.8 doesn't seem to have packages or ports for GHC 7.10.2), but demonstrates that it works. The |
I spoke a bit too soon. There seem to be character encoding issues:
This despite setting |
@borsboom do you get the same error when you do something like: |
That does seem to fix it! Is |
Next issue: installing the
|
that looks like a BSD / GNU make issue. there is the |
Hi all, with ghc 8.0.1 and ghc 8.0.2 making a ghc bindist works pretty much out-of-the-box on OpenBSD 6.0 x86_64. I used my build (8.0.1) to compile cabal, stack and the default stack project template without a problem. Karel Gardas, who provides the bindist on the ghc site, uses OpenBSD current to build. So that's why those bindist are not working on 6.0. Anyway, using the ./configure options he gave me, the ghc build on 6.0 just works: pkg_add ghc gmake autoconf automake iconv gmp libffi What's the way forward to unblock this? |
I'm confused? GHC 8.0.1/8.0.2 bindists are documented as targeted for OpenBSD 5.9 (and that was confirmed for GHC 8.0.1 in earlier posts) — is that inaccurate? And IIUC OpenBSD current is later than 6.0 and stuff built there won't work on older releases? https://www.haskell.org/ghc/download_ghc_8_0_1#openbsd_x86_64 Anyway: supporting more variants of a platform is just a matter of listing those correctly in
This is relevant: Of those, we have an LTS based on GHC 8.0.1, and Stack can build with it; it seems integration tests still don't default to that version though. It seems the Vagrantfile mentioned by that comment is still there (based on OpenBSD 6.0). It would be good to update it. Not sure what's needed since I don't take care of releases (IIRC @borsboom does), but I'd guess we need an uploaded bindist (mentioned in https://github.com/fpco/stackage-content/blob/master/stack/stack-setup-2.yaml) and a Vagrantfile to install it and test it. |
After seeing #2822, I investigated myself. TL;DR. Indeed, GHC bindists, or userland programs, in general, aren't necessarily portable from OpenBSD version X to OpenBSD version Y. Sources: Based on https://www.openbsd.org/faq/faq5.html#Flavors and http://comp.unix.bsd.openbsd.misc.narkive.com/ey6FWylS/backward-binary-compatibility#post4 ages ago (yet the second relevant google result for The latter link mentioned static linking as an option. Would that still work? |
@Blaisorblade I'm not sure about GHC itself, but if I statically compile the very simple Haskell program below on OpenBSD-current it won't run on OpenBSD 6.0-stable. On OpenBSD-current:
When I copy the executable to OpenBSD 6.0-stable it get the following:
However if I build the same program on OpenBSD 6.0-stable and copy it to OpenBSD-current it works, although I'm not sure if this is by design or just luck. On OpenBSD 6.0-stable:
On OpenBSD-current:
|
@mrijkeboer Thanks for trying this out! The more interesting direction is building on an older version and trying it out on a new one—the reverse cannot work by design, if Sticking to system GHCs is of course an alternative, especially if ports allow building older GHCs. The main downside is that Stack won't be able to pick the appropriate version, but that could be solved if somebody picked up #2433, which is more generally useful (maybe see also #2546). |
@Blaisorblade It seems that the GHC 8.0.2 is build for OpenBSD-current or at least it works:
|
@Blaisorblade I've asked the OpenBSD mailing list whether static binaries compiled on an older release (X) are expected to run on a newer release (X+1, X+2) [0]. I've received the following - expected - answer from Sebastien Marie [1]:
So it seems that the best way would be to support more variants of the OpenBSD platform like you suggested above. Fortunately OpenBSD only maintains three releases at a time:
As Juan Francisco Cantero Hurtado [2] pointed out, Go on OpenBSD has the same problem: golang/go#15227 [0] http://marc.info/?l=openbsd-misc&m=148793092509010&w=2 |
Just a note to help others While the best solution is worked out, OpenBSD users can continue to use stack, even without using only the system install ghc. if you build a binary-dist and then specify it in your config.yaml, you can then use stack setup to installed it. This is how i do it.
Then I run the following script
copy the resulting bindist to your development machine and include the following in your .stack/config.yaml file
Note: with W^X now mandatory in OpenBSD back in may, I know its not the safest but i run my /home, /usr/local and /tmp marked as wxallowed. I hope this helps other users out there! |
Thanks @adamsteen, In either case, I'm still having trouble getting ghc-8.0 to compile on OpenBSD 6.0. Here's the config and error I keep receiving after trying
also, I've been trying to build the latest master, but each time I get some different error, but maybe I should expect that from the latest. Here's the config and error message I receive when trying to build the latest master as of April 9, 2017:
If anyone has seen these errors before and can point me in the right direction that would be very much appreciated. |
Sorry i am only learning about the innards of GHC myself, i haven't see those errors. (Also i run Current) if might be better posting to ghc-devs mailing list, they have been helpful to me in the past, I don't think this is the best spot. also see Preparing and Building OpenBSD Lastly, did you install Happy and Alex from ports or via cabal, i have always installed them via ports. |
First, building GHC can be hard in general, also on Linux, even if you know
the Makefile language, and even if you read all docs on the GHC wiki. I
don't want to discourage you, but please read those docs. There are enough
bugs to workaround.
This sort of error
Panic! libraries/Cabal/Cabal/dist-install/build/Distribution/Simple/Setup.hi
exists, but libraries/Cabal/Cabal/dist-install/build/Distribution/Simple/Setup.dyn_o
does not.
is often produced by pressing Ctrl-C after starting a build, so that only
some of the output from one input are saved (here, the .hi, but not
.dyn_o). This is a GHC bug and also happens during builds with stack or
cabal. It happens to be often enough.
As a workaround, remove the output which is there.
If you get that on a clean build (seems unlikely here): maybe the dyn_o
file is just not being created. That's output for dynamic linking, but
maybe it doesn't work on OpenBSD. Maybe the build.mk is not set correctly.
The second error is weirder. If you get it on a clean build, check
permissions of the file where the build is failing.
--
Paolo Giarrusso
From smartphone, sorry for typos or excessive brevity
Il 10 apr 2017 03:30, "Sean Westfall" <notifications@github.com> ha scritto:
Thanks @adamsteen <https://github.com/adamsteen>,
A little more on OpenBSD's new wxallowed attribute
<https://www.openbsd.org/faq/upgrade60.html>. You can either set it by
editing the /etc/fstab like so:
01020304050607.h /usr/local ffs rw,nodev,wxallowed 1 2 and rebooting, or
you can temporary set a mount as wxallowed by running this command: mount
-uo wxallowed /usr/local. (where /usr/local is the partition you'd like to
affected, run mount to see them all)
In either case, I'm still having trouble getting ghc-8.0 to compile on
OpenBSD 6.0. Here's the config and error I keep receiving after trying gmake
:
Configure completed successfully.
Building GHC version : 8.0.2.20170314
Git commit id : d2d13a4f6750e30389552974bd7465712d522735
Build platform : x86_64-unknown-openbsd
Host platform : x86_64-unknown-openbsd
Target platform : x86_64-unknown-openbsd
Bootstrapping using : /usr/local/bin/ghc
which is version : 7.10.3
Using gcc : /usr/bin/gcc
which is version : 4.2.1
Building a cross compiler : NO
hs-cpp : /usr/bin/gcc
hs-cpp-flags : -E -undef -traditional
ld : /usr/bin/ld
nm : /usr/bin/nm
objdump : /usr/bin/objdump
Happy : /home/goldfish/.cabal/bin/happy (1.19.5)
Alex : /home/goldfish/.cabal/bin/alex (3.2.1)
Perl : /usr/bin/perl
sphinx-build :
xelatex :
Using LLVM tools
llc :
opt :
HsColour was not found; documentation will not contain source links
Tools to build Sphinx HTML documentation available: NO
Tools to build Sphinx PDF documentation available: NO
----------------------------------------------------------------------
For a standard build of GHC (fully optimised with profiling), type (g)make.
To make changes to the default build configuration, copy the file
mk/build.mk.sample to mk/build.mk, and edit the settings in there.
For more information on how to configure your GHC build, see
http://ghc.haskell.org/trac/ghc/wiki/Building
$ gmake
===--- building phase 0
gmake --no-print-directory -f ghc.mk phase=0 phase_0_builds
gmake[1]: Nothing to be done for 'phase_0_builds'.
===--- building phase 1
gmake --no-print-directory -f ghc.mk phase=1 phase_1_builds
gmake[1]: Nothing to be done for 'phase_1_builds'.
===--- building final phase
gmake --no-print-directory -f ghc.mk phase=final all
Panic! libraries/Cabal/Cabal/dist-install/build/Distribution/Simple/Setup.hi
exists, but libraries/Cabal/Cabal/dist-install/build/Distribution/Simple/Setup.dyn_o
does not.
gmake[1]: *** [libraries/Cabal/Cabal/ghc.mk:4:
libraries/Cabal/Cabal/dist-install/build/Distribution/Simple/Setup.dyn_o]
Error 1
gmake: *** [Makefile:134: all] Error 2
also, I've been trying to build the latest master, but each time I get some
different error, but maybe I should expect that from the latest. Here's the
config and error message I receive when trying to build the latest master
as of April 9, 2017:
Configure completed successfully.
Building GHC version : 8.3.20170409
Git commit id : 87377f74eec1567af741737b4b9034d06e3f0698
Build platform : x86_64-unknown-openbsd
Host platform : x86_64-unknown-openbsd
Target platform : x86_64-unknown-openbsd
Bootstrapping using : /usr/local/bin/ghc
which is version : 7.10.3
Using (for bootstrapping) : /usr/bin/gcc
Using gcc : gcc
which is version : 4.2.1
Building a cross compiler : NO
Unregisterised : NO
hs-cpp : gcc
hs-cpp-flags : -E -undef -traditional
ld : /usr/bin/ld
nm : /usr/bin/nm
objdump : /usr/bin/objdump
Happy : /home/goldfish/.cabal/bin/happy (1.19.5)
Alex : /home/goldfish/.cabal/bin/alex (3.2.1)
Perl : /usr/bin/perl
sphinx-build :
xelatex :
Using LLVM tools
llc :
opt :
HsColour was not found; documentation will not contain source links
Tools to build Sphinx HTML documentation available: NO
Tools to build Sphinx PDF documentation available: NO
----------------------------------------------------------------------
For a standard build of GHC (fully optimised with profiling), type (g)make.
To make changes to the default build configuration, copy the file
mk/build.mk.sample to mk/build.mk, and edit the settings in there.
For more information on how to configure your GHC build, see
http://ghc.haskell.org/trac/ghc/wiki/Building
$ gmake
===--- building phase 0
gmake --no-print-directory -f ghc.mk phase=0 phase_0_builds
gmake[1]: Nothing to be done for 'phase_0_builds'.
===--- building phase 1
gmake --no-print-directory -f ghc.mk phase=1 phase_1_builds
gcc -E -undef -traditional -P
-DTOP='"/home/goldfish/yesod_test/ghc_compile_test/ghc"'
-DFFI_INCLUDE_DIR=/usr/local/include -DFFI_LIB_DIR=/usr/local/lib
'-DFFI_LIB=' -x c -Iincludes -Iincludes/dist
-Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header rts/package.conf.in -o
rts/dist/package.conf.inplace.raw
grep -v '^#pragma GCC' rts/dist/package.conf.inplace.raw | sed -e
's/""//g' -e 's/:[ ]*,/: /g' > rts/dist/package.conf.inplace
"inplace/bin/ghc-pkg" update --force rts/dist/package.conf.inplace
ghc-pkg: Couldn't open database
/home/goldfish/yesod_test/ghc_compile_test/ghc/inplace/lib/package.conf.d
for modification:
/home/goldfish/yesod_test/ghc_compile_test/ghc/inplace/lib/package.conf.d/package.cache:
GHC.PackageDb.readPackageDb: inappropriate type (Not a valid Unicode
code point!)
gmake[1]: *** [rts/ghc.mk:540: rts/dist/package.conf.inplace] Error 1
gmake[1]: *** Deleting file 'rts/dist/package.conf.inplace'
gmake: *** [Makefile:125: all] Error 2
$
If anyone ha seen these errors before and can point me in the right
direction that would be very much appreciated.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#416 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARsqHFqHruvGho3kc8xvCRjI4ovgqWVks5ruYZSgaJpZM4FL9qe>
.
|
Success guys! 🎉 I let it compile over night, with only one core, just to be on the safe side, and it completed. Though, I did the last step
and I'm not sure what this does actually. When I use
if the compiled completed correctly, shouldn't this return 8.0.2, and not 7.10.3?
|
Not really. Only Anyway, To fix that failure:
|
How feasible is it to support multiple GHC versions in ports? |
I asked this question a few month ago on the ports mailing list. I received the following answer from the OpenBSD GHC maintainer (kili): http://marc.info/?l=openbsd-ports&m=147224433914597&w=2 |
@Blaisorblade Already mentioned this to @adamsteen But the only step I needed to do to finish up was run Though, I guess next steps is now compiling GHC 8.2.0 on OpenBSD 6.1. |
@seanwestfall No: I'm sure uploasing GHC to ports would help GHC users on BSD, but it's not enough for stack official support. |
Right, the real problem here is that we don't (yet) have an easy way to build / host multiple versions of GHC for each OpenBSD release. Any proposals for realistic methods to do so? |
@ketzacoatl I see supporting multiple releases in ports is an organizational problem. But support in port is not too relevant to stack. Both Stack (and I think GHC headquarters) could host community-supported working bindists. Stack setup already supports some (https://github.com/fpco/stackage-content/blame/master/stack/stack-setup-2.yaml)—apparently, the ones from Karel Gardas, hosted by GHC headquarters (https://www.haskell.org/ghc/download_ghc_8_0_1#openbsd_x86_64, https://www.haskell.org/ghc/download_ghc_8_0_2#openbsd_x86_64). |
@seanwestfall I have to agree with Blaisorblade here, i don't install GHC i built, but use stack to do its magic with my version of the bindist! I am happy with this until we can come up with a way for stack to support in natively. I use the same process with 8.2.1. |
@Blaisorblade Okay, yes you're right. For some reason, when I followed the instructions for adding the bindist file to the |
For anybody still interested: we might have all the pieces needed. But I got no time to coordinate testing and integration. We're making progress on #2822 to have Stack select a different GHC bindist on OpenBSD for each major release. The needed Haskell coding might be done, but is untested (master...check-openbsd-release). I also sketched the needed changes to Stack config to find the bindists (commercialhaskell/stackage-content#25) — you can try them out locally via https://docs.haskellstack.org/en/stable/yaml_configuration/#setup-info. As usual, I can't actually build bindists. But hopefully those changes contain all the Stack expertise needed. |
Good work @Blaisorblade. Though what about what's listed on the ports pages? e.g. https://mirrors.sonic.net/pub/OpenBSD/6.1/packages/amd64/ghc-7.10.3p7.tgz, https://mirrors.sonic.net/pub/OpenBSD/6.0/packages/amd64/ghc-7.10.3p4.tgz |
Stack supports usual system-installed GHCs, but it can't manage those. IIUC, those users are already supported—they just need to setup https://docs.haskellstack.org/en/stable/yaml_configuration/#system-ghc to true, like on all other platforms.
In case you wonder: those archives can't be used as bindists, because their contents are different (for instance, no |
Interestingly, the 8.2.1 release notes mentions the following
|
Any chance of getting a binary installer for OpenBSD (current, AMD64) or instructions on
how to get it working from source? I develop Haskell on OpenBSD and would like to use
stack.
The text was updated successfully, but these errors were encountered: