search

commercialhaskell / stack

The Haskell Tool Stack
http://haskellstack.org
BSD 3-Clause "New" or "Revised" License
3.98k stars 842 forks source link

OpenBSD installer / instructions #416

Closed mrijkeboer closed 7 years ago

mrijkeboer commented 9 years ago

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 commented 9 years ago

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

mrijkeboer commented 9 years ago

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

snoyberg commented 9 years ago

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 commented 9 years ago

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

mrijkeboer commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

mrijkeboer commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

borsboom commented 8 years ago

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

borsboom commented 8 years ago

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 commented 8 years ago

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

mrijkeboer commented 8 years ago

@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 commented 8 years ago

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

The version comes for the following line in the makefile.

mrijkeboer commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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

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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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:

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 commented 8 years ago

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 commented 8 years ago

@borsboom HS_ENCODING is introduced in the following patch.

borsboom commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

-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 commented 8 years ago

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
    deraadt@amd64.openbsd.org:/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 commented 8 years ago

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

mrijkeboer commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

mrijkeboer commented 8 years ago

@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
    deraadt@amd64.openbsd.org:/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 commented 8 years ago

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 commented 8 years ago

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

ketzacoatl commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.