| 18 Apr 2024 |
 Mike Pilgrem | He sm: The key ingredient is Olivier Benz's unofficial GHC musl binary distributions. He only makes them available via his Docker images. | 21:05:58 |
| Mike Pilgrem | * sm: The key ingredient is Olivier Benz's unofficial GHC musl binary distributions. He only makes them available via his Docker images. | 21:06:28 |
 sm | oh I see, I didn't quite get that on first reading (my brain read "do the build with funny options in alpine linux") | 21:07:33 |
| sm | that's a great reference link (ghc-musl). Thought it's not really clear why a special docker image is required for this task, when cabal just needs a single flag. | 21:10:06 |
| sm | * that's a great reference link (ghc-musl). Though it's not really clear why a special docker image is required for this task, when cabal just needs a single flag. | 21:10:15 |
| sm | * that's a great reference link (ghc-musl). Though it's not really clear (in the ghc-musl readme either) why a special docker image is required for this task, when cabal just needs a single flag. | 21:10:33 |
| sm | * that's a great reference link (ghc-musl). Though it's not really clear (in the ghc-musl readme either) why a special docker image is required for this task, when cabal just needs alpine and a single command-line flag. | 21:16:34 |
| Mike Pilgrem | sm: as a Windows user, I am 'flying on instruments' here but I understand that: (1) there is (a) 'glibc' and (b) lightweight 'musl libc' (2) if you are producing statically-linked executables, you really want 'musl libc' (because it is lightweight) (3) the GHC project does not itself produce 'musl libc' versions of GHC (4) but people (including Olivier Benz) have created 'musl libc' versions of GHC (5) and Olivier's versions are available only in the form of Docker images. | 22:32:23 |
| sm | As I understand it building on Alpine linux takes care of the musl libc part. But possibly building with this custom GHC produces a more static executable than cabal's flag, I know it's not a simple binary description | 22:48:55 |
| sm | It's also possible that the ghc installed by ghcup on Alpine already includes similar special sauce for static linking | 22:50:56 |
| Mike Pilgrem | sm: I came across this series of blog posts, which include a Stack v Cabal comparison, which may be of interest: https://www.extrema.is/blog/2022/03/24/ghc-musl-part-1 | 23:08:01 |
| sm | good find! | 23:10:37 |
| sm | two years old, but things probably haven't changed too much | 23:11:24 |
| 19 Apr 2024 |
 chreekat | I believe that it is literally impossible to achieve a fully statically-linked binary with glibc | 08:04:24 |
| chreekat | GHC has some ... experimental? Broken? (It's hard to ascertain because of abuse of CI) bindists that may in theory be used to create statically-linked binaries | 08:07:08 |
| chreekat | e.g. https://downloads.haskell.org/~ghc/9.6.5/ghc-9.6.5-x86_64-alpine3_12-linux.tar.xz | 08:07:39 |
| chreekat | That has a dynamically-linked GHC that can nonetheless, possibly, be used to generate statically-linked executables | 08:08:02 |
| chreekat | * That is a dynamically-linked GHC that can nonetheless, possibly, be used to generate statically-linked executables | 08:08:08 |
| chreekat | Some hint to their purpose and state of brokenness can be seen from the code that generates CI jobs:
-- Fully static build, in theory usable on any linux distribution.
, fullyStaticBrokenTests (standardBuildsWithConfig Amd64 (Linux Alpine312) (splitSectionsBroken static))
-- Dynamically linked build, suitable for building your own static executables on alpine
, disableValidate (standardBuildsWithConfig Amd64 (Linux Alpine312) (splitSectionsBroken vanilla))
, disableValidate (standardBuildsWithConfig AArch64 (Linux Alpine318) (splitSectionsBroken vanilla))
, disableValidate (standardBuildsWithConfig Amd64 (Linux Alpine318) (splitSectionsBroken vanilla))
, fullyStaticBrokenTests (disableValidate (allowFailureGroup (standardBuildsWithConfig Amd64 (Linux Alpine312) staticNativeInt)))
| 08:09:03 |
| chreekat | "broken"..."disable"... | 08:09:25 |
| Mike Pilgrem | sm From 7 Oct 2015: https://www.fpcomplete.com/blog/static-compilation-with-stack/ | 09:45:31 |
| Mike Pilgrem | * sm From 7 Oct 2016: https://www.fpcomplete.com/blog/static-compilation-with-stack/ | 09:46:00 |
| chreekat | I've now published most of the stackage deployment configuration: https://github.com/commercialhaskell/stackage-infrastructure | 09:53:22 |
| 20 Apr 2024 |
| Mike Pilgrem | Should Stack augment the Stack-supplied MSYS2 with pkgconf?
I am consulting on the above topic (there is also a related Stack issue #1586, from 2016). The context is this: Haskell package zlib is popular: on Hackage, over 7,700 packages depend on it (including stack). From version 0.7 (now included in nightly-2024-04-11), by default, it will not build with Stack unless either (a) executable pkg-config is on the PATH or (b) --flag zlib:-pkg-config is passed. MSYS2 does not provide pkg-config 'out of the box', but it can be installed using stack exec -- pacman -S pkgconf. Historically, the Stack-supplied MSYS2 has been what the MSYS2 project provides 'out of the box' and it has been left to users to decide what, if any, other MSYS2 packages they install.
| 20:15:09 |
| 22 Apr 2024 |
| chreekat | I just discovered https://docs.haskellstack.org/en/stable/yaml_configuration/#building-ghc-from-source . I wonder if it works | 09:28:02 |
| Mike Pilgrem | chreekat: On building GHC from source with Stack, relatively recently I've got it to work on Windows but I think it is fragile. | 23:19:47 |
| 23 Apr 2024 |
| chreekat | Mike Pilgrem: well that's remarkable | 05:38:22 |
|  Chris Dornan joined the room. | 14:32:56 |
| Chris Dornan set a profile picture. | 15:12:17 |
| 25 Apr 2024 |
|  Nguyễn Trọng Cường joined the room. | 14:28:59 |
