Writing a wrapper stub to something dynamic, where static linking would produce huge executables?

Ecosystem
, ,
1

What I have:

  • dune
  • opam
  • opencv (headers in /usr/include, and shared objects)
  • a cxx stub
  • main project in ocaml

What I want:

  • to build the project with dune

The problem:
I can’t seem to find in dune docs the way to get this setup working. The compiler rightfully complains at the linking stage saying that all my opencv-related references in the object file are undefined.
As far as I am aware, OCaml only links statically (will have to use dlopen wrappers otherwise), but I was wondering if it’s possible to link dynamically with the stub compiler then feed the object file to OCaml compiler…

What’s the tried and true way to approach this situation anyway?

2

Silly question: Do you pass right C libraries on linking stage? Something like -cclib -lopencv` or something?

3

First step: can you compile with a series of shell commands? I mean, ignore dune and just see if you can get it to link and run on the commandline. Then it’s a question of teaching dune to do the same thing. Which might be messy, but at least you’ll know that your program -does- build and run.

4

I wasn’t aware of where to specify this in the build pipeline but yes! cclib and ccopt works perfectly. I wouldn’t have guessed. that’s something new to learn about I guess.

5

I’m guessing I’ll be passing cclib to the compiler flags via dune
should be less painful than a rule/run stanza

6

I still wonder if there’s a usual workflow for this kind of projects though. Especially when packaging I see *-config packages which do pkg-config checks with opam

7

Usually, it is done using so-called configurator

1 Like
8

… with OCaml libraries, yes, but C libraries used through C/OCaml bindings can, and usually are, dynamically linked. It’s the C linker that handles this, mostly transparently.

When -cclib -lopencv is given to ocamlopt, directly or via an OCaml library, the C linker gets -lopencv and finds out whether to use libopencv.so or libopencv.a.

9

I see. I experimented a little with -cclib and -ccopt and I find (with -verbose) that the extra flags I supply are passed to the same commandline either way.
The help text distinguishes between the two by mentioning that -cclib is for the linking stage only, but their behaviour appears to be synonymous to me. Is there a subtle difference of sorts?

10

thanks for the mention! Looking at it now and it looks like a good idea to integrate with the build process instead of manually passing flags.

11

Not quite. -cclib material goes at the end of the C linker command line, in an order that tries to honor the “list libraries in reverse dependency order” requirement of the C linker. (See e.g. Library order in static linking - Eli Bendersky's website for a discussion of these requirements.) In contrast, -ccopt material goes at the beginning of the C compiler and of the C linker command lines, assuming that the relative order of options doesn’t matter.

1 Like