Stack: OpenBSD installer / instructions

[mrijkeboer]

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]

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 [email protected]
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
https://github.com/commercialhaskell/stack/issues/416.

[mrijkeboer]

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

• https://openbsd.dead-parrot.de/distfiles/ghc-7.8.3.20150623-amd64-unknown-openbsd.tar.bz2

[snoyberg]

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?

[mrijkeboer]

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

• http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ghc-7.8.4p2.tgz

[mrijkeboer]

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]

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]

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]

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

[mrijkeboer]

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

[mrijkeboer]

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:

• https://haskell.sru-systems.com/ghc-7.8.4-openbsd-x86_64-current.tar.bz2
• https://haskell.sru-systems.com/ghc-7.10.2-openbsd-x86_64-current.tar.bz2

OpenBSD 5.8/AMD64:

• https://haskell.sru-systems.com/ghc-7.8.4-openbsd-x86_64-5.8.tar.bz2
• https://haskell.sru-systems.com/ghc-7.10.2-openbsd-x86_64-5.8.tar.bz2

The server hosting them should have enough bandwidth.

[ketzacoatl]

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]

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]

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]

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

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]

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]

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

[borsboom]

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

[borsboom]

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]

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

[mrijkeboer]

@ketzacoatl I've used the 'make bootstrap' target of OpenBSD's ghc port. This will build the bindist that is used to build the ghc package. By doing a 'cvs update -PdA' in the ports ghc directory on 5.8 and changing the bindist to the original version for 5.8 I was able to build 7.10 on 5.8. For 7.8 on current I did the opposite 'cvs update -rOPENBSD_5_8 -Pd' and changing the bindist to the original version for current.

Unfortunately there is an error in the bindist-list file that creates the bindist. I references a non existing directory. After removing that offending line the bindist is created.

[mrijkeboer]

@borsboom I haven't tried the ./configure since I didn't know that stack used it that way. The bindists for 5.8 and current probably aren't compatible. Current is indeed a moving target, but that is why I symlinked the 'current' bindist to the correct version (e.g. ghc-7.10.2-openbsd-x86_64-current -> ghc-7.10.2-openbsd-x86_64-current-20151130). This isn't a great solution so if somebody has a better idea I'm all ears.

The bindist is build with the following settings in mk/build.mk (7.10.2):

• HSCOLOUR_SRCS=NO
• GhcLibHcOpts=-O -fasm
• GhcStage1HcOpts=-O -fasm
• GhcStage2HcOpts=-O -fasm
• SplitObjs=NO
• GhcLibWays=v
• GhcRTSWays=
• GhcWithInterpreter=NO
• INTEGER_LIBRARY=integer-gmp2
• SRC_CC_OPTS+=-g -O0
• HADDOCK_DOCS=NO
• LATEX_DOCS=NO
• BUILD_DOCBOOK_HTML=NO
• BUILD_DOCBOOK_PDF=NO
• BUILD_DOCBOOK_PS=NO
• GhcWithSMP=NO
• LD_OPTS=-optl-static -optl-s

The version comes for the following line in the makefile.

• echo ${BOOTSTRAP_DATE} > ${WRKSRC}/VERSION_DATE

[mrijkeboer]

@borsboom Initial I tried to use stack with the OpenBSD ghc package (current 7.10.2) and indeed stack would build, but when I tried to compile a simple HelloWorld program with stack I got problems. I will try if I can reproduce those errors so I can post them here.

What would you prefer having bindists or using the official packages?

[mrijkeboer]

@borsboom On a OpenBSD-current virtual machine I've installed ghc-7.10.2p1 and cabal-install-1.22.6.0 with pkg_add and build stack with cabal. When trying to build the helloworld example I get the following (as root, I know, bad bad me):

# stack new helloworld new-template

Downloading template "new-template" to create project "helloworld" in helloworld/ ...
The following parameters were needed by the template but not provided: author-email, author-name, category, copyright, github-username
You can provide them in /root/.stack/config.yaml, like this:
templates:
  params:
    author-email: value
    author-name: value
    category: value
    copyright: value
    github-username: value
Or you can pass each one as parameters like this:
stack new helloworld new-template -p "author-email:value" -p "author-name:value" -p "category:value" -p "copyright:value" -p "github-username:value"
Writing default config file to: /root/helloworld/stack.yaml
Basing on cabal files:
- /root/helloworld/helloworld.cabal

Downloaded lts-3.16 build plan.
Caching build plan
Fetched package index.                                                          Populated index cache.
Checking against build plan lts-3.16
Selected resolver: lts-3.16
Wrote project config to: /root/helloworld/stack.yaml

# cd helloworld/
# stack build
[1 of 1] Compiling Main             ( /tmp/stack27098/Setup.hs, /tmp/stack27098/Setup.o )
Linking /root/.stack/setup-exe-cache/tmp-setup-Simple-Cabal-1.22.4.0-x86_64-openbsd-ghc-7.10.2 ...
/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/base_GDytRqRVSUX7zckgKqJjgw/libHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw.a(IO__1.o): In function `ghczuwrapperZC0ZCbaseZCSystemziIOZCrand':
(.text+0x1): warning: warning: rand() may return deterministic values, is that what you want?
/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()
helloworld-0.1.0.0: configure
Configuring helloworld-0.1.0.0...
helloworld-0.1.0.0: build
Preprocessing library helloworld-0.1.0.0...
[1 of 1] Compiling Lib              ( src/Lib.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.4.0/build/Lib.o )
In-place registering helloworld-0.1.0.0...
Preprocessing executable 'helloworld-exe' for helloworld-0.1.0.0...
[1 of 1] Compiling Main             ( app/Main.hs, .stack-work/dist/x86_64-openbsd/Cabal-1.22.4.0/build/helloworld-exe/helloworld-exe-tmp/Main.o )
Linking .stack-work/dist/x86_64-openbsd/Cabal-1.22.4.0/build/helloworld-exe/helloworld-exe ...
/usr/local/lib/ghc/rts/libHSrts_thr.a(RtsFlags.thr_o): In function `copyArg':

Could not resolve file /root/helloworld/rts/RtsFlags.c

[ketzacoatl]

@mrijkeboer, @borsboom, etc, what seems to be the deliverable we could make happen with OpenBSD 5.8? I do not believe it makes sense to do anything with -current, unless we had a super easy way (vagrant/etc) to run the builds on a recent snapshot (but mrijk's most recent comment suggests GHC itself might need a patch?).

I believe it would be valuable to have a stack executable built in the release process, that would be installable and usable on OpenBSD 5.8. Aside from the build automation to make that executable with each release, what else needs to be done for this to be usable?

[borsboom]

I'd say the minimum deliverables to say Stack has first-class support for platform are:

• stack setup should be able to install at least GHC 7.8.4 and 7.10.2, which means having bindists for those versions that behave the same way as official GHC bindists behave
• Stack should be able to build code that uses the subset of Stackage that doesn't require any special system libraries (e.g. pcre) "out of the box" (without any weird errors or extra steps)
• The Stack release process should build Stack bindists (and, ideally, distro packages)

For second-class support, I think it's OK to have to use the system package manager to install GHC, but Stack should still be able to build projects using that subset of Stackage. Thus far we have not released any Stack bindists or distro packages for second-class platforms, and I'd be reluctant to start since it implies a level of support we can't give. Also the Stack bindists exist so people can just get started _without_ having to install GHC first, so if you have to install a system-wide GHC anyway, you might as well just cabal install stack.

[mrijkeboer]

@ketzacoatl If you mean to have stack in ports (OpenBSD package) than you have to go with -current, since OpenBSD only adds security fixes in the release/stable port branches. Besides, most people who use OpenBSD as a desktop will use current (including myself). However, I do use release/stable versions on my servers, hence I tried to build bindists for both.

[mrijkeboer]

@borsboom I would really like stack to have first-class support for OpenBSD. I'm willing to try to make that happen, but I need some help since it is quite out of my league.

[borsboom]

Probably the next thing I'd look into is how the semi-official FreeBSD bindists are built, since those would be the most similar to OpenBSD. And then try that process, but with some or all of the OpenBSD port's patches applied. Note: currently the FreeBSD bindists aren't supported either because they require special configure arguments which Stack does not support (but could easily be made to support); see #1253.

[ketzacoatl]

I would like to see stack run cleanly on OpenBSD, though that does not need to include auto-installs for GHC and the like right out of the gate. Given what we're looking at, an initial MVP here could focus on:

• establish the process for installing stack so it can build _something_
• fix bugs that prevent stack from building haskell packages as expected

I do not believe it is fair or accurate to say _most people with desktops_ use snapshots/-current (or show your source). It may make sense to get to this MVP through a process that works on -current, but having a package that installs on the latest release (5.8, not -current) is the right thing to do (WRT first class support).

[mrijkeboer]

I downloaded the GHC source (7.10.2) and can run ./configure without problems. When building, ghc-stage1 is build successful, but when building the base library I get the following error:

checking value of O_BINARY... 0
checking for library containing iconv... no
configure: error: iconv is required on non-Windows platforms
libraries/base/ghc.mk:4: recipe for target 'libraries/base/dist-install/package-data.mk' failed
gmake[1]: *** [libraries/base/dist-install/package-data.mk] Error 1
Makefile:71: recipe for target 'build' failed
gmake: *** [build] Error 2

The strange thing is that libiconv is installed in /usr/local/.

[mrijkeboer]

@borsboom HS_ENCODING is introduced in the following patch.

[borsboom]

Right, Stack could easily be modified to set HS_ENCODING (it's already setting other locale variables in many cases). GHC 7.10.3 will support a GHC_CHARENC variable with a similar purpose, so not sure of HS_ENCODING will even be necessary anymore once it is released.

[mrijkeboer]

I've build a bindist of GHC 7.10.3 that seems to work on OpenBSD-current:

$ curl -O https://haskell.sru-systems.com/ghc-7.10.3-openbsd-x86_64-current.tar.bz2
$ tar jxf  ghc-7.10.3-openbsd-x86_64-current.tar.bz2
$ cd ghc-7.10.3
$ ./configure --prefix /home/admin/.ghc-7.10.3
$ gmake install
$ export PATH=/home/admin/.ghc-7.10.3/bin:$PATH
$ which ghc
/home/admin/.ghc-7.10.3/bin/ghc
$ cd
$ cat >>hello.hs
main = putStrLn "Hello, world"
$ ghc hello.hs
[1 of 1] Compiling Main             ( hello.hs, hello.o )
Linking hello ...
/home/admin/.ghc-7.10.3/lib/ghc-7.10.3/rts/libHSrts.a(RtsFlags.o): In function `copyArg':

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

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

I have taken the following steps to build this bindist:

$ doas su -
# pkg_add ghc gtar-- docbook-xsl autoconf-2.61p4 automake-1.4.6p4 bzip2 gmake curl
# exit
$ cd
$ curl -O http://downloads.haskell.org/~ghc/7.10.3/ghc-7.10.3b-src.tar.bz2
$ curl -O http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/ghc/patches/patch-ghc_mk?rev=1.11
$ mv patch-ghc_mk\?rev\=1.11 patch-ghc_mk
$ curl -O http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/ghc/patches/patch-libffi_ghc_mk?rev=1.5
$ mv patch-libffi_ghc_mk\?rev\=1.5 patch-libffi_ghc_mk
$ curl -O http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/ghc/patches/patch-libraries_Cabal_Cabal_Distribution_Simple_Program_Strip_hs?rev=1.1
$ mv patch-libraries_Cabal_Cabal_Distribution_Simple_Program_Strip_hs\?rev\=1.1 patch-libraries_Cabal_Cabal_Distribution_Simple_Program_Strip_hs
$ curl -O http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/ghc/patches/patch-libraries_process_include_runProcess_h?rev=1.3
$ mv patch-libraries_process_include_runProcess_h?rev=1.3 patch-libraries_process_include_runProcess_h
$ curl -O http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/ghc/patches/patch-mk_config_mk_in?rev=1.11
$ mv patch-mk_config_mk_in?rev=1.11 patch-mk_config_mk_in
$ curl -O http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/ghc/patches/patch-rts_Linker_c?rev=1.11
$ mv patch-rts_Linker_c?rev=1.11 patch-rts_Linker_c
$ tar jxf ghc-7.10.3b-src.tar.bz2
$ cd ghc-7.10.3
$ patch -p0 < ../patch-ghc_mk
$ patch -p0 < ../patch-libffi_ghc_mk
$ patch -p0 < ../patch-libraries_Cabal_Cabal_Distribution_Simple_Program_Strip_hs
$ patch -p0 < ../patch-libraries_process_include_runProcess_h
$ patch -p0 < ../patch-mk_config_mk_in
$ patch -p0 < ../patch-rts_Linker_c
$ export AUTOCONF_VERSION=2.61
$ export AUTOMAKE_VERSION=1.4
$ env CC=gcc ./configure --prefix=/home/admin/.ghc-7.10.3 \
> --with-iconv-includes=/usr/local/include \
> --with-iconv-libraries=/usr/local/lib
$ gmake all binary-dist

[HaskellOpenBSD]

-stable user here, would be happy to do what I can to help. Currently my want-to is stronger than my knowledge, but I'm open to learning and/or grunt work.

[mrijkeboer]

Stack 1.1.0 now successfully builds on OpenBSD 5.9-current (AMD64) with packages from ports:

$ sysctl kern.version
kern.version=OpenBSD 5.9-current (GENERIC.MP) #2018: Mon May  9 04:43:24 MDT 2016
    [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
$ doas su -
# pkg_add ghc cabal-install
# exit
$ pkg_info | grep ghc
ghc-7.10.3p4        compiler for the functional language Haskell
$ pkg_info | grep cabal
cabal-install-1.22.6.0 command-line interface for Cabal and Hackage
$ cabal install stack
$ stack --version
Version 1.1.0 x86_64 hpack-0.13.0
$ stack new helloworld
$ cd helloworld
$ stack build
$ stack exec helloworld-exe
someFunc

Unfortunately it doesn't work on 5.9 (release/stable). The command cabal install stack fails with the following error:

...
Installed connection-0.2.5
cabal: user error (Error: some packages failed to install:
aeson-0.11.2.0 depends on text-1.2.2.1 which failed to install.
aeson-compat-0.3.3.0 depends on text-1.2.2.1 which failed to install.
attoparsec-0.13.0.2 depends on text-1.2.2.1 which failed to install.
bifunctors-5.3 depends on text-1.2.2.1 which failed to install.
binary-tagged-0.1.4.0 depends on text-1.2.2.1 which failed to install.
blaze-builder-0.4.0.2 depends on text-1.2.2.1 which failed to install.
blaze-html-0.8.1.1 depends on text-1.2.2.1 which failed to install.
blaze-markup-0.7.0.3 depends on text-1.2.2.1 which failed to install.
case-insensitive-1.2.0.6 depends on text-1.2.2.1 which failed to install.
comonad-5 depends on text-1.2.2.1 which failed to install.
conduit-extra-1.1.13.1 depends on text-1.2.2.1 which failed to install.
contravariant-1.4 depends on text-1.2.2.1 which failed to install.
cookie-0.4.2 depends on text-1.2.2.1 which failed to install.
cryptohash-conduit-0.1.1 depends on text-1.2.2.1 which failed to install.
either-4.4.1 depends on text-1.2.2.1 which failed to install.
fast-logger-2.4.6 depends on text-1.2.2.1 which failed to install.
free-4.12.4 depends on text-1.2.2.1 which failed to install.
fsnotify-0.2.1 depends on text-1.2.2.1 which failed to install.
hashable-1.2.4.0 depends on text-1.2.2.1 which failed to install.
hastache-0.6.1 depends on text-1.2.2.1 which failed to install.
hpack-0.13.0 depends on text-1.2.2.1 which failed to install.
http-api-data-0.2.2 depends on text-1.2.2.1 which failed to install.
http-client-0.4.28 depends on text-1.2.2.1 which failed to install.
http-client-tls-0.2.4 depends on text-1.2.2.1 which failed to install.
http-conduit-2.1.10.1 depends on text-1.2.2.1 which failed to install.
http-types-0.9 depends on text-1.2.2.1 which failed to install.
mime-types-0.1.0.7 depends on text-1.2.2.1 which failed to install.
monad-logger-0.3.18 depends on text-1.2.2.1 which failed to install.
network-uri-2.6.1.0 depends on text-1.2.2.1 which failed to install.
optparse-simple-0.0.3 depends on text-1.2.2.1 which failed to install.
parsec-3.1.9 depends on text-1.2.2.1 which failed to install.
path-pieces-0.2.1 depends on text-1.2.2.1 which failed to install.
persistent-2.5 depends on text-1.2.2.1 which failed to install.
persistent-sqlite-2.5 depends on text-1.2.2.1 which failed to install.
persistent-template-2.5.1.1 depends on text-1.2.2.1 which failed to install.
profunctors-5.2 depends on text-1.2.2.1 which failed to install.
project-template-0.2.0 depends on text-1.2.2.1 which failed to install.
resource-pool-0.2.3.2 depends on text-1.2.2.1 which failed to install.
scientific-0.3.4.6 depends on text-1.2.2.1 which failed to install.
semigroupoids-5.0.1 depends on text-1.2.2.1 which failed to install.
semigroups-0.18.1 depends on text-1.2.2.1 which failed to install.
stack-1.1.0 depends on text-1.2.2.1 which failed to install.
streaming-commons-0.1.15.4 depends on text-1.2.2.1 which failed to install.
text-1.2.2.1 failed during the configure step. The exception was:
ExitFailure (-10)
text-binary-0.2.1 depends on text-1.2.2.1 which failed to install.
unordered-containers-0.2.7.0 depends on text-1.2.2.1 which failed to install.
void-0.7.1 depends on text-1.2.2.1 which failed to install.
yaml-0.8.17.1 depends on text-1.2.2.1 which failed to install.
zip-archive-0.2.3.7 depends on text-1.2.2.1 which failed to install.
)

[ketzacoatl]

@mrijkeboer, that is awesome to see! Question: are you able to run the stack executable from 5.9-current on 5.9-release?

[mrijkeboer]

Unfortunately not:

$ stack --version                                                            
stack: can't load library 'libc.so.87.0'
$ ldd stack                                                                    
stack:
stack: can't load library 'libpthread.so.22.0'
stack: exit status 4

[ketzacoatl]

@mrijkeboer, are you able to dig into why this fails?

text-1.2.2.1 failed during the configure step. The exception was:
ExitFailure (-10)

Does it seem feasible to get stack building on 5.9 release/stable, or should we just wait for current to become 6.0?

[mgsloan]

We've gotten results like that (except ExitFailure (-7)) to indicate conditions like OOM. Perhaps it's something similar?

[mrijkeboer]

@mgsloan, it was indeed an OOM like issue. I was building stack as a normal user, which has limited resources by default under OpenBSD. I've now successfully build stack as root on a temporary VPS. However, setting the correct resource limits for a user would probably also work.

# sysctl kern.version
kern.version=OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST 2016
    [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
# pkg_add ghc cabal-install
# pkg_info | grep ghc
ghc-7.10.3p0        compiler for the functional language Haskell
# pkg_info | grep cabal
cabal-install-1.22.6.0 command-line interface for Cabal and Hackage
# cabal install stack
# stack --version
Version 1.1.0 x86_64 hpack-0.14.0
# stack new helloworld
# cd helloworld
# stack build
# stack exec helloworld-exe
someFunc

[ketzacoatl]

OK, now that we can easily build/run stack on the active OpenBSD release, I met up with @manny-fp to identify what would be left to do (in stack), to more officially bring stack to OpenBSD:

If there's a GHC bindist that works "normally" (i.e. you can run ./configure --prefix= && make && make install to install it where you want, and it "just works") then it's just a matter of configuration to get Stack to use it. In terms of Stack itself, we'd need etc/scripts/vagrant-releases.sh to also build a Stack bindist for OpenBSD. And for that, there'd need to be a Vagrantfile that sets up a similar environment to those that are in etc/vagrant for various Linux distros.

stack setup uses the metadata here to find the right GHC bindist for your operating system: https://github.com/fpco/stackage-content/blob/master/stack/stack-setup-2.yaml#L71. There's a reasonable chance that just adding a bindist for OpenBSD there will work out of the box.

That ought to be pretty straight forward.

As a longer-term thing, the next topic would be to get OpenBSD up on https://www.haskell.org/ghc/download_ghc_7_10_3#binaries as an officially support platform, that ought to make it possible to to get support for multiple GHC versions via stack setup. I can follow up with kili and the GHC devs to figure out what next steps are there.

[mrijkeboer]

@ketzacoatl, it would be really nice if you could follow it up with kili and the GHC devs, as you suggested above.

[ketzacoatl]

Yes, if all goes according to plan, I will make small steps on this over the next couple of weeks. ATM, getting OpenBSD incorporated into the Stack release process is my primary goal, and getting Kili's work merged upstream (and GHC's official support for OpenBSD as a platform) is secondary. I'll update here as I make progress towards these goals.

[borsboom]

@ketzacoatl Keep in mind that we don't normally make an OS part of the official Stack release process unlress there are already officially supported GHC bindists for that OS, so it sounds like you may be doing this in reverse order. We can make an exception if there will be community-supported GHC bindists for the OS, but that would be a prerequisite before making official Stack releases.

[borsboom]

I just added official FreeBSD bindist support to the release process, so adding it for OpenBSD should be similar (once there are usable GHC bindists, of course). Here's the commit with all the changes: https://github.com/commercialhaskell/stack/commit/cb6da863d0c14c2d93916c3e0cf45c1c33b3143d

[borsboom]

Good news! Looks like GHC 8.0.1 includes an official OpenBSD bindist. See https://www.haskell.org/ghc/download_ghc_8_0_1#openbsd_x86_64

[ketzacoatl]

That's... interesting. I wonder if the "SPARC" bit is a typo. So @borsboom, should stack support skip the 7.x series, or use the unofficial builds we have access to?

[borsboom]

Yeah, that's a typo. It's referred to as x86_64 everywhere else, and I'm trying the bindist on x86_64 right now. I tested @mrijkeboer's 7.10.3 bindist and it seems to work on openbsd-5.9, so I think we should use that as well. I've copied it over to S3 and added it to the stack setup metadata. Now the only issue I'm running into is that OpenBSD's tar doesn't seem to support detecting and uncompressing .bz2 and .xz files on its own, which stack setup expects it to be able to do:

$ stack setup
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Downloaded ghc-7.10.3.
Running /bin/tar xf /home/vagrant/.stack/programs/x86_64-openbsd/ghc-7.10.3.tar.bz2 in directory /tmp/stack-setup7059/ exited with ExitFailure 1


tar: input compressed with bzip2; use the -j option to decompress it

It does have the -j flag for .bz2 files, but not the -J flag for .xz files. Might just be simplest if Stack is modified to pipe into tar from bzcat or xzcat instead.

[borsboom]

I take it back about the ghc-7.10.3 bindist. It does work fairly well, but some packages (like generics-sop, a dependency of Stack) fail to build with ExitFailure (-11) (aka segmentation fault). I was able to build Stack and its dependencies using the official ghc-8.0.1 bindist, though.

[borsboom]

Steps remaining for official OpenBSD support:

• [x] Have stack setup use bzcat/xzcat to uncompress GHC bindist instead of relying on tar to do it (see also https://github.com/commercialhaskell/stack/issues/2283)
• [x] Await a Stackage LTS snapshot that uses GHC 8.0.x and update the Stack build process (and integration tests) to use it
• [ ] Ensure integration tests pass
• [ ] Integrate into release process (I've already added a starter Vagrantfile in etc/vagrant/openbsd-5.9-amd64/Vagrantfile)
• [x] Perhaps remove old not-quite-working OpenBSD bindists from stack-setup-2.yaml, to avoid confusion.

[Blaisorblade]

https://github.com/commercialhaskell/stack/pull/2456#issuecomment-238330797 confirms that ghc-7.8.3.20150623 fails installation, though there was no actual report here AFAICS. Opening the tarball reveals the extracted folder is named ghc-7.8.3.20150623 rather than ghc-7.8.3 as expected in the code.

[seanwestfall]

Hey guys, is anyone still working on this. Recently tried a cabal install stack on OpenBSD 6.0 on an AMD64 virtual machine.

Got this error during compiling:

# cabal install stack
...
cabal: user error (Error: some packages failed to install:
stack-1.2.0 depends on store-0.2.1.2 which failed to install.
store-0.2.1.2 failed during the building phase. The exception was:
ExitFailure (-10)
)
# cabal install store-0.2.1.2
Resolving dependencies...
Configuring store-0.2.1.2...
Building store-0.2.1.2...
Preprocessing library store-0.2.1.2...
[ 1 of 10] Compiling System.IO.ByteBuffer ( src/System/IO/ByteBuffer.hs, dist/build/System/IO/ByteBuffer.o )
[ 2 of 10] Compiling Data.Store.Impl  ( src/Data/Store/Impl.hs, dist/build/Data/Store/Impl.o )
[ 3 of 10] Compiling Data.Store.TH    ( src/Data/Store/TH.hs, dist/build/Data/Store/TH.o )
[ 4 of 10] Compiling Data.Store.TH.Internal ( src/Data/Store/TH/Internal.hs, dist/build/Data/Store/TH/Internal.o )
[ 5 of 10] Compiling Data.Store.Internal ( src/Data/Store/Internal.hs, dist/build/Data/Store/Internal.o )
Failed to install store-0.2.1.2
cabal: user error (Error: some packages failed to install:
store-0.2.1.2 failed during the building phase. The exception was:
ExitFailure (-10)
)
#

So obviously this is a store-0.2.1.2 issue, I opened an issue there as well: https://github.com/fpco/store/issues/85

[seanwestfall]

hey guys, fixed the issue by doubling the ram on the virtual machine. So ignore the comment above.

[dhouthoo]

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]

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
https://github.com/commercialhaskell/stack/issues/416#issuecomment-220405106).

What's the way forward to unblock this?

This is relevant:
https://github.com/commercialhaskell/stack/issues/416#issuecomment-220801230
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]

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]

@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
    [email protected]:/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
    [email protected]:/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
    [email protected]:/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
    [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP

$ sha256 Main                       
SHA256 (Main) = afece87c07c79b68737efca66bdde280d84202cec4f33bd34fbc3b6a1431abc9

$ ./Main                                                                      
Hello

[Blaisorblade]

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

@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
    [email protected]:/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]

@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: https://github.com/golang/go/issues/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]

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]

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



md5-5d31ea2583da995557e4e7a00260e43b



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



md5-8471f6cd73214bb860e1c999d342677f



$ 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]

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

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" [e-mail] 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
https://github.com/commercialhaskell/stack/issues/416#issuecomment-292829292,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARsqHFqHruvGho3kc8xvCRjI4ovgqWVks5ruYZSgaJpZM4FL9qe
.

[seanwestfall]

Success guys! :tada: 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]

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]

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

[mrijkeboer]

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]

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

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

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]

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:
https://github.com/commercialhaskell/stack/issues/2822#issuecomment-300591681

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]

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

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

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 (https://github.com/commercialhaskell/stack/compare/master...check-openbsd-release). I also sketched the needed changes to Stack config to find the bindists (https://github.com/fpco/stackage-content/pull/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]

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]

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]

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]

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.