07:50 <discocaml> <omnisci3nt> gdi trying to link with some C code is driving me batty. even though the generated `.so` and `.a` definitely have a symbol I keep getting `exception Dl.DL_error("_build/default/bin/main.exe: undefined symbol: ...")`

07:51 <dh`> why is it looking for the symbol in main.exe?

07:51 <discocaml> <omnisci3nt> I'm calling a function from within my main.ml

07:52 <discocaml> <omnisci3nt> that should execute a C function that I've wrapped in my `lib` with `foreign "blabla"` using Ctypes

07:52 <discocaml> <omnisci3nt> that should execute a C function that I've wrapped in my `lib` with `foreign "blabla" (type @-> returning void)` using Ctypes

07:53 <dh`> my question is: are you sure that the reason main.exe appears in the error message isn't that it's opening main.exe to look for the symbol instead of the .so file?

07:55 <discocaml> <omnisci3nt> It could be I guess, there's very little useful information in the dune docs for how to set this up

07:56 <discocaml> <omnisci3nt> I'd rather it be statically linked anyway but I've tried testing `(modes native)` and `(no_dynlink)` and it still wants both a `.a` *and* a `.so`

07:56 <dh`> I successfully managed to use Ctypes for something a while back but afaicr it just worked

07:57 <discocaml> <omnisci3nt> I have used it successfully before too but it seems like it was just magic or the way I set it up no longer works

07:57 <discocaml> <omnisci3nt> last time I used `(foreign_archives foo)` and just copied `libfoo.a` into my `bin` directory and it worked

07:57 <dh`> other things to check: make sure the symbol is tagged with the right visibility

07:57 <discocaml> <omnisci3nt> I tried that but alas

07:57 <discocaml> <omnisci3nt> last time (like 2 years ago?) I used `(foreign_archives foo)` and just copied `libfoo.a` into my `bin` directory and it worked

07:58 <dh`> also try opening libfoo.so from python and see if that works, will rule out it itself being bust

07:58 <discocaml> <omnisci3nt> yeah good idea.

07:59 <dh`> also try strace/ktrace/etc if you have that available, that will tell you which file it's actually opening among other useful things

07:59 <discocaml> <omnisci3nt> so using `nm` theyre showing `T` which should be publically exported symbols

08:00 <dh`> you also need to check the dynamic visibility

08:00 <dh`> e.g. with readelf -s

08:01 <discocaml> <omnisci3nt> FUNC GLOBAL DEFAULT

08:01 <dh`> hmm that should be ok

08:11 <discocaml> <omnisci3nt> I'm a bit confused because `foreign_archives` wants a `.a` and as far as I can tell by googling it means it gets statically lniked in, yet even if it compiles I get a DLOpen error when running `dune exec bin/main.exe` indicating its trying to dynlink to it. I think I need to set up a minimum replication repo and ask someone in #advanced-help or something.

08:14 <discocaml> <omnisci3nt> I guess this is a #dune issue actually

10:37 <discocaml> <omnisci3nt> Update: I just did some more googling and it seems like this persons dilemma and nice gentleman/woman/soul 's response is the solution: https://discuss.ocaml.org/t/dune-project-with-a-c-c-ctypes-foreign-defined-function/12696/2

10:37 <discocaml> <omnisci3nt> The OP observed that moving their `.c`, `.h` into the `/bin` folder and moving foreign declarations in main.ml worked ✅ . However, I don't think that's a particularly nice way of organising code.

10:37 <discocaml> <omnisci3nt>

10:37 <discocaml> <omnisci3nt> I wonder if given the fact that my old project worked when I had copied the `libfoo.a` into the `/bin` folder perhaps some functionality in either dune or ctypes-foreign has changed since then. If I can understand what's going on well enough I might try and make a template repository or a PR to the docs because it's kind of hidden knowledge on how to get it to work *unless* you already know how it works (the curse of a lot of OCaml tooling

10:37 <discocaml> <omnisci3nt>

10:37 <discocaml> <omnisci3nt> I will try the `dl.open` solution after dinner. It looks like using the stub generation or a different workflow is probably the better long-term play but that's an adventure for anther day...

10:37 <discocaml> <omnisci3nt> Update: I just did some more googling and it seems like this persons dilemma and nice gentleman/woman/soul 's response is the solution: https://discuss.ocaml.org/t/dune-project-with-a-c-c-ctypes-foreign-defined-function/12696/2

10:37 <discocaml> <omnisci3nt> The OP observed that moving their `.c`, `.h` into the `/bin` folder and moving foreign declarations in main.ml worked ✅ . However, I don't think that's a particularly nice way of organising code.

10:37 <discocaml> <omnisci3nt>

10:37 <discocaml> <omnisci3nt> I wonder if given the fact that my old project worked when I had copied the `libfoo.a` into the `/bin` folder perhaps some functionality in either dune or ctypes-foreign has changed since then. If I can understand what's going on well enough I might try and make a template repository or a PR to the docs because it's kind of hidden knowledge on how to get it to work *unless* you already know how it works (the curse of a lot of OCaml tooling

10:37 <discocaml> <omnisci3nt>

10:37 <discocaml> <omnisci3nt> I will try the `dl.open` solution after dinner! It looks like using the stub generation or a different workflow is probably the better long-term play but that's an adventure for anther day...

10:38 <discocaml> <omnisci3nt> Update: I just did some more googling and it seems like this persons dilemma and nice gentleman/woman/soul 's response is the solution: https://discuss.ocaml.org/t/dune-project-with-a-c-c-ctypes-foreign-defined-function/12696/2

10:38 <discocaml> <omnisci3nt> The OP observed that moving their `.c`, `.h` into the `/bin` folder and moving foreign declarations in main.ml worked ✅ . However, I don't think that's a particularly nice way of organising code.

10:38 <discocaml> <omnisci3nt>

10:38 <discocaml> <omnisci3nt> I wonder if given the fact that my old project worked when I had copied the `libfoo.a` into the `/bin` folder perhaps some functionality in either dune or ctypes-foreign has changed since then. If I can understand what's going on well enough I might try and make a template github repo or a PR to the docs because it's kind of hidden knowledge on how to get it to work *unless* you already know how it works (the curse of a lot of OCaml tooling

10:38 <discocaml> <omnisci3nt>

10:38 <discocaml> <omnisci3nt> I will try the `dl.open` solution after dinner! It looks like using the stub generation or a different workflow is probably the better long-term play but that's an adventure for anther day...

11:46 <discocaml> <froyo> type t = ..

11:46 <discocaml> <froyo> type t += private A

11:46 <discocaml> <froyo> type t += B

11:46 <discocaml> <froyo> this is cute

11:46 <discocaml> <froyo> private at constructor level

12:16 <discocaml> <_ggole> That's kinda nice

12:35 <discocaml> <tjammer> ```

12:35 <discocaml> <tjammer> ** Conflict (unexplainable) in state 143.

12:35 <discocaml> <tjammer> ** Token involved: Rpar

12:35 <discocaml> <tjammer> ** Please send your grammar to Menhir's developers.

12:35 <discocaml> <tjammer> ```

12:35 <discocaml> <tjammer> That's a new one

12:44 <discocaml> <0aty> that's funny

17:07 <discocaml> <gabyfle> Yow, I have some C files inside my project that is using dune for building. Does anyone knows if I can add `.c` and `.h` to be automatically formatted using the `dune fmt` command ?

17:07 <discocaml> <gabyfle> Like by using `clang-format` for example

20:12 <discocaml> <drakonnus> hm, there seems to be a typo in the description for riot, lighweight should be spelled lightweight

21:15 <discocaml> <tjammer> Apparently, you can add an action to the `@fmt` alias

21:15 <discocaml> <tjammer> https://dune.readthedocs.io/en/stable/reference/aliases.html#fmt

21:19 <discocaml> <gabyfle> Hooo, perfect this is insane thanks a lot ! That was exactly what I was looking for