-output-obj for dynamic libraries?

[db4]

Not sure if this is a feature request or just a question. I need to create a standalone OCaml plugin that is dynamically loaded by a main program in C. That's done by ocamlopt -output-obj -o plugin.so ... on Linux and ocamlopt -output-obj -o plugin.dll ... on Windows. Does Dune support such targets?

[nojb]

Yes, use (modes shared_object) in an (executable) stanza. https://dune.readthedocs.io/en/stable/dune-files.html#linking-modes

[db4]

@nojb, thanks for your advice.
Yes, it works for native code DLLs, but how do the same for bytecode? In other words, how to make Dune run ocamlc -output-obj -o plugin.so ... command? Note that I also need C foreign stubs for that DLL.

[db4]

Ah, I didn't know that ocamldebug was able to debug bytecode that has been built into a shared object, that's interesting.

Yes, it can (could?). I added this feature to OCaml about fifteen years ago :) The debug info is placed into a separate .cds file. BTW, I see in the changelog your:

- #10371: no longer generatd useless `.cds` file when using
  `-output-complete-exe`.
  (Nicolás Ojeda Bär, review by David Allsopp)

why useless?

Coming back to your question, as I mentioned before I believe the only way to obtain a DLL built out of bytecode at the moment is by "hiding" ocamlopt from Dune (eg by temporarily renaming it) when you trigger your build.

I see. Not very convenient, but better than nothing...

[nojb]

why useless?

Good question :) I don't remember the details, I will need to go back and look at the code, but perhaps the support for .cds files was not working or perhaps I (or someone else) was under the impression that this was not used at all in the wild... If this feature was mistakingly removed, it should be added back.

[db4]

OK, -output-obj still generates .cds while -output-complete-obj doesn't. It could make sense. Is it currently impossible to force Dune to use the former for shared_object?

[nojb]

Is it currently impossible to force Dune to use the former for shared_object?

Indeed, as far as I know, it is not possible using the built-in rules. But you could try a workaround by building a library and then finishing with a user-defined rule, something like:

(libary
 (name lib)
 ...)

(rule
 (target foo%{ext_dll}
 (action
  (run ocamlc -o %{target} -output-obj %{dep:lib.cma})))

(this is off the top of my head, so not tested)

[nojb]

I see. Not very convenient, but better than nothing...

Actually, I misremembered: it is possible to build a shared_object out of bytecode by using (modes (byte shared_object)), sorry for the confusion (this is explained in the manual: https://dune.readthedocs.io/en/latest/dune-files.html#linking-modes

[db4]

Actually, I misremembered: it is possible to build a shared_object out of bytecode by using (modes (byte shared_object)), sorry for the confusion (this is explained in the manual: https://dune.readthedocs.io/en/latest/dune-files.html#linking-modes

Not exactly. (byte shared_object) doesn't allow to link C stubs:

74 | (executable
75 |  (name xxx)
76 |  (modes (byte shared_object))
....
95 |  )
96 |  (flags)
97 | )
Error: Pure bytecode executables cannot contain foreign stubs.
Hint: If you only need to build a native executable use "(modes exe)".

So I'll try to create an additional rule as you suggested. Thanks a lot again!

[db4]

Interestingly, (modes shared_object) works with ocamlc for an executable with C stubs (when ocamlopt is not available). Maybe the error above is just a bug?

[nojb]

Possibly; I opened #7800