Newest at the top
| 2024-05-02 18:00:26 +0200 | <tomsmeding> | (this is different from the C world, where C-level compatibility implies ABI-level compatibility if you have the same compiler) |
| 2024-05-02 18:00:05 +0200 | <tomsmeding> | so you have to rebuild dependent libraries and executables anyway |
| 2024-05-02 17:59:56 +0200 | <tomsmeding> | GHC makes no guarantees there |
| 2024-05-02 17:59:49 +0200 | <tomsmeding> | but if you recompile a new version of a library, even if the haskell-level interface is compatible, the binary interface is probably not |
| 2024-05-02 17:59:28 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-02 17:59:12 +0200 | <tomsmeding> | yeah also |
| 2024-05-02 17:59:05 +0200 | <tomsmeding> | e.g. libc, zlib, gmp, etc |
| 2024-05-02 17:58:59 +0200 | <tomsmeding> | note that system libs are still linked dynamically |
| 2024-05-02 17:58:54 +0200 | <hseg> | oh? I thought the ABI instability was caused by the libraries getting infected with the build plans? |
| 2024-05-02 17:58:53 +0200 | danso_o | danso |
| 2024-05-02 17:58:49 +0200 | <tomsmeding> | (for haskell) |
| 2024-05-02 17:58:46 +0200 | <tomsmeding> | but in the haskell community that's a considered a meager win versus the significant increased hassle of dynamic linking |
| 2024-05-02 17:58:20 +0200 | <tomsmeding> | the only reason would be to save a bit of disk space |
| 2024-05-02 17:58:13 +0200 | <tomsmeding> | optimisations too, but that's mostly irrelevant to the point -- even without optimisations it would be pointless |
| 2024-05-02 17:57:58 +0200 | <hseg> | sniped |
| 2024-05-02 17:57:49 +0200 | <tomsmeding> | so you might as well static link |
| 2024-05-02 17:57:46 +0200 | <hseg> | right, which given ghc's cross-module optimizations, is irrelevant for ghc haskell |
| 2024-05-02 17:57:46 +0200 | <tomsmeding> | but GHC doesn't have a stable ABI so that doesn't work for haskell, you have to rebuild dependents anyway |
| 2024-05-02 17:57:32 +0200 | <tomsmeding> | hence allowing one to distribute security updates without having to rebuild the world |
| 2024-05-02 17:57:22 +0200 | <tomsmeding> | the usual security reason for dynamic libraries (disclaimer: I haven't read that specific page) is that you can update dynamic libraries without updating the executable |
| 2024-05-02 17:56:57 +0200 | <tomsmeding> | that is pointless for haskell |
| 2024-05-02 17:56:52 +0200 | <tomsmeding> | with sufficient magic you can make that go dynamically too, but there is typically no good reason for that |
| 2024-05-02 17:56:49 +0200 | <hseg> | https://wiki.archlinux.org/title/Arch_package_guidelines/Security is the relevant policy |
| 2024-05-02 17:56:40 +0200 | <hseg> | ah, OK. Was worried since the packaging system was yelling at me |
| 2024-05-02 17:56:28 +0200 | <tomsmeding> | but haskell libraries are usually linked statically into haskell executables |
| 2024-05-02 17:56:06 +0200 | <tomsmeding> | as far as I understand, those flags are typically relevant if you want to build libraries dynamically |
| 2024-05-02 17:56:06 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-05-02 17:55:32 +0200 | <hseg> | yeah, it's executable |
| 2024-05-02 17:55:20 +0200 | <tomsmeding> | it's an executable, right? |
| 2024-05-02 17:55:14 +0200 | <tomsmeding> | is that a problem? |
| 2024-05-02 17:55:08 +0200 | <hseg> | except the resulting code doesn't have relro or pie enabled (building to double check) |
| 2024-05-02 17:53:50 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 260 seconds) |
| 2024-05-02 17:53:20 +0200 | <tomsmeding> | still, those three flags should be enough |
| 2024-05-02 17:53:20 +0200 | gehmehgeh | gmg |
| 2024-05-02 17:53:19 +0200 | gmg | (~user@user/gehmehgeh) (Killed (NickServ (Forcing logout gmg -> gehmehgeh))) |
| 2024-05-02 17:53:16 +0200 | <tomsmeding> | yeah |
| 2024-05-02 17:53:13 +0200 | <tomsmeding> | I see |
| 2024-05-02 17:53:12 +0200 | <hseg> | (presumably, those need the configuration to carry over?) |
| 2024-05-02 17:53:01 +0200 | <tomsmeding> | `cabal build --prefix=/usr --docdir=... --enable-tests` should do the job |
| 2024-05-02 17:52:52 +0200 | <hseg> | also, I'm configuring since in a later step I also run tests and install it into a directory to be zipped up into a package |
| 2024-05-02 17:52:46 +0200 | <tomsmeding> | the -O is also redundant (it's default), and the --jobs is also default |
| 2024-05-02 17:52:17 +0200 | <hseg> | ah, that's probably cargo-culted from an old build script |
| 2024-05-02 17:52:16 +0200 | <tomsmeding> | is that a solution then? |
| 2024-05-02 17:52:00 +0200 | yin | (~yin@user/zero) (Ping timeout: 245 seconds) |
| 2024-05-02 17:51:55 +0200 | euleritian | (~euleritia@77.22.252.56) (Ping timeout: 246 seconds) |
| 2024-05-02 17:51:47 +0200 | <tomsmeding> | (side note, `cabal configure` is unnecessary here, you can just pass those flags to `cabal build` -- and why are you doing `v2-build`? `build` should work fine with non-ancient cabal) |
| 2024-05-02 17:51:39 +0200 | gehmehgeh | (~user@user/gehmehgeh) |
| 2024-05-02 17:51:33 +0200 | <hseg> | without the third line things build perfectly |
| 2024-05-02 17:51:09 +0200 | <tomsmeding> | without the third line of that command |
| 2024-05-02 17:51:04 +0200 | <tomsmeding> | er |