Yes, because the opam package that is distributing bindings to the library is not responsible for distribution the actual library. In fact, there are two approaches. You can distribute only the bindings code and assume that the bound library is linked by the user code, or you can statically link the bound library and distributed in one big cmxs file.
Before dune, the build systems were able to notice in the META file that an OCaml library has an extra dependency on a foreign shared library and automatically pass the corresponding command-line options during the linking phase. In addition, cma and cmxa files (OCaml library archives) contain information about the libraries that has to be linked and about the C compiler options that has to be used during linking via the
-ccopt command-line options.
Unfortunately, the library that you’re using is doing neither so it is you task to specify the extra dependencies1. In general you can use the
flags) stanza, e.g.,
(link_flags -cclib -lfoo) to link the
libfoo.so library to your library (executable). But in case of
ocaml_mammut I think you would need to add much more than that, e.g., this is what I think you need to add,
-cclib -lstdc++ -cclib -lraplcap-msr -cclib -lsmartgauge -cclib -lusb-1.0 -cclib -lmammut
E.g., if you’re building a binary that uses
ocaml_mamut then add to the executable stanza the following line,
(flags (:standard -w -49 -cclib -lstdc++ -cclib -lraplcap-msr -cclib -lsmartgauge -cclib -lusb-1.0 -cclib -lmammut))
1) when we link with
lm we don’t have to specify their dependencies as well, it is the responsibility of the linked library to specify their dependencies. So
mamut_ocaml shall pass those options as
link_flags when they define the
mammut library. If they would do this, then you we wouldn’t need to write those options in the code that use their library. I would suggest you to open an issue or suggest a PR with the fix.