Newest at the top
| 2024-05-02 18:03:55 +0200 | <tomsmeding> | e.g. specialisation, but also worker-wrapper transformation |
| 2024-05-02 18:03:45 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-02 18:03:39 +0200 | <tomsmeding> | the haskell interface file (.hi) produced by GHC as a side effect of compilation describes where the code is and what it looks like in the object file |
| 2024-05-02 18:03:25 +0200 | <hseg> | oh, because of specialization? |
| 2024-05-02 18:03:14 +0200 | <tomsmeding> | names too |
| 2024-05-02 18:03:12 +0200 | <tomsmeding> | more that the types of the arguments might change on the assembly level |
| 2024-05-02 18:02:52 +0200 | califax | (~califax@user/califx) |
| 2024-05-02 18:02:52 +0200 | <hseg> | eg you'd get a function dropped since it gets inlined everywhere? |
| 2024-05-02 18:02:39 +0200 | <tomsmeding> | yep |
| 2024-05-02 18:02:38 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-02 18:02:27 +0200 | <hseg> | ah -- because a haskell-compatible library edit might expose new optimizations, which might change the effective ABI? |
| 2024-05-02 18:02:01 +0200 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Remote host closed the connection) |
| 2024-05-02 18:01:54 +0200 | <tomsmeding> | so indirectly it's because of optimisations, but the direct cause is lack of ABI stability |
| 2024-05-02 18:01:19 +0200 | <tomsmeding> | the reason for which is, indeed, cross-module optimisations |
| 2024-05-02 18:01:07 +0200 | <tomsmeding> | just that there's no effort at stability |
| 2024-05-02 18:00:56 +0200 | <hseg> | hrm. What causes that instability? |
| 2024-05-02 18:00:35 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 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 |