Logs: liberachat/#haskell
| 2026-03-26 13:06:04 | <merijn> | or is test-wai the project name |
| 2026-03-26 13:06:19 | <merijn> | That paste is from after my comment, though :p |
| 2026-03-26 13:06:25 | <int-e> | Anyway, I think I know why. It's this: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.6/compiler/GHC/Linker/ExtraObj.hs#L234-236 (read the comment; Darwin is not an ELF target) |
| 2026-03-26 13:06:45 | <int-e> | It would work fine under Linux ;) |
| 2026-03-26 13:06:57 | → | xff0x joins (~xff0x@2405:6580:b080:900:634f:4ad0:7953:dee2) |
| 2026-03-26 13:07:44 | <int-e> | "not an ELF target" -- that's essentially what `platformSupportsSavingLinkOpts` checks, with one exception that's irrelevant) |
| 2026-03-26 13:11:40 | <int-e> | Warning: The package list for 'hackage.haskell.org' is 64 days old. |
| 2026-03-26 13:11:40 | <int-e> | Run 'cabal update' to get the latest list of available packages. |
| 2026-03-26 13:11:43 | <int-e> | gah |
| 2026-03-26 13:12:51 | <mesaoptimizer> | merijn: that is the name of the directory. I created a new cabal project to test [exa]'s issue: https://github.com/yesodweb/wai/issues/825 |
| 2026-03-26 13:13:05 | <int-e> | Here's a test of this under Linux: https://paste.debian.net/hidden/bc4ce81e ...note 1) line 27, where GHC links the executable because the flags changed, and 2) that when I didn't change the .cabal file, cabal-install said "Up to date" and didn't mention building the executable. |
| 2026-03-26 13:13:41 | <mesaoptimizer> | (on that note, I haven't stress-tested the compiled version, I will do that now) |
| 2026-03-26 13:14:21 | → | machinedgod joins (~machinedg@d172-219-48-230.abhsia.telus.net) |
| 2026-03-26 13:16:24 | <mesaoptimizer> | [exa]: even the compiled version doesn't crash or exit after hitting `Network.Socket.accept: resource exhausted (Too many open files)` multiple times. It continues to work and return 200s as expected (after a while) |
| 2026-03-26 13:18:13 | × | koala_man quits (~vidar@157.146.251.23.bc.googleusercontent.com) (Read error: Connection reset by peer) |
| 2026-03-26 13:18:18 | <mesaoptimizer> | int-e: interesting, so the issue is that it cannot do linking on existing executables on Darwin and FreeBSD? |
| 2026-03-26 13:18:28 | → | koala_man joins (~vidar@157.146.251.23.bc.googleusercontent.com) |
| 2026-03-26 13:19:50 | <int-e> | mesaoptimizer: the issue is that GHC doesn't know how to record and later read the compilation flags in an executable on non-ELF system, plus the recompilation check is optimistic (assume flags haven't changed) instead of conservative. |
| 2026-03-26 13:21:01 | <int-e> | FreeBSD should work since it uses ELF |
| 2026-03-26 13:23:02 | <mesaoptimizer> | oh, the solaris thing is irrelevant here |
| 2026-03-26 13:23:17 | <mesaoptimizer> | since it checks instead for `osElfTarget os` |
| 2026-03-26 13:23:26 | <mesaoptimizer> | on line https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.6/compiler/GHC/Linker/ExtraObj.hs#L215 |
| 2026-03-26 13:24:04 | <mesaoptimizer> | so how do I make GHC recompilation 'conservative'? |
| 2026-03-26 13:24:38 | <mesaoptimizer> | https://downloads.haskell.org/~ghc/9.4.5/docs/users_guide/separate_compilation.html#the-recompilation-checker I see, `-fforce-recomp` |
| 2026-03-26 13:25:23 | <int-e> | how often are you really going to change the link flags? just delete the build directory |
| 2026-03-26 13:25:47 | <int-e> | cabal-install could work around this if it wanted to |
| 2026-03-26 13:26:04 | <int-e> | (it knows where the executable is and could delete it when flags change) |
| 2026-03-26 13:26:12 | <mesaoptimizer> | isn't that the same thing as using `-fforce-recomp` in your .cabal file? |
| 2026-03-26 13:26:29 | <int-e> | you really don't want that on permanently, I think |
| 2026-03-26 13:26:51 | × | koala_man quits (~vidar@157.146.251.23.bc.googleusercontent.com) (Ping timeout: 255 seconds) |
| 2026-03-26 13:26:51 | <int-e> | it'll recompile the whole package every single time |
| 2026-03-26 13:27:36 | <int-e> | and the problem is specific to linking executables when link flags change |
| 2026-03-26 13:27:56 | <int-e> | outside of that the recompilation check should be accurate |
| 2026-03-26 13:28:16 | <int-e> | now if there was an -fforce-relink... that would be more tempting |
| 2026-03-26 13:28:26 | <mesaoptimizer> | I see. How would `cabal-install` work around this? |
| 2026-03-26 13:28:58 | <mesaoptimizer> | and if I do a `cabal build` twice in succession with `-fforce-recomp` on, it doesn't build a second time |
| 2026-03-26 13:29:24 | <int-e> | cabal-install tracks when the .cabal file changes |
| 2026-03-26 13:29:56 | <int-e> | mesaoptimizer: right, because cabal-install tracks that particular case: if none of the project source files (including the .cabal file) changed, it'll not run GHC at all. |
| 2026-03-26 13:30:27 | <int-e> | But if anything changes, it'll tell GHC to rebuild the whole thing and rely on GHC to be clever about reusing existing artifacts |
| 2026-03-26 13:30:46 | <int-e> | and -fforce-recomp will tell GHC to be stupid |
| 2026-03-26 13:31:00 | <mesaoptimizer> | I see |
| 2026-03-26 13:34:21 | <merijn> | int-e: FreeBSD does not use ELF |
| 2026-03-26 13:34:32 | <merijn> | There's a linux compat layer that *can* use ELF |
| 2026-03-26 13:34:47 | <merijn> | but it's not the default unless there've been some major overhauls since I last checked |
| 2026-03-26 13:34:55 | → | Buliarou1 joins (~gypsydang@46.232.210.139) |
| 2026-03-26 13:35:37 | <merijn> | In practice you're not changing linker flags often enough for it to really matter, tbh |
| 2026-03-26 13:35:58 | <mesaoptimizer> | I'd like it to not fail silent regardless |
| 2026-03-26 13:36:20 | <mesaoptimizer> | how do you make cabal-install delete the executable and rebuild if the linker flags were changed, anyway? |
| 2026-03-26 13:38:11 | <int-e> | merijn: Well that's another GHC bug then: https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/ghc-platform/src/GHC/Platform/ArchOS.hs#L163-180 |
| 2026-03-26 13:38:36 | <int-e> | merijn: that, or the function name is misleading ;) |
| 2026-03-26 13:41:53 | → | kuribas joins (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2026-03-26 13:42:01 | <int-e> | (The code in compiler/GHC/SysTools/Elf.hs does look very much like it'll only work on ELF) |
| 2026-03-26 13:42:01 | × | myme quits (~myme@2a01:799:d5e:5f00:bb34:b3ad:fa86:ff90) (Ping timeout: 268 seconds) |
| 2026-03-26 13:42:05 | <mesaoptimizer> | "Since the ELF tools available offered a solution to the shared library problem and were generally seen as “the way forward” anyway, the migration cost was accepted as necessary and the transition made. FreeBSD's shared library mechanism is based more closely on Sun's SunOS™ style shared library mechanism and, as such, is very easy to use." |
| 2026-03-26 13:42:07 | <int-e> | s/on/with/? |
| 2026-03-26 13:42:07 | <mesaoptimizer> | https://docs-archive.freebsd.org/doc/7.3-RELEASE/usr/share/doc/handbook/binary-formats.html |
| 2026-03-26 13:42:10 | <mesaoptimizer> | FreeBSD uses ELF |
| 2026-03-26 13:42:27 | → | myme joins (~myme@2a01:799:d5e:5f00:4bf0:4daf:c921:3337) |
| 2026-03-26 13:42:43 | <mesaoptimizer> | I'm not going to ssh into a freebsd machine just to compile and run a haskell program lol |
| 2026-03-26 13:43:10 | × | Googulator78 quits (~Googulato@2a01-036d-0106-0364-757c-7b1f-aded-4ae9.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-26 13:43:23 | <int-e> | ...oh right, merijn could be wrong. I'm usually mean, why didn't I consider that option. (scnr) |
| 2026-03-26 13:43:40 | → | Googulator78 joins (~Googulato@2a01-036d-0106-0364-757c-7b1f-aded-4ae9.pool6.digikabel.hu) |
| 2026-03-26 13:45:05 | → | koala_man joins (~vidar@157.146.251.23.bc.googleusercontent.com) |
| 2026-03-26 13:45:05 | × | noctux quits (~noctux@user/noctux) (Read error: Connection reset by peer) |
| 2026-03-26 13:45:08 | → | tremon joins (~tremon@83.80.159.219) |
| 2026-03-26 13:47:29 | <mesaoptimizer> | "For example, on OSX, not passing -threaded results in pthreads being used:" https://github.com/ghc-proposals/ghc-proposals/pull/240 I could just use `-threaded` everywhere then |
| 2026-03-26 13:47:34 | × | bggd__ quits (~bgg@2a01:e0a:fd5:f510:aea0:e1c8:9dee:f851) (Ping timeout: 268 seconds) |
| 2026-03-26 13:50:44 | × | takuan quits (~takuan@d8D86B9E9.access.telenet.be) (Ping timeout: 245 seconds) |
| 2026-03-26 13:51:19 | × | koala_man quits (~vidar@157.146.251.23.bc.googleusercontent.com) (Ping timeout: 264 seconds) |
| 2026-03-26 13:52:31 | → | koala_man joins (~vidar@157.146.251.23.bc.googleusercontent.com) |
| 2026-03-26 13:53:24 | × | xff0x quits (~xff0x@2405:6580:b080:900:634f:4ad0:7953:dee2) (Ping timeout: 256 seconds) |
| 2026-03-26 13:55:46 | → | takuan joins (~takuan@d8D86B9E9.access.telenet.be) |
| 2026-03-26 13:56:59 | → | CloneOfNone_ joins (~CloneOfNo@user/CloneOfNone) |
| 2026-03-26 13:57:49 | × | CloneOfNone quits (~CloneOfNo@user/CloneOfNone) (Ping timeout: 268 seconds) |
| 2026-03-26 14:00:58 | → | xff0x joins (~xff0x@2405:6580:b080:900:634f:4ad0:7953:dee2) |
| 2026-03-26 14:01:17 | <mesaoptimizer> | no, you are right, it is better to do a `cabal clean && cabal build` instead, if you change the *.cabal file |
| 2026-03-26 14:01:37 | → | noctux joins (~noctux@user/noctux) |
| 2026-03-26 14:07:09 | × | mistivia quits (~mistivia@user/mistivia) (Remote host closed the connection) |
| 2026-03-26 14:07:25 | → | mistivia joins (~mistivia@user/mistivia) |
| 2026-03-26 14:09:43 | × | mistivia quits (~mistivia@user/mistivia) (Remote host closed the connection) |
| 2026-03-26 14:09:57 | → | mistivia joins (~mistivia@user/mistivia) |
| 2026-03-26 14:14:59 | × | mistivia quits (~mistivia@user/mistivia) (Ping timeout: 252 seconds) |
| 2026-03-26 14:15:04 | → | mistiv1a joins (~mistivia@user/mistivia) |
| 2026-03-26 14:18:27 | → | thresh_ joins (~thresh_@107-219-206-205.lightspeed.cicril.sbcglobal.net) |
| 2026-03-26 14:18:45 | × | thresh_ quits (~thresh_@107-219-206-205.lightspeed.cicril.sbcglobal.net) (Client Quit) |
| 2026-03-26 14:19:32 | <mesaoptimizer> | https://gitlab.haskell.org/ghc/ghc/-/issues/16126 still open |
| 2026-03-26 14:20:57 | <mesaoptimizer> | (doesn't seem that hard to do by myself tbh) |
| 2026-03-26 14:21:58 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 2026-03-26 14:23:16 | → | st_aldini joins (~Betterbir@2605:a601:a07c:7426:a9c5:df0c:3e0f:b451) |
| 2026-03-26 14:29:48 | × | jreicher quits (~joelr@user/jreicher) (Ping timeout: 255 seconds) |
| 2026-03-26 14:32:47 | × | koala_man quits (~vidar@157.146.251.23.bc.googleusercontent.com) (Ping timeout: 272 seconds) |
| 2026-03-26 14:34:20 | → | koala_man joins (~vidar@157.146.251.23.bc.googleusercontent.com) |
| 2026-03-26 14:39:42 | <Athas> | Did mkStdGen change recently? |
| 2026-03-26 14:39:53 | <Athas> | Well, "recently". At some point? |
| 2026-03-26 14:42:04 | xdej_ | is now known as xdej |
| 2026-03-26 14:44:41 | → | bggd_ joins (~bgg@2a01:e0a:fd5:f510:d391:e26c:d535:2a19) |
| 2026-03-26 14:50:37 | <int-e> | Changed how? The interface is the same; the underlying generator is different. |
| 2026-03-26 14:50:58 | <int-e> | comparing random 1.3.1 and 1.0.0.0 |
| 2026-03-26 14:51:42 | × | koala_man quits (~vidar@157.146.251.23.bc.googleusercontent.com) (Read error: Connection reset by peer) |
| 2026-03-26 14:52:55 | <int-e> | I guess StdGen is a bit larger now too, but it's opaque so shouldn't really matter. |
All times are in UTC.