Skip to content
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

Closed
mrijkeboer opened this issue Jun 25, 2015 · 80 comments · Fixed by #3184
Closed

OpenBSD installer / instructions #416

mrijkeboer opened this issue Jun 25, 2015 · 80 comments · Fixed by #3184
Labels
Milestone

Comments

@mrijkeboer
Copy link

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.

@snoyberg
Copy link
Contributor

Certainly, that would be great! The main thing we need is access to a
bindist. I'm on my phone right now, so can't point to the relevant files,
but we then just have some minor metadata files and lookups to update. If
you can take care of the hard part of making the bindist, I can point out
the rest.

On Thu, Jun 25, 2015, 8:07 PM Martijn Rijkeboer notifications@github.com
wrote:

Any chance of getting a binary installer for OpenBSD (current, AMD64) or
instructions on
how to get it working? I develop Haskell on OpenBSD and would like to use
stack.


Reply to this email directly or view it on GitHub
#416.

@mrijkeboer
Copy link
Author

I haven't made it, but here is the bindist that OpenBSD's GHC is using:

snoyberg added a commit to commercialhaskell/stackage-content that referenced this issue Jun 26, 2015
snoyberg added a commit that referenced this issue Jun 26, 2015
@snoyberg
Copy link
Contributor

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 resolver: ghc-7.8 to test in the meanwhile. Any possibility of a 7.10 release?

@snoyberg snoyberg added this to the 0.2.0.0 milestone Jun 26, 2015
@mrijkeboer
Copy link
Author

There is a OpenBSD package for GHC 7.8.4, but it is not a bindist, but a full package:

@mrijkeboer
Copy link
Author

I've also asked one of the maintainers of OpenBSD's GHC package if it's possible to get a 7.8.4 and
or 7.10 bindist.

@ketzacoatl
Copy link
Contributor

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.

@mrijkeboer
Copy link
Author

I received the following from one of the maintainers of OpenBSD GHC package:

I'm trying to make FPComplete's Haskell tool Stack work on OpenBSD [1]. For
this a bindist is needed. I have found the bindist for GHC 7.8.3 on
dead-parrot.de but for compatibility with LTS Haskell a bindist for 7.8.4
and preferable 7.10 is needed.

Please don't use the bindists from dead-parrot.de (or from any
OpenBSD mirrors holding distfiles for ports), they're trimmed down
to the absolute minimum required to build the lang/ghc port on
OpenBSD, and they may disappear when they aren't of use for the
ports tree any longer (for example, not required for the last two
or three stable releases of OpenBSD, nor for current).

Is it hard to create bindist's for 7.8.4 and 7.10

It depends on your definition of 'hard' ;-)

and can I do this myself?

It should be possible, at least for 7.8.4, with some knowledge about
ports(7) and make(1). Grab a recent OpenBSD ports tree and look at
/usr/ports/lang/ghc. There's a bootstrap target in the Makefile
that builds the trimmed down bindists I use to bootstrap the real
ghc package.

Note that the version number of the built bootstrapper / bindist
is defined in the make variable MODGHC_VER in ghc.port.mk. When
building new bootstrappers / bindists like some days ago, I set
this to the previos ghc release, because for whatever reason,
building the ghc port using a bootstrapper with the same version
just fails. But for your case, this shouldn't matter (you don't
want to build the port but just the bootstrapper / bindist).

To get a full-fledged bindist, you'll have to fiddle with the
bootstrap target of the ports Makefile, especially with all those

    echo .... >> ${WRKSRC}/mk/build.mk

lines. I don't know wether just removing them all would work, you'll
have to experiment a little bit here (and read the ghc build
documentation).

For ghc-7.10, you'd have to change the lang/ghc port to build 7.10,
which may be easy or not (I didn't work on this yet, because I'm
still unsure wether to keep everything close to haskell-platform
or not).

BTW: if I switch to 7.10 some day, you'll no longer be able to
use the (then 7.10) port for building a 7.8 bindist, so it may be
a good idea to keep a diff and all the files created during make
patch for 7.8 now.

Also be aware that you'll have to build and distribute new bindists
whenever OpenBSDs base libraries (or packages like iconv) get major
updates.

Ciao,
Kili

ps: feel free to quote this mail or parts of it on the gitub issue
tracker ;-)

@ketzacoatl
Copy link
Contributor

Similarly, Kili was able to provide me with some clarification for GHC OpenBSD i386/AMD64:

I do not currently have an AMD64 host available, but my tests with GHC on
i386 have failed miserably. My assumption is that AMD64 is functional, but
i386 is not going to get the fixes it would need.. but maybe this is wrong
and both should be working?

ghc on i386 has issues -- the dynamic linker contained in the ghc
runtime system doesn't work on i386, so ghci doesn't work, and
several haskell package which require ghc loading libraries and
objects during compile time (probably required by template haskell)
don't build.

While I do not have strong C (or Haskell.. still learning), I am an avid
OpenBSD user/sysadmin and interested in ensuring GHC (and stack) runs well
on OpenBSD. To that end, I would be interested in helping you to whatever
degree I am able.

No strong C knowledge, so I guess trying to fix the dynamic linker
of ghc (rts/Linker.c) isn't something for you

But if you are comfortable with the OpenBSD ports system, make(1)
and GNU make (which is used to build ghc), and are willing to
wrap your head around ghc's build system, you could try to build
the ghc port with real shared libraries enabled. This could allow
ghci and other parts of ghc to use OpenBSDs native shared loader
for dynamic haskell libraries.

Ciao,
Kili

@snoyberg snoyberg modified the milestones: 0.2.0.0, 0.3.0.0 Jul 2, 2015
@mrijkeboer
Copy link
Author

Due to time constraints I am unfortunately not able to put time into this in the near future.

@snoyberg snoyberg modified the milestones: Later improvements, 0.3.0.0 Sep 6, 2015
@mrijkeboer
Copy link
Author

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.

@ketzacoatl
Copy link
Contributor

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!

@borsboom
Copy link
Contributor

Nice! Do these bindists install with the standard ./configure --prefix=<path> && make install process? If they do, integrating them with Stack should be no problem.

@borsboom
Copy link
Contributor

Also, are the -5.8 bindists not compatible with -current? We do have some support for selecting different bindists depending on OS version (e.g., on Linux for the Centos 6 libgmp4 variants), but supporting a moving target like -current is more problematic. Sadly, I haven't used OpenBSD since the 90s so I'm very out of date...

@borsboom
Copy link
Contributor

borsboom commented Dec 1, 2015

@mrijkeboer I've tried the ghc-7.10.2-openbsd-x86_64-5.8.tar.bz2 bindist using the configure defaults, and run into some trouble:

  • Compiling a simple program doesn't work with default options. E.g.:

    $ cat >>hello.hs
    main = putStrLn "Hello, world"
    $ ghc hello.hs
    [1 of 1] Compiling Main             ( hello.hs, hello.o )
    Linking hello ...
    /usr/bin/ld: /home/manny/.local/ghc-7.10.2.20151026/lib/ghc/rts/libCffi.a(prep_cif.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
    /home/manny/.local/ghc-7.10.2.20151026/lib/ghc/rts/libCffi.a: could not read symbols: Bad value
    collect2: ld returned 1 exit status
    
  • runghc doesn't seem to work. E.g.:

    $ runghc hello.hs
    <command line>: not built for interactive use
    
  • There's no haddock binary included, which means cabal-install's bootstrap.sh doesn't run

  • The version reported by ghc --version is 7.10.2.20151026 rather than 7.10.2

For my own reference, here's what I did starting from a bare OpenBSD installation

AS ROOT:
export PKG_PATH=http://ftp.openbsd.org/pub/OpenBSD/$(uname -r)/packages/$(machine -a)/
pkg_add sudo

AS USER:
echo 'export PKG_PATH=http://ftp.openbsd.org/pub/OpenBSD/$(uname -r)/packages/$(machine -a)/' >>.profile
source .profile
sudo pkg_add curl bzip2 gmake
curl -O https://haskell.sru-systems.com/ghc-7.10.2-openbsd-x86_64-5.8.tar.bz2
tar xjf ghc-7.10.2-openbsd-x86_64-5.8.tar.bz2
pushd ghc-7.10.2.20151026
./configure --prefix=~/.local/ghc-7.10.2.20151026
gmake install
popd
export PATH=/home/manny/.local/ghc-7.10.2.20151026/bin:$PATH
curl -O https://www.haskell.org/cabal/release/cabal-install-1.22.6.0/cabal-install-1.22.6.0.tar.gz
tar xzf cabal-install-1.22.6.0.tar.gz
cd cabal-install-1.22.6.0
./bootstrap.sh
popd

@borsboom
Copy link
Contributor

borsboom commented Dec 1, 2015

I was able to get stack working on OpenBSD using pretty easily:

pkg_add ghc cabal-install
cabal install stack

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 stack installed this way is then able to build itself from source (using stack --stack-yaml=stack-7.8.yaml build to use GHC 7.8), so Stack is pretty usable on OpenBSD already. Of course, it'd be really nice if we could provide Stack bindists for OpenBSD and it could take care of installing its managed GHC version -- that means making GHC bindists that conform to the official ones for Linux, OS X, Windows, etc.

@borsboom
Copy link
Contributor

borsboom commented Dec 1, 2015

I spoke a bit too soon. There seem to be character encoding issues:

transformers-base-0.4.4: build
Progress: 1/82
--  While building package transformers-base-0.4.4 using:
      /home/manny/.stack/setup-exe-cache/setup-Simple-Cabal-1.18.1.5-x86_64-openbsd-ghc-7.8.4 --builddir=.stack-work/dist/x86_64-openbsd/Cabal-1.18.1.5 build --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/manny/stack/.stack-work/logs/transformers-base-0.4.4.log

    Configuring transformers-base-0.4.4...
    Building transformers-base-0.4.4...
    Preprocessing library transformers-base-0.4.4...
    [1 of 1] Compiling Control.Monad.Base ( src/Control/Monad/Base.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.18.1.5/build/Control/Monad/Base.o )
    .stack-work/dist/x86_64-openbsd/Cabal-1.18.1.5/build/src/Control/Monad/Base.dump-hi: commitBuffer: invalid argument (invalid character)

This despite setting export LC_ALL=en_US.UTF-8.

@qbit
Copy link

qbit commented Dec 1, 2015

@borsboom do you get the same error when you do something like: export HS_ENCODING=utf8?

@borsboom
Copy link
Contributor

borsboom commented Dec 1, 2015

That does seem to fix it! Is HS_ENCODING specific to the OpenBSD port? I haven't encountered it before.

@borsboom
Copy link
Contributor

borsboom commented Dec 1, 2015

Next issue: installing the unix package fails (also using cabal-install):

$ cabal install unix-2.7.0.1 --reinstall
Resolving dependencies...
Warning: The following packages are likely to be broken by the reinstalls:
process-1.2.0.0
haskell98-2.0.0.3
ghc-7.8.4
Cabal-1.18.1.5
bin-package-db-0.0.0.0
haskeline-0.7.1.2
directory-1.2.1.0
hpc-0.6.0.1
Continuing even though the plan contains dangerous reinstalls.
Downloading unix-2.7.0.1...
Configuring unix-2.7.0.1...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for an ANSI C-conforming const... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking dirent.h usability... yes
checking dirent.h presence... yes
checking for dirent.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking for string.h... (cached) yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking for sys/stat.h... (cached) yes
checking sys/times.h usability... yes
checking sys/times.h presence... yes
checking for sys/times.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/utsname.h usability... yes
checking sys/utsname.h presence... yes
checking for sys/utsname.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking bsd/libutil.h usability... no
checking bsd/libutil.h presence... no
checking for bsd/libutil.h... no
checking libutil.h usability... no
checking libutil.h presence... no
checking for libutil.h... no
checking pty.h usability... no
checking pty.h presence... no
checking for pty.h... no
checking utmp.h usability... yes
checking utmp.h presence... yes
checking for utmp.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking for unistd.h... (cached) yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking for getgrgid_r... yes
checking for getgrnam_r... yes
checking for getpwnam_r... yes
checking for getpwuid_r... yes
checking for getpwnam... yes
checking for getpwuid... yes
checking for getpwent... yes
checking for getgrent... yes
checking for lchown... yes
checking for setenv... yes
checking for sysconf... yes
checking for unsetenv... yes
checking for clearenv... no
checking for nanosleep... yes
checking for ptsname... yes
checking for setitimer... yes
checking for readdir_r... yes
checking for telldir... yes
checking for seekdir... yes
checking for struct stat.st_atim... yes
checking for struct stat.st_mtim... yes
checking for struct stat.st_ctim... yes
checking for struct stat.st_atimespec... yes
checking for struct stat.st_mtimespec... yes
checking for struct stat.st_ctimespec... yes
checking for struct stat.st_atimensec... yes
checking for struct stat.st_mtimensec... yes
checking for struct stat.st_ctimensec... yes
checking for struct stat.st_atime_n... no
checking for struct stat.st_mtime_n... no
checking for struct stat.st_ctime_n... no
checking for struct stat.st_uatime... no
checking for struct stat.st_umtime... no
checking for struct stat.st_uctime... no
checking for struct passwd.pw_gecos... yes
checking for utimensat... yes
checking for futimens... yes
checking for lutimes... no
checking for futimes... yes
checking for mkstemps... yes
checking for mkdtemp... yes
checking for library containing shm_open... none required
checking for shm_open... yes
checking for shm_unlink... yes
checking value of SIGABRT... 6
checking value of SIGALRM... 14
checking value of SIGBUS... 10
checking value of SIGCHLD... 20
checking value of SIGCONT... 19
checking value of SIGFPE... 8
checking value of SIGHUP... 1
checking value of SIGILL... 4
checking value of SIGINT... 2
checking value of SIGKILL... 9
checking value of SIGPIPE... 13
checking value of SIGQUIT... 3
checking value of SIGSEGV... 11
checking value of SIGSTOP... 17
checking value of SIGTERM... 15
checking value of SIGTSTP... 18
checking value of SIGTTIN... 21
checking value of SIGTTOU... 22
checking value of SIGUSR1... 30
checking value of SIGUSR2... 31
checking value of SIGPOLL... -1
checking value of SIGPROF... 27
checking value of SIGSYS... 12
checking value of SIGTRAP... 5
checking value of SIGURG... 16
checking value of SIGVTALRM... 26
checking value of SIGXCPU... 24
checking value of SIGXFSZ... 25
checking value of SIG_BLOCK... 1
checking value of SIG_SETMASK... 3
checking value of SIG_UNBLOCK... 2
checking for _SC_GETGR_R_SIZE_MAX... yes
checking for _SC_GETPW_R_SIZE_MAX... yes
checking return type of usleep... int
checking return type of unsetenv... int
checking for RTLD_NEXT from dlfcn.h... yes
checking for RTLD_DEFAULT from dlfcn.h... yes
checking for RTLD_LOCAL from dlfcn.h... yes
checking for RTLD_GLOBAL from dlfcn.h... yes
checking for RTLD_NOW from dlfcn.h... yes
checking for openpty... no
checking for openpty in -lutil... yes
checking for /dev/ptmx... no
checking for /dev/ptc... no
checking for dlopen in -ldl... no
checking build system type... x86_64-unknown-openbsd5.8
checking host system type... x86_64-unknown-openbsd5.8
checking target system type... x86_64-unknown-openbsd5.8
checking for library containing sem_close... -lpthread
configure: creating ./config.status
config.status: creating unix.buildinfo
config.status: creating include/HsUnixConfig.h
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
cabal: user error (Bad header file: execvpe.h
The header file contains a compile error. You can re-run configure with the
verbosity flag -v3 to see the error messages from the C compiler.
)
Failed to install unix-2.7.0.1
cabal: user error (Error: some packages failed to install:
unix-2.7.0.1 failed during the configure step. The exception was:
ExitFailure 1
)

@ketzacoatl
Copy link
Contributor

that looks like a BSD / GNU make issue. there is the gmake package, which, ironically, this unix package may need on OpenBSD?

@dhouthoo
Copy link

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
./configure
--with-iconv-libraries=/usr/local/lib
--with-iconv-includes=/usr/local/include
--with-gmp-libraries=/usr/local/lib
--with-gmp-includes=/usr/local/include
--with-ffi-libraries=/usr/local/lib
--with-ffi-includes=/usr/local/include
--with-sytem-libffi
gmake
gmake binary-dist

What's the way forward to unblock this?

@Blaisorblade
Copy link
Collaborator

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.

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?
Finally: would binaries built on earlier releases work on later ones, or viceversa?

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

Anyway: supporting more variants of a platform is just a matter of listing those correctly in
https://github.com/fpco/stackage-content/blob/master/stack/stack-setup-2.yaml (see all the Windows variants there to wit). But keep in mind that by default Stack uses externally maintained bindists (by default, official ones—see
#416 (comment)).

What's the way forward to unblock this?

This is relevant:
#416 (comment)
Maybe @borsboom has news?

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.

@Blaisorblade
Copy link
Collaborator

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.
It seems one would need a different bindist for each supported OpenBSD release.

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 openbsd binary compatibility),, it seems binary compatibility with a release is maintained on the -stable channel.

The latter link mentioned static linking as an option. Would that still work?

@mrijkeboer
Copy link
Author

mrijkeboer commented Feb 1, 2017

@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:

$ sysctl kern.version
kern.version=OpenBSD 6.0-current (GENERIC.MP) #158: Mon Jan 30 19:30:12 MST 2017
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3

$ cat Main.hs                                                                 
main :: IO ()
main = putStrLn "Hello"

$ ghc -optl-static Main.hs
Linking Main ...
/usr/local/lib/ghc/rts/libHSrts.a(RtsFlags.o): In function `copyArg':

rts/RtsFlags.c:1685:0:
     warning: warning: strcpy() is almost always misused, please use strlcpy()
/usr/local/lib/ghc/rts/libHSrts.a(RtsUtils.o): In function `showStgWord64':

rts/RtsUtils.c:204:0:
     warning: warning: sprintf() is often misused, please use snprintf()

$ file Main
Main: ELF 64-bit LSB executable, x86-64, version 1

$ ldd Main
Main:
not a dynamic executable

$ ./Main 
Hello

$ sha256 Main                                                                   
SHA256 (Main) = 7ad681ca78976e5401b548afc768a3d4d1137745ee18ea71b5e6688d36f0a144

When I copy the executable to OpenBSD 6.0-stable it get the following:

$ sysctl kern.version
kern.version=OpenBSD 6.0-stable (GENERIC.MP) #8: Thu Jan  5 19:41:14 CET 2017
    build@dexter.bunix.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

$ sha256 Main                                                                   
SHA256 (Main) = 7ad681ca78976e5401b548afc768a3d4d1137745ee18ea71b5e6688d36f0a144

$ ./Main
./Main[1]: syntax error: `H$IE�L$I�H$C��^Gu^X$?#ff$Pff$P' unexpected

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:

$ sysctl kern.version
kern.version=OpenBSD 6.0-stable (GENERIC.MP) #7: Sat Nov  5 21:29:21 CET 2016
    build@dexter.bunix.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

$ cat Main.hs                                                                 
main :: IO ()
main = putStrLn "Hello"

$ ghc -optl-static Main.hs  
Linking Main ...
/usr/local/lib/ghc/rts/libHSrts.a(RtsFlags.o): In function `copyArg':

rts/RtsFlags.c:1685:0:
     warning: warning: strcpy() is almost always misused, please use strlcpy()
/usr/local/lib/ghc/rts/libHSrts.a(RtsUtils.o): In function `showStgWord64':

rts/RtsUtils.c:204:0:
     warning: warning: sprintf() is often misused, please use snprintf()

$ file Main 
Main: ELF 64-bit LSB executable, x86-64, version 1

$ ldd Main
Main:
not a dynamic executable

$ ./Main                                                                      
Hello

$ sha256 Main 
SHA256 (Main) = afece87c07c79b68737efca66bdde280d84202cec4f33bd34fbc3b6a1431abc9

On OpenBSD-current:

$ sysctl kern.version
kern.version=OpenBSD 6.0-current (GENERIC.MP) #158: Mon Jan 30 19:30:12 MST 2017
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

$ sha256 Main                       
SHA256 (Main) = afece87c07c79b68737efca66bdde280d84202cec4f33bd34fbc3b6a1431abc9

$ ./Main                                                                      
Hello

@Blaisorblade
Copy link
Collaborator

@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 -current adds new syscalls and uses them in libc.
Since I fail to find clear info for this use case, could some OpenBSD user interested ask in the OpenBSD community (or the Haskell OpenBSD community)? I'm not clueful enough on OpenBSD to ask on the OpenBSD mailing list.

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).

@mrijkeboer
Copy link
Author

@Blaisorblade It seems that the GHC 8.0.2 is build for OpenBSD-current or at least it works:

$ sysctl kern.version
kern.version=OpenBSD 6.0-current (GENERIC.MP) #166: Wed Feb  8 19:15:03 MST 2017
    deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

$ stack --version
Version 1.3.2 x86_64 hpack-0.15.0

$ stack new test82
Downloading template "new-template" to create project "test82" in test82/ ...

The following parameters were needed by the template but not provided: category
You can provide them in /home/user/.stack/config.yaml, like this:
templates:
  params:
    category: value
Or you can pass each one as parameters like this:
stack new test82 new-template -p "category:value"

Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- test82/test82.cabal

Selecting the best among 10 snapshots...

Downloaded lts-8.0 build plan.    
Updating package index Hackage (mirrored at https://github.com/commercialhaskell                                                                                Fetching package index ...remote: Counting objects: 3689, done.
remote: Compressing objects: 100% (246/246), done.
remote: Total 3689 (delta 1313), reused 1262 (delta 1262), pack-reused 2175
Receiving objects: 100% (3689/3689), 2.83 MiB | 725.00 KiB/s, done.
Resolving deltas: 100% (1490/1490), completed with 556 local objects.
From https://github.com/commercialhaskell/all-cabal-hashes
   79f894d3f9..53fcf98366  hackage         -> origin/hackage
 t [tag update]            current-hackage -> current-hackage
Fetched package index.    
Populated index cache.    
* Matches lts-8.0

Selected resolver: lts-8.0
Initialising configuration using resolver: lts-8.0
Total number of user packages considered: 1
Writing configuration to file: test82/stack.yaml
All done.

$ cd test82/

$ stack setup
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Downloaded ghc-8.0.2.                                     
Unpacking GHC into /home/user/.stack/programs/x86_64-openbsd/ghc-8.0.2.temp/                                                                                 Installed GHC.     
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec

$ stack build
Warning: File listed in test82.cabal file does not exist: README.md
[1 of 2] Compiling Main             ( /home/user/.stack/setup-exe-src/setup-mPHDZzAJ.hs, /home/user/.stack/setup-exe-src/setup-mPHDZzAJ.o )
[2 of 2] Compiling StackSetupShim   ( /home/user/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /home/user/.stack/setup-exe-src/setup-shim-mPHDZzAJ.o )
Linking /home/user/.stack/setup-exe-cache/x86_64-openbsd/tmp-Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 ...
/home/user/.stack/programs/x86_64-openbsd/ghc-8.0.2/lib/ghc-8.0.2/base-4.9.1.0/libHSbase-4.9.1.0.a(IO__1.o): In function `ghczuwrapperZC0ZCbaseZCSystemziIOZCrand':
(.text+0x1): warning: warning: rand() may return deterministic values, is that what you want?
/home/user/.stack/programs/x86_64-openbsd/ghc-8.0.2/lib/ghc-8.0.2/rts/libHSrts_thr.a(RtsFlags.thr_o): In function `copyArg':

rts/RtsFlags.c:1805:0: error:
     warning: warning: strcpy() is almost always misused, please use strlcpy()
/usr/local/lib/libgmp.so.10.0: warning: warning: vsprintf() is often misused, please use vsnprintf()
/home/user/.stack/programs/x86_64-openbsd/ghc-8.0.2/lib/ghc-8.0.2/rts/libHSrts_thr.a(RtsUtils.thr_o): In function `showStgWord64':

rts/RtsUtils.c:230:0: error:
     warning: warning: sprintf() is often misused, please use snprintf()
test82-0.1.0.0: configure (lib + exe)
Configuring test82-0.1.0.0...
test82-0.1.0.0: build (lib + exe)
Preprocessing library test82-0.1.0.0...
[1 of 1] Compiling Lib              ( src/Lib.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.24.2.0/build/Lib.o )
Preprocessing executable 'test82-exe' for test82-0.1.0.0...
[1 of 1] Compiling Main             ( app/Main.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.24.2.0/build/test82-exe/test82-exe-tmp/Main.o )
Linking .stack-work/dist/x86_64-openbsd/Cabal-1.24.2.0/build/test82-exe/test82-exe ...
/home/user/.stack/programs/x86_64-openbsd/ghc-8.0.2/lib/ghc-8.0.2/rts/libHSrts_thr.a(RtsFlags.thr_o): In function `copyArg':

rts/RtsFlags.c:1805:0: error:
     warning: warning: strcpy() is almost always misused, please use strlcpy()
/usr/local/lib/libgmp.so.10.0: warning: warning: vsprintf() is often misused, please use vsnprintf()
/home/user/.stack/programs/x86_64-openbsd/ghc-8.0.2/lib/ghc-8.0.2/rts/libHSrts_thr.a(RtsUtils.thr_o): In function `showStgWord64':

rts/RtsUtils.c:230:0: error:
     warning: warning: sprintf() is often misused, please use snprintf()
Warning: File listed in test82.cabal file does not exist: README.md
test82-0.1.0.0: copy/register
Installing library in
/home/user/Scratch/test82/.stack-work/install/x86_64-openbsd/lts-8.0/8.0.2/lib/x86_64-openbsd-ghc-8.0.2/test82-0.1.0.0-EVLQkMVlEaDLN2y26yqY67
Installing executable(s) in
/home/user/Scratch/test82/.stack-work/install/x86_64-openbsd/lts-8.0/8.0.2/bin
Registering test82-0.1.0.0...

$ stack exec test82-exe
someFunc

@mrijkeboer
Copy link
Author

@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]:

The generic answer will be "no".

The example is the switch from 5.4 to 5.5 release which included time_t
change (32 to 64 bits) - see https://www.openbsd.org/faq/upgrade55.html#time_t

But generally, an old binary (from release X) is able to run on a new
kernel (from release X+1), but nothing more could be expected: old
things are cleaned, so an old binary could be able to run or not (it
just depends if relying on old API/ABI with kernel - syscalls, struct
size...).

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:

  • Current development version (-current).
  • Latest release (at the time of this writing: 6.0).
  • Previous release (at the time of this writing: 5.9).

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
[1] http://marc.info/?l=openbsd-misc&m=148793453010027&w=2
[2] http://marc.info/?l=openbsd-misc&m=148794264012274&w=2

@adamsteen
Copy link

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.
On a fresh install of OpenBSD Current.
Prerequisite:

  1. /home is marked as wxallowed in /etc/fstab
  2. the datasize-cur for staff in etc/login.conf is set to 4096M (it could be lower but i haven't bothered to find out)
  3. and /etc/doas.conf has a line similar to "permit nopass setenv { PKG_CACHE PKG_PATH } adamsteen cmd pkg_add" (where adamsteen is your username)

Then I run the following script

#!/bin/sh
rm -rf $HOME/tmp && \
rm -rf $HOME/bin && \
rm -rf $HOME/ghc && \
mkdir tmp && \
mkdir bin && \
export PKG_PATH=http://mirror.internode.on.net/pub/OpenBSD/snapshots/packages/amd64/ && \
doas pkg_add ghc gmake 'autoconf-2.69p2' 'automake-1.15p0' gmp alex happy git xz gtar-- && \
ln -sf /usr/local/bin/python2.7 $HOME/bin/python && \
ln -sf /usr/local/bin/python2.7-2to3 $HOME/bin/2to3 && \
ln -sf /usr/local/bin/python2.7-config $HOME/bin/python-config && \
ln -sf /usr/local/bin/pydoc2.7 $HOME/bin/pydoc && \
export AUTOCONF_VERSION=2.69 && \
export AUTOMAKE_VERSION=1.15 && \
export TMP=$HOME/tmp && \
export TEMP=$HOME/tmp && \
git clone --recursive git://git.haskell.org/ghc.git && \
cd ghc && \
git checkout ghc-8.0 && \
git submodule update --init && \
./boot && \
./configure --with-iconv-libraries=/usr/local/lib --with-iconv-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-ffi-libraries=/usr/local/lib --with-ffi-includes=/usr/local/include --with-system-libffi && \
gmake -j4 && \
gmake binary-dist && \
cd .. && \
mv ghc/ghc-* .

copy the resulting bindist to your development machine and include the following in your .stack/config.yaml file

setup-info:
  ghc:
    openbsd64:
      8.0.2.20170314:
        url: '/home/adamsteen/devl/ghc-bindist/ghc-8.0.2.20170314-x86_64-unknown-openbsd.tar.xz'

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!

@seanwestfall
Copy link

seanwestfall commented Apr 10, 2017

Thanks @adamsteen,
A little more on OpenBSD's new wxallowed attribute. 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 has seen these errors before and can point me in the right direction that would be very much appreciated.

@adamsteen
Copy link

@seanwestfall

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.

@Blaisorblade
Copy link
Collaborator

Blaisorblade commented Apr 10, 2017 via email

@seanwestfall
Copy link

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

$ cat /home/goldfish/.stack/config.yaml
templates:
  params: null
system-ghc: true
setup-info:
  ghc:
    openbsd64:
      8.0.2.20170314:
        url: '/home/goldfish/ghc-8.0.2.20170314-x86_64-unknown-openbsd.tar.xz'

and I'm not sure what this does actually. When I use stack setup I get this error:

$ stack setup
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Did not find executable at specified path: /home/goldfish/.stack/programs/x86_64-openbsd/ghc-8.0.2.20170314.temp/ghc-8.0.2.20170314/configure

Error: Error encountered while configuring GHC with
         /home/goldfish/.stack/programs/x86_64-openbsd/ghc-8.0.2.20170314.temp/ghc-8.0.2.20170314/configure --prefix=/home/goldfish/.stack/programs/x86_64-openbsd/ghc-8.0.2.20170314/
         run in /home/goldfish/.stack/programs/x86_64-openbsd/ghc-8.0.2.20170314.temp/ghc-8.0.2.20170314/

The following directories may now contain files, but won't be used by stack:
  - /home/goldfish/.stack/programs/x86_64-openbsd/ghc-8.0.2.20170314.temp/
  - /home/goldfish/.stack/programs/x86_64-openbsd/ghc-8.0.2.20170314/

if the compiled completed correctly, shouldn't this return 8.0.2, and not 7.10.3?

$ pwd
/home/goldfish/ghc
$ ls
ANNOUNCE          bin               config.sub        install-sh        settings
HACKING.md        bindist-list      configure         iserv             settings.in
INSTALL.md        bindistprep       configure.ac      libffi            testsuite
LICENSE           bindisttest       distrib           libffi-tarballs   tmp
MAKEHELP.md       boot              docs              libraries         utils
Makefile          bootstrapping     driver            mk                validate
README.md         compiler          ghc               nofib
Vagrantfile       config.guess      ghc.mk            packages
aclocal.m4        config.log        includes          rts
autom4te.cache    config.status     inplace           rules
$ ghc --vresion
ghc: unrecognised flag: --vresion

Usage: For basic information, try the `--help' option.
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3
$

@Blaisorblade
Copy link
Collaborator

if the compiled completed correctly, shouldn't this return 8.0.2, and not 7.10.3?

Not really. Only stack exec -- ghc --version will use the GHC that stack installs — stack won't install it globally and mess with your system.

Anyway, stack setup says it failed and it seems a correct error.

To fix that failure:

  1. You need to make sure you have xz installed (not default in OpenBSD). This seems the case.
  2. I recommend removing /home/goldfish/.stack/programs/x86_64-openbsd/ghc-8.0.2.2017031* (both folders), since the install failed.
  3. how did you prepare /home/goldfish/ghc-8.0.2.20170314-x86_64-unknown-openbsd.tar.xz?
    It needs to be a bindist like the ones from GHC, with a configure file for setting the prefix later. According to https://ghc.haskell.org/trac/ghc/wiki/Building/Installing#Buildingandinstallingfromabinarydistribution, you need gmake binary-dist to create that file.
  4. If a proper binary dist fails install, try again with stack setup -v to get more verbose logs—take a look for clues and/or post them here.
  5. If instead you get a binary distro that works, and is for an OpenBSD version not otherwise supported, feel free to share! (I think Stack would benefit from builds for stable GHC versions, if possible, but hopefully that should be easier to achieve now).

@ketzacoatl
Copy link
Contributor

How feasible is it to support multiple GHC versions in ports?

@mrijkeboer
Copy link
Author

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

@seanwestfall
Copy link

seanwestfall commented May 10, 2017

@Blaisorblade Already mentioned this to @adamsteen But the only step I needed to do to finish up was run gmake install as root to finish up the install process and install and move the compiled GHC to the global executable. What would be left to upload GHC 8.0.2 to the OpenBSD 6.0 packages/ports list, would this be up to kili? Compiling GHC 8.0.2 on OpenBSD 6.0 hasn't been to hard.

Though, I guess next steps is now compiling GHC 8.2.0 on OpenBSD 6.1.

@Blaisorblade
Copy link
Collaborator

@seanwestfall No: gmake install as root does a global install, and it does not fix stack setup. Stack setup can install multiple GHC versions, but that's only possible because it has its own installation method, and installs things in a non-global location. By default, stack won't even use the globally installed GHC (though it can be configured for that).
That's why stack would need a binary dist, and why I provided instructions to build one.

I'm sure uploasing GHC to ports would help GHC users on BSD, but it's not enough for stack official support.

@ketzacoatl
Copy link
Contributor

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?

@Blaisorblade
Copy link
Collaborator

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.
The bigger issue, at this point, is autodetecting the OpenBSD bindist to use:
#2822 (comment)

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).

@adamsteen
Copy link

@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.

@seanwestfall
Copy link

@Blaisorblade Okay, yes you're right. For some reason, when I followed the instructions for adding the bindist file to the .stack/config.yaml it just produced the errors I reported earlier. I'll fiddle more with stack's config to figure out how to get it to work with the bindist, but running gmake install was the only way for me to know that the compile process could even produce a working GHC.

@Blaisorblade
Copy link
Collaborator

Blaisorblade commented May 19, 2017

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.

@seanwestfall
Copy link

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
Should we care about people getting GHC that way?

@Blaisorblade
Copy link
Collaborator

Should we care about people getting GHC that way?

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.

Though what about what's listed on the ports pages?

In case you wonder: those archives can't be used as bindists, because their contents are different (for instance, no configure and Makefile for installation). It might just be a matter of packaging; I still guess building a bindist from scratch is much easier than trying to adjust those.

@ketzacoatl
Copy link
Contributor

Interestingly, the 8.2.1 release notes mentions the following

GHC HQ now builds FreeBSD and OpenBSD distributions for amd64; this comes after many years of these distributions being faithfully provided by Karel Gardas and Pali Gabor Janos, who we should heartily thank for their contributions.
GHC HQ building these distributions ourselves will allow us to more quickly ship distributions to users by eliminating the need for a long lag time between source release availability and having all binary distributions available.

https://ghc.haskell.org/trac/ghc/blog/ghc-8.2.11-released

@Blaisorblade
Copy link
Collaborator

OK, I've now marked #3184 as fixing this since that's the major stumbling block. I'm not sure that's the only open problem, but this issue is too big—I've forked #3313 out of this to highlight possibly-important remaining steps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.