| 2025-05-14 00:02:04 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) |
| 2025-05-14 00:03:29 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Read error: Connection reset by peer) |
| 2025-05-14 00:03:43 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2025-05-14 00:04:24 +0200 | <tomsmeding> | xeno11: "collect2: fatal error: cannot find ‘ld’" |
| 2025-05-14 00:04:49 +0200 | <tomsmeding> | xeno11: I suspect that this is the actual error, and that cabal just misinterprets failure of gcc as something completely unrelated (and wrong) |
| 2025-05-14 00:05:02 +0200 | <tomsmeding> | do you have a working gcc and ld? :p |
| 2025-05-14 00:05:16 +0200 | <int-e> | note that ghc passes '-fuse-ld=gold' there |
| 2025-05-14 00:05:25 +0200 | esnos | (~user@194.29.137.22) |
| 2025-05-14 00:05:36 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-05-14 00:05:47 +0200 | <tomsmeding> | despite the only earlier occurrence of the string "gold" in that log being "Cannot find ld.gold on the path" |
| 2025-05-14 00:06:59 +0200 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-05-14 00:06:59 +0200 | <int-e> | ghc --info | grep gold |
| 2025-05-14 00:07:05 +0200 | <int-e> | is likely to find gold ;-) |
| 2025-05-14 00:08:44 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-56.bstnma.fios.verizon.net) (Ping timeout: 245 seconds) |
| 2025-05-14 00:09:08 +0200 | <int-e> | it's funny (and annoying) though that cabal diagnoses this as a missing C library |
| 2025-05-14 00:09:52 +0200 | <tomsmeding> | I guess cabal assumes that gcc always succeeds unless there was a linker error, and a linker error "always" means that one of the C libraries wasn't available |
| 2025-05-14 00:10:28 +0200 | <tomsmeding> | to be fair I don't blame cabal for not trying to parse linker errors, but it would do well, perhaps, to pass on the error to the user instead of waiting until -v3 (not even -v, -v3!) to display it |
| 2025-05-14 00:11:14 +0200 | Sgeo | (~Sgeo@user/sgeo) (Ping timeout: 245 seconds) |
| 2025-05-14 00:11:31 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-05-14 00:12:18 +0200 | tomsmeding | is afk |
| 2025-05-14 00:12:48 +0200 | esnos | (~user@194.29.137.22) (Remote host closed the connection) |
| 2025-05-14 00:13:14 +0200 | zarek | (~user@194.29.137.22) |
| 2025-05-14 00:14:31 +0200 | <zarek> | Hi, I already done beginner books about haskell and now I want to do something with Cardano, do you know how can I start? |
| 2025-05-14 00:15:24 +0200 | <zarek> | And do I need to learn about some more abstractions? I know everything up to state monads, but I don't know gadts or arrows |
| 2025-05-14 00:16:48 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 00:21:37 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-05-14 00:26:52 +0200 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 265 seconds) |
| 2025-05-14 00:31:07 +0200 | pavonia | (~user@user/siracusa) siracusa |
| 2025-05-14 00:31:39 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) (Read error: Connection reset by peer) |
| 2025-05-14 00:32:36 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 00:33:50 +0200 | sabathan2 | (~sabathan@amarseille-159-1-12-107.w86-203.abo.wanadoo.fr) |
| 2025-05-14 00:35:17 +0200 | <EvanR> | zarek, dunno about cardano but would you be interested in game programming |
| 2025-05-14 00:35:30 +0200 | <EvanR> | it is surely to make you collide with more abstractions |
| 2025-05-14 00:37:02 +0200 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-05-14 00:37:37 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-05-14 00:39:47 +0200 | <zarek> | EvanR: Yes, I'm also interested |
| 2025-05-14 00:40:11 +0200 | <sim590> | int-e, tomsmeding: seems like ld.gold is deprecated apprently. But cabal still uses it by default? Shouldn't it stop to use it at some point? |
| 2025-05-14 00:41:19 +0200 | <int-e> | sim590: my guess is that using ld.gold is baked into the ghc binary you're using. that's what the ghc --info comment was about |
| 2025-05-14 00:42:23 +0200 | <int-e> | Or, technically, not the binary but the `settings` files it ships with. So if you feel adventerous you can change that. |
| 2025-05-14 00:42:30 +0200 | <zarek> | EvanR: Would you recommend some library for it or blog post/book about programming game in haskell? I only today saw this video about programming game in haskell in haskell https://www.youtube.com/watch?v=1MNTerD8IuI&list=PLcGKfGEEONaCyiY7-IV6boavjCIG7q1vd& |
| 2025-05-14 00:42:54 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-05-14 00:43:06 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 272 seconds) |
| 2025-05-14 00:43:26 +0200 | <sim590> | int-e: So, it's something that would be likely to change by itself if GHC was upgraded, right? |
| 2025-05-14 00:43:58 +0200 | <EvanR> | there is #haskell-game and HaskellGameDev discord, with its own links and references, though things have slowed down in the last few months |
| 2025-05-14 00:44:09 +0200 | <int-e> | sim590: maybe. afaics you're using ghc-up so you're relying on that upstream's build configuration |
| 2025-05-14 00:44:20 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2025-05-14 00:44:25 +0200 | <sim590> | int-e: yep. |
| 2025-05-14 00:44:32 +0200 | <zarek> | sim590: by any chance did you install ghc by pacman in arch linux? If yes, thank I suggest nuke everything and install everything from curl link |
| 2025-05-14 00:44:57 +0200 | <int-e> | sim590: you can override the linker in your cabal config, that's probably the easier route for making progress right now |
| 2025-05-14 00:45:28 +0200 | <int-e> | zarek: ironically that would likely use a linker that's actually installed |
| 2025-05-14 00:45:44 +0200 | <int-e> | (the trouble is elsewhere) |
| 2025-05-14 00:45:56 +0200 | <EvanR> | forwarding that link to the other channel looks interesting |
| 2025-05-14 00:46:15 +0200 | <sim590> | zarek: One of my machines I use have arch and the other has debian. |
| 2025-05-14 00:46:27 +0200 | <sim590> | But I actually didn't have any issue on Arch. |
| 2025-05-14 00:47:06 +0200 | <sim590> | I only got issues with debian when dist-upgrading (same as xeno11). I guess that the `binutils-gold` was removed when we did a `dist-upgrade` and that confused everything. |
| 2025-05-14 00:47:33 +0200 | <int-e> | zarek: it's irrelevant anyway: --with-ghc=/home/xkappel/.ghcup/bin/ghc |
| 2025-05-14 00:48:06 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-05-14 00:48:23 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 00:49:36 +0200 | <zarek> | I remember this is how I solved my problems with ghcup and rest of haskell, but if this isn't solution than I don't know |
| 2025-05-14 00:52:00 +0200 | <haskellbridge> | <sm> hi zarek, cardano has lots of getting started and learning haskell resources doesn't it; we don't know them all here |
| 2025-05-14 00:52:28 +0200 | <haskellbridge> | <sm> and, welcome |
| 2025-05-14 00:52:30 +0200 | <int-e> | sim590: Anyway. The path of least resistance is to install ld.gold (it may be deprecated but it works as a linker). The next easiest idea is to tweak, hmm, ld-location I suppose in ~/.cabal/config. After that it's editing the settings file inside the ghc distribution and after that it's finding a "better" ghc package. |
| 2025-05-14 00:52:55 +0200 | <int-e> | glhf |
| 2025-05-14 00:53:02 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-05-14 00:53:54 +0200 | <sim590> | int-e: isn't it possible to just pass an option to GHC to force not using ld.gold, but stick to plain ld ? |
| 2025-05-14 00:54:25 +0200 | <sim590> | So we could just protect ourselves with an option in a `cabal.project` file or literally inside the cabal file. |
| 2025-05-14 00:55:01 +0200 | <int-e> | sim590: which is what cabal would do if you instructed it accordingly, and doing it in the config file feels less painful than doing it on every invokation |
| 2025-05-14 00:55:44 +0200 | <sim590> | int-e: It would not be in the invocation, but in a config file in the project repo. |
| 2025-05-14 00:56:03 +0200 | <sim590> | I thought ourproject.cabal in the `ghc-options:` section. |
| 2025-05-14 00:56:06 +0200 | <int-e> | it's a local configuration so putting it into the project is wrong |
| 2025-05-14 00:57:11 +0200 | <int-e> | (and you'll run into this with *every* haskell project as long as you use this particular ghc, and probably other versions shipped with ghc-up too) |
| 2025-05-14 00:57:11 +0200 | <sim590> | At least, we can put it in `cabal.project`, so it's not shipped anywhere. |
| 2025-05-14 00:57:35 +0200 | halloy5771 | (~halloy577@205.175.106.139) (Read error: Connection reset by peer) |
| 2025-05-14 00:57:51 +0200 | <int-e> | it really is a thing that pretty much unambiguously belongs in ~/.cabal/config |
| 2025-05-14 00:58:03 +0200 | <int-e> | and not in some project-related file |
| 2025-05-14 00:59:55 +0200 | <geekosaur> | it should probably go in ghc's settings file fwiw |
| 2025-05-14 01:00:18 +0200 | <int-e> | sure but then you're bound to clash with ghc-up eventually |
| 2025-05-14 01:00:31 +0200 | <xeno11> | tomsmeding:,int-e: thanks for the help, much appreciated |
| 2025-05-14 01:00:58 +0200 | <xeno11> | tomsmeding: , int-e: * |
| 2025-05-14 01:03:58 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 01:05:11 +0200 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-05-14 01:07:49 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 276 seconds) |
| 2025-05-14 01:07:50 +0200 | ljdarj1 | ljdarj |
| 2025-05-14 01:08:38 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-05-14 01:12:39 +0200 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-05-14 01:13:25 +0200 | jason_davidson | (~jason.dav@user/jason-davidson:57402) jason_davidson |
| 2025-05-14 01:17:56 +0200 | Square2 | (~Square@user/square) (Ping timeout: 272 seconds) |
| 2025-05-14 01:19:45 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 01:20:34 +0200 | sprotte24 | (~sprotte24@p200300d16f210300c438dc587dfe80f8.dip0.t-ipconnect.de) (Quit: Leaving) |
| 2025-05-14 01:23:03 +0200 | Guest35 | (~Guest35@2800:bf0:177:7c0:3c92:6af8:5ab1:4e0a) |
| 2025-05-14 01:24:23 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-05-14 01:25:28 +0200 | Guest35 | (~Guest35@2800:bf0:177:7c0:3c92:6af8:5ab1:4e0a) (Client Quit) |
| 2025-05-14 01:29:38 +0200 | <monochrom> | Hrm, ld.gold is going away? That's a pity. If you reinstall GHC, the install script can pick up the fact that you don't have ld.gold, then initialize its settings file accordingly. |
| 2025-05-14 01:30:51 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2025-05-14 01:35:08 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 01:37:25 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2025-05-14 01:37:52 +0200 | jespada | (~jespada@r179-25-18-201.dialup.adsl.anteldata.net.uy) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-05-14 01:38:19 +0200 | halloy5771 | (~halloy577@205.175.106.139) |
| 2025-05-14 01:38:36 +0200 | halloy5771 | (~halloy577@205.175.106.139) (Client Quit) |
| 2025-05-14 01:41:39 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-05-14 01:42:09 +0200 | acidjnk | (~acidjnk@p200300d6e71c4f19710480a6a0bd753e.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
| 2025-05-14 01:45:58 +0200 | emmanuelux | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-05-14 01:46:45 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-05-14 01:47:23 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 244 seconds) |
| 2025-05-14 01:53:11 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 01:58:13 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-05-14 02:06:58 +0200 | preflex | (~preflex@user/mauke/bot/preflex) (Ping timeout: 276 seconds) |
| 2025-05-14 02:07:16 +0200 | preflex | (~preflex@user/mauke/bot/preflex) preflex |
| 2025-05-14 02:07:17 +0200 | acidsys | (~crameleon@openSUSE/member/crameleon) (Ping timeout: 248 seconds) |
| 2025-05-14 02:08:03 +0200 | bionade24 | (~quassel@2a03:4000:33:45b::1) (Ping timeout: 244 seconds) |
| 2025-05-14 02:08:06 +0200 | acidsys | (~crameleon@openSUSE/member/crameleon) crameleon |
| 2025-05-14 02:08:28 +0200 | bionade24 | (~quassel@server2.oscloud.info) bionade24 |
| 2025-05-14 02:08:57 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 02:09:20 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 265 seconds) |
| 2025-05-14 02:09:53 +0200 | j1n37 | (~j1n37@user/j1n37) j1n37 |
| 2025-05-14 02:09:57 +0200 | j1n37- | (~j1n37@user/j1n37) (Ping timeout: 248 seconds) |
| 2025-05-14 02:12:15 +0200 | xeno11 | (~xeno11@c-69-140-170-168.hsd1.de.comcast.net) (Quit: Client closed) |
| 2025-05-14 02:13:37 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-05-14 02:15:55 +0200 | ttybitnik | (~ttybitnik@user/wolper) (Quit: Fading out...) |
| 2025-05-14 02:16:09 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 02:20:15 +0200 | zarek | (~user@194.29.137.22) (ERC 5.6.0.30.1 (IRC client for GNU Emacs 30.1)) |
| 2025-05-14 02:21:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-14 02:23:20 +0200 | droideqa | (uid499291@user/droideqa) droideqa |
| 2025-05-14 02:25:13 +0200 | mange | (~user@user/mange) mange |
| 2025-05-14 02:31:49 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 02:37:31 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-14 02:38:27 +0200 | servo | (~servo@c-73-128-187-52.hsd1.va.comcast.net) |
| 2025-05-14 02:39:19 +0200 | sajenim | (~sajenim@user/sajenim) sajenim |
| 2025-05-14 02:43:53 +0200 | servo | (~servo@c-73-128-187-52.hsd1.va.comcast.net) (Quit: Client closed) |
| 2025-05-14 02:47:38 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 02:53:07 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2025-05-14 02:55:15 +0200 | xff0x | (~xff0x@2405:6580:b080:900:fab1:2ba7:ff3c:d0fc) (Ping timeout: 265 seconds) |
| 2025-05-14 02:55:24 +0200 | vsv | (~vsv@c-73-128-187-52.hsd1.va.comcast.net) |
| 2025-05-14 03:00:06 +0200 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-05-14 03:00:36 +0200 | vsv20 | (~vsv@c-73-128-187-52.hsd1.va.comcast.net) |
| 2025-05-14 03:00:57 +0200 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-05-14 03:03:25 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 03:08:17 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-05-14 03:10:36 +0200 | halloy5771 | (~halloy577@71-212-10-118.tukw.qwest.net) |
| 2025-05-14 03:11:40 +0200 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
| 2025-05-14 03:14:47 +0200 | <sim590> | monochrom: really? Well, this is the curl installation way, but will ghcup do that also? I guess not as int-e suggested otherwise. |
| 2025-05-14 03:17:44 +0200 | <sim590> | int-e: my main goal though is to make it so that any developer that wants to work on my project doesn't have to ask himself the same thing we asked ourselves just because ld.gold missing is silently reported in some fat log that you are gonna have trouble find at first. So, that's why I say it belongs in the repo since I am at the very least sure that `ld` should exist on the platform as it always |
| 2025-05-14 03:17:46 +0200 | <sim590> | had. I've been using Linux for almost 15 years and I've never heard of `ld.gold`, so I think that the safest is to force `ld` for all developers who touch the project. |
| 2025-05-14 03:19:13 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 03:26:11 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-05-14 03:37:16 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 03:41:52 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-05-14 03:49:17 +0200 | <monochrom> | That road leads to docker images. Then you can full control of what runs on other people's computers. |
| 2025-05-14 03:49:43 +0200 | <monochrom> | Hell, s/what runs on// |
| 2025-05-14 03:50:45 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-05-14 03:50:56 +0200 | <sim590> | I don't need to go there just yet... :) |
| 2025-05-14 03:51:35 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 252 seconds) |
| 2025-05-14 03:51:58 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
| 2025-05-14 03:53:03 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-05-14 03:54:50 +0200 | <monochrom> | GHC is about the only compiler that generates code that spams the linker to the point that ld.gnu is noticeably too slow and we need the asymptotically faster ld.gold. So it is natural that outside the Haskell community no one needs to talk about it. |
| 2025-05-14 03:58:20 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |