Newest at the top
2025-10-23 20:41:25 +0200 | jmcantrell_ | (~weechat@user/jmcantrell) (Ping timeout: 264 seconds) |
2025-10-23 20:40:22 +0200 | karenw | (~karenw@user/karenw) karenw |
2025-10-23 20:35:46 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
2025-10-23 20:33:48 +0200 | numberella | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 244 seconds) |
2025-10-23 20:32:33 +0200 | numberel_ | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
2025-10-23 20:32:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
2025-10-23 20:28:01 +0200 | <chromoblob> | what was wrong with Haskell Platform? why was it replaced with Ghcup? |
2025-10-23 20:27:18 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-10-23 20:26:58 +0200 | lill | (~lill@bras-base-gmlyon2002w-grc-37-74-12-9-150.dsl.bell.ca) (Quit: WeeChat 4.7.1) |
2025-10-23 20:24:47 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) (Ping timeout: 250 seconds) |
2025-10-23 20:24:16 +0200 | arandombit | (~arandombi@user/arandombit) arandombit |
2025-10-23 20:21:38 +0200 | arandombit | (~arandombi@user/arandombit) (Remote host closed the connection) |
2025-10-23 20:19:07 +0200 | lill | (~lill@bras-base-gmlyon2002w-grc-37-74-12-9-150.dsl.bell.ca) |
2025-10-23 20:18:16 +0200 | lill | (~lill@bras-base-gmlyon2002w-grc-37-74-12-9-150.dsl.bell.ca) (Quit: leaving) |
2025-10-23 20:17:58 +0200 | LainIwakura | (~LainIwaku@user/LainIwakura) LainIwakura |
2025-10-23 20:17:45 +0200 | tromp | (~textual@2001:1c00:3487:1b00:cd8f:ea15:2cfa:e4a8) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2025-10-23 20:16:28 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
2025-10-23 20:16:13 +0200 | Googulator27 | (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) |
2025-10-23 20:15:58 +0200 | Googulator27 | (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) (Quit: Client closed) |
2025-10-23 20:11:51 +0200 | lill | (~lill@bras-base-gmlyon2002w-grc-37-74-12-9-150.dsl.bell.ca) |
2025-10-23 20:11:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-10-23 20:10:51 +0200 | target_i | (~target_i@user/target-i/x-6023099) target_i |
2025-10-23 20:09:25 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-10-23 20:04:47 +0200 | ft | (~ft@p4fc2aaeb.dip0.t-ipconnect.de) ft |
2025-10-23 20:02:56 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-10-23 20:01:20 +0200 | williu5 | (~williu5@user/williu5) (Quit: WeeChat 4.1.1) |
2025-10-23 19:52:13 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
2025-10-23 19:51:55 +0200 | <EvanR> | I'm also linked against the vdso |
2025-10-23 19:51:44 +0200 | deptype_ | (~deptype@124.123.188.12) (Remote host closed the connection) |
2025-10-23 19:51:44 +0200 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
2025-10-23 19:47:18 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-10-23 19:44:20 +0200 | <haskellbridge> | <Morj> Anyway, to the original question of statically linking: I don't have a complete answer, but look into the docs of ghc options «-static -optl-static -staticlib» |
2025-10-23 19:44:08 +0200 | <EvanR> | and redistribute |
2025-10-23 19:43:59 +0200 | <EvanR> | they can just recompile if things change |
2025-10-23 19:43:26 +0200 | <haskellbridge> | <Morj> Go world went with rewriting the world, and it sort-of works for them. They produce completely static binaries, and it's very convenient to use |
2025-10-23 19:43:10 +0200 | <EvanR> | it's the ultimate form of "never use dependencies" |
2025-10-23 19:42:58 +0200 | <EvanR> | and it's a pain in the ass |
2025-10-23 19:42:43 +0200 | <haskellbridge> | <Morj> If you write from scratch targeting linux without libc, you can fear no breakage. Unfortunately, you 1) usually don't have enough time for that, 2) want to integrate with the system, and some integrations require using shared libraries. One example of that is DNS resolution |
2025-10-23 19:42:13 +0200 | <EvanR> | alternative libc implementations seem to be about memory usage, but you're on some random persons linux with a spinning cube desktop |
2025-10-23 19:41:31 +0200 | <EvanR> | there's a reason there's a standard API, so it should work with any implementation |
2025-10-23 19:41:29 +0200 | <haskellbridge> | <Morj> As I say, the syscalls are incredibly stable. You won't see a breakage in /them/ |
2025-10-23 19:41:07 +0200 | <chromoblob> | if only Linux shipped a standard libc... |
2025-10-23 19:40:45 +0200 | <chromoblob> | no, glibc is not Linux, it is GNU |
2025-10-23 19:40:41 +0200 | <EvanR> | that's usually how I've seen it done |
2025-10-23 19:40:38 +0200 | <haskellbridge> | <Morj> I think on BSDs they do just that, except it's another libc |
2025-10-23 19:40:21 +0200 | <haskellbridge> | <Morj> In theory if everyone was a good citizen, you could dynamically link to glibc and have no problems |
2025-10-23 19:39:56 +0200 | <EvanR> | you traded "philosophical problems" for actual problems |
2025-10-23 19:39:47 +0200 | <haskellbridge> | <Morj> Yeah, except for little unstable parts that someone will surely get their little library fingers in =) |
2025-10-23 19:39:42 +0200 | <chromoblob> | note, A*B*I |
2025-10-23 19:39:28 +0200 | <EvanR> | but here we are |