00:03 <d_bot> <Kate> kronicmage: `opam upgrade` should do the job I believe

00:05 <d_bot> <Kate> though could you open an issue on the opam bugtracker? It feels like it should be the case by default

00:26 <d_bot> <Et7f3> I found the list https://github.com/ocaml-community/utop/blob/master/src/top/dune#L13-L15

00:28 <d_bot> <Et7f3> Ah no it is the opposite: in toplevel/expunge.ml we read it is `<names of modules to keep>`

00:28 <d_bot> <Et7f3> so one lib used by utop expect those showed

00:32 <d_bot> <Et7f3> Ah no expunge is also a binary in utop https://github.com/ocaml-community/utop/blob/master/src/top/expunge/expunge.ml#L72 😭 why they use the same name

00:34 <d_bot> <Et7f3> it does some cleanup and call real expunge

12:58 <d_bot> <Kate> kronicmage: Actually I just tried and your issue is fixed in opam 2.1

13:05 <d_bot> <NULL> What would the issue be ? Because I have the same error feed when the invariant is "ocaml-system=4.11.1" and pacman's OCaml is at version 4.12.0, when I try "opam install ocaml-lsp-server". Or do you simply mean that opam 2.1 allows more easily to change the invariant to reflect the new version of the distribution's compiler ?

13:18 <d_bot> <Kate> mh no, opam 2.1 does it automatically from what I tested

13:18 <d_bot> <Kate> @NULL what version of opam do you have?

13:19 <d_bot> <Kate> what does `opam switch invariant` give you?

13:29 <d_bot> <NULL> `opam 2.1.1`. `["ocaml-system" {= "4.11.1"}]`

13:31 <d_bot> <NULL> `opam upgrade` prompts to `--fixup`, trying to install a package doesn't

13:34 <d_bot> <NULL> Or should opam automatically set any `ocaml-system` invariant not to mention any version (that's what it was when I looked at it now but I thought I might have changed it)

13:36 <d_bot> <NULL> In this case, it automatically schedules the compiler upgrade on installing a package (and on global upgrade I presume)

14:07 <d_bot> <andreypopp> I have a setup where I use (1) cstubs generation to bind to C code and then (2) inverted C stubs to expose some functions to C code. The problem is that when I compile a generator for (2) it tries to link (1) as the functions I'm trying to expose use APIs from (1). It fails understandably on undefined references to externs...

14:08 <d_bot> <andreypopp> Is there any way to separate inverted cstubs definitions from implementations so I don't try to link stuff which is only executable at runtime into generator?

14:14 <d_bot> <andreypopp> as a workaround I know I can pass `-ccopt -Wl,--unresolved-symbols=ignore-in-object-files` when building a generator for (2) but wondering if there's some kind of blessed way

14:30 <d_bot> <cemerick> hah, yup

14:30 <d_bot> <cemerick> maybe rub some CNNs on it

15:28 <d_bot> <Kate> @NULL yeah exactly. If your invariant is set to 4.11.1 opam can’t really do much about it automatically. The switch could have been created with e.g. `opam switch create system ocaml-system` and this would have set the invariant automatically to "whatever the version on the system is". You can always set it after the fact with `opam switch set-invariant ocaml-system`

15:29 <d_bot> <NULL> And "system" switches before 2.1 would not fix their version in the invariant during the update ?

15:33 <d_bot> <Kate> i don’t think so. The invariant system was introduced in 2.1. Before that it was just all linked to a unique compiler package set at a specific version

15:34 <d_bot> <NULL> So 2.1 allows for good "system" switches that don't track the version in the invariant, but you have to set the good invariant (so remove the specific version of `ocaml-system`) manually, right ?

15:35 <d_bot> <Kate> yep, exactly

15:35 <d_bot> <NULL> That is what kronicmage has to do then

15:36 <d_bot> <NULL> `opam switch set-invariant ocaml-system`