Logs: liberachat/#haskell
| 2021-07-29 15:47:38 | → | pesada joins (~agua@2804:14c:8793:8e2f:3944:8017:7f63:8e28) |
| 2021-07-29 15:50:47 | → | tzh joins (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2021-07-29 15:51:23 | × | agua quits (~agua@2804:18:40:39f8:1:0:64c7:dff1) (Ping timeout: 252 seconds) |
| 2021-07-29 15:51:33 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:9d14:637c:254d:7940) (Quit: WeeChat 2.8) |
| 2021-07-29 15:53:07 | × | jpds quits (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 244 seconds) |
| 2021-07-29 15:53:23 | → | hnOsmium0001 joins (uid453710@id-453710.stonehaven.irccloud.com) |
| 2021-07-29 15:54:43 | → | motle joins (~motle@cpc103048-sgyl39-2-0-cust506.18-2.cable.virginm.net) |
| 2021-07-29 15:54:53 | <motle> | now it complains about; libcairo-gobject2 |
| 2021-07-29 15:55:09 | × | rmoe quits (~rmoe@c-71-236-207-44.hsd1.wa.comcast.net) (Ping timeout: 276 seconds) |
| 2021-07-29 15:55:10 | <motle> | so i guess that fixed the original gobject issue |
| 2021-07-29 15:55:38 | <motle> | ie pacman -S mingw-w64-x86_64-gobject-introspection |
| 2021-07-29 15:55:39 | <motle> | worked |
| 2021-07-29 15:55:43 | <kritzefitz> | motle, did you also `pacman -S mingw-w32-x86_64-gtk3`? |
| 2021-07-29 15:56:04 | <kritzefitz> | That should pull in the rest of the dependencies you need for gi-gtk. |
| 2021-07-29 15:56:28 | <kritzefitz> | (assuming you're using gt-gtk version 3.x and not 4.x) |
| 2021-07-29 15:56:31 | <motle> | error: target not found: mingw-w32-x86_64-gtk3 |
| 2021-07-29 15:56:54 | <kritzefitz> | err, mingw-w64-x86_64-gtk3 |
| 2021-07-29 15:57:08 | → | rmoe joins (~rmoe@c-71-236-207-44.hsd1.wa.comcast.net) |
| 2021-07-29 15:57:27 | <motle> | yah, that works |
| 2021-07-29 15:58:32 | <motle> | ahh, iv just got to get used to putting that prefix on the dependencies normally listed because of msys |
| 2021-07-29 15:59:22 | <motle> | still complains about 'libcairo-gobject-2.dll though |
| 2021-07-29 15:59:32 | → | drd joins (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-07-29 16:01:06 | × | justsomeguy quits (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.2) |
| 2021-07-29 16:01:10 | → | jpds joins (~jpds@gateway/tor-sasl/jpds) |
| 2021-07-29 16:01:29 | <kritzefitz> | That sounds like an issue with PATH |
| 2021-07-29 16:03:30 | <kritzefitz> | IIRC libcairo-gobject-2.dll should be in you msys environment inside /mingw64/bin or similar. Can you find it there? |
| 2021-07-29 16:03:49 | <motle> | i thought that before when it couldnt resolve gobject after gobject-introspect installed |
| 2021-07-29 16:04:41 | <kritzefitz> | Yeah, but that was a different error message. When stack complains about not finding a library, its usually because pkg-config can't even find the definition for the file. |
| 2021-07-29 16:05:10 | <kritzefitz> | If you get complaints about a .dll, pkg-config probably found the definition, but now the linker can't find the .dll one the PATH. |
| 2021-07-29 16:06:10 | × | fossdd quits (~fossdd@sourcehut/user/fossdd) (Ping timeout: 240 seconds) |
| 2021-07-29 16:06:12 | <motle> | the only dlls in the bin dir at ../.. in a msys prompt are prefixed by msys- |
| 2021-07-29 16:06:22 | <motle> | not the right ones |
| 2021-07-29 16:07:04 | <kritzefitz> | Are you sure ../.. is the same as /mingw64? |
| 2021-07-29 16:07:09 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-07-29 16:07:09 | → | fossdd joins (~fossdd@sourcehut/user/fossdd) |
| 2021-07-29 16:07:30 | × | wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 276 seconds) |
| 2021-07-29 16:08:04 | <motle> | C:\msys64\mingw64\bin has the gtk dll |
| 2021-07-29 16:08:49 | <kritzefitz> | That sounds about right, but... |
| 2021-07-29 16:08:59 | <motle> | aha, and the libcairo-gobject-2.dll |
| 2021-07-29 16:09:00 | <kritzefitz> | you're using a system installation of msys? |
| 2021-07-29 16:09:18 | <motle> | yeah, i installed stack within it not the other way round |
| 2021-07-29 16:09:20 | <motle> | using curl |
| 2021-07-29 16:09:53 | <kritzefitz> | Are you sure stack didn't install its own msys environment? It's not exactly straightforward to keep it from doing that. |
| 2021-07-29 16:11:22 | × | azeem quits (~azeem@dynamic-adsl-94-34-48-122.clienti.tiscali.it) (Ping timeout: 268 seconds) |
| 2021-07-29 16:11:41 | <motle> | im not sure if its just the windows installer that does that? |
| 2021-07-29 16:11:56 | <motle> | the curl option being for the unix environemnt |
| 2021-07-29 16:12:02 | <kritzefitz> | Nah, `stack setup` does it much like it does with GHC. |
| 2021-07-29 16:12:32 | <motle> | oh yeah fair, probably it has some msys dir somewhere like ghc |
| 2021-07-29 16:12:49 | <motle> | but if those are like sandboxed things... |
| 2021-07-29 16:12:54 | → | azeem joins (~azeem@176.201.11.200) |
| 2021-07-29 16:13:04 | <kritzefitz> | You can check the output of `stack path`. If the items of bin-path point to some obscure location, it's probably using the wrong msys environment. |
| 2021-07-29 16:13:18 | <maerwald[m]> | https://docs.haskellstack.org/en/stable/yaml_configuration/#skip-msys |
| 2021-07-29 16:13:34 | × | Cajun quits (~Cajun@ip98-163-211-112.no.no.cox.net) (Quit: Client closed) |
| 2021-07-29 16:13:59 | → | pavonia joins (~user@user/siracusa) |
| 2021-07-29 16:14:10 | <motle> | idk i added that directory and started a new msys session and it seems like its building ok now |
| 2021-07-29 16:14:20 | <motle> | to the PATH |
| 2021-07-29 16:14:44 | <motle> | cant tell if its some intermittent thing like to do with starting the new session |
| 2021-07-29 16:14:48 | → | neceve joins (~quassel@2a02:c7f:607e:d600:f762:20dd:304e:4b1f) |
| 2021-07-29 16:14:57 | <motle> | something like that could be quite confusing! |
| 2021-07-29 16:15:25 | <motle> | or running stack several times in a row changing something, idk |
| 2021-07-29 16:15:36 | <motle> | seems to be working now anyhow |
| 2021-07-29 16:15:38 | <kritzefitz> | If C:\msys64\mingw64\bin is on your path when you start stack, it will probably not remove it, so everything should still work. |
| 2021-07-29 16:16:04 | <Drew[m]> | What's fun is that installing msys yourself, installing it through chocolatey, installing it through chocolatey's haskell-dev package, installing it through GHCup and Stack installing it all put things in different locations and some of those methods don't clean up after themselves reliably in my experience. |
| 2021-07-29 16:16:59 | <kritzefitz> | But at least in the long run you should consider setting skip-msys and removing stack's installation of msys. Its great for your own sanity, as long as you remember to only call stack from the correct MSYS environment. |
| 2021-07-29 16:17:55 | <motle> | yeah, i keep refreshing windows too |
| 2021-07-29 16:18:14 | <kritzefitz> | Also: you have to remember to start it from the correct MSYS shell. Last time I installed MSYS, it installed three different “entry points“ (“MSYS2”, “MinGW32”, “MinGW64” IIRC) and each of them have different things on the PATH. |
| 2021-07-29 16:18:17 | <maerwald[m]> | Drew: GHCup should clean up properly after itself |
| 2021-07-29 16:18:42 | <maerwald[m]> | You don't need to start it from an msys2 shell |
| 2021-07-29 16:18:42 | <kritzefitz> | And by default all the mingw-w64 stuff is only on PATH if you start MinGW64. |
| 2021-07-29 16:19:09 | → | ikex1 joins (~ash@user/ikex) |
| 2021-07-29 16:19:26 | × | ikex quits (~ash@user/ikex) (Ping timeout: 252 seconds) |
| 2021-07-29 16:19:28 | <maerwald[m]> | You need these settings: skip-msys, extra-path, extra-include-dirs, extra-lib-dirs |
| 2021-07-29 16:19:46 | <kritzefitz> | Yeah, that should work too. |
| 2021-07-29 16:19:50 | ikex1 | is now known as ikex |
| 2021-07-29 16:20:01 | <maerwald[m]> | Then it works from powershell |
| 2021-07-29 16:20:08 | <maerwald[m]> | Adjusting PATH has odd side effects on windows |
| 2021-07-29 16:20:26 | <motle> | now it just dies without giving any reason |
| 2021-07-29 16:20:36 | <kritzefitz> | who dies? stack? |
| 2021-07-29 16:20:43 | <motle> | yeah |
| 2021-07-29 16:21:01 | × | dajoer quits (~david@user/gvx) (Quit: leaving) |
| 2021-07-29 16:21:05 | <kritzefitz> | What's the exit code? Maybe it's just finished? |
| 2021-07-29 16:21:13 | <motle> | Process exited with code: ExitFailure (-1073741515) |
| 2021-07-29 16:21:21 | <kritzefitz> | Huh. |
| 2021-07-29 16:21:39 | <maerwald[m]> | Try cabal, it doesn't install its own msys2 |
| 2021-07-29 16:21:41 | <kritzefitz> | Maybe try re-running? Sometimes the actual error message is buried inside other messages. |
| 2021-07-29 16:21:50 | → | hexfive joins (~eric@50.35.83.177) |
| 2021-07-29 16:21:56 | <motle> | idk how best to get cabal on a clean msys install |
| 2021-07-29 16:22:05 | × | hexfive quits (~eric@50.35.83.177) (Client Quit) |
| 2021-07-29 16:22:08 | × | Toast52 quits (~Toast52@151.192.167.120) (Quit: Leaving) |
| 2021-07-29 16:23:01 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-07-29 16:23:32 | <kritzefitz> | motle, you might need to set XDG_DATA_DIRS=/mingw64/share in the environment. But if that's the case there should be an error message hidden somewhere. |
| 2021-07-29 16:24:10 | × | fossdd quits (~fossdd@sourcehut/user/fossdd) (Ping timeout: 240 seconds) |
| 2021-07-29 16:24:12 | <kritzefitz> | e.g. `XDG_DATA_DIRS=/mingw64/share stack ...` |
| 2021-07-29 16:24:59 | → | fossdd joins (~fossdd@sourcehut/user/fossdd) |
| 2021-07-29 16:25:08 | <maerwald[m]> | motle: can install cabal with ghcup |
| 2021-07-29 16:25:13 | <zzz> | wait, importing a module inflates the binary with the full module? seems trivial to statically check what's not used and strip it away, no? |
| 2021-07-29 16:25:32 | <maerwald[m]> | It asks for pre-existent msys2 |
| 2021-07-29 16:27:03 | <maerwald[m]> | Don't run stuff from within msys2 |
| 2021-07-29 16:27:52 | → | superstar64 joins (~superstar@2600:1700:ed80:50a0:d250:99ff:fe2c:53c4) |
| 2021-07-29 16:28:25 | <lechner> | Hi, does a ! strictness indicator in a JSON data type definition make the parsing more strict or more relaxed, please? |
All times are in UTC.