On Fri, Feb 11, 2022 at 7:18 PM BOBOT Francois wrote: > Hi everyone, > > I'm a little lost with some binding. Usually I bind statically > C library in OCaml libraries (except for C libraries already present on > the system). It works well for all the targets (bytecode, native static > .cmxa, native dynamic .cmxs) by keeping the C library in the OCaml > library. Usually one just need to be sure that libfoo.a is compiled > with -fPic (which is not usual). However static linking lose the > advantage of a C library with the *L*GPL licence (no?). So I'm lost > between everything we have: > > - .cmxs needs ld to be able to find the dynamic C library, libfoo.so > - there is the stublibs directory, but it is only for bytecode and > files are prefixed by dll instead of lib so ld can't find them. > - There is no directory to install dynamic C library in opam, no > LD_LIBRARY_PATH set > - -dllpath requires to know the install directory during compilation > > > -dllpath is usually the chosen solution but hardcoding path makes build > cache less useful, and dune knows the install directory only at the > end. Is there an elegant solution I haven't seen or some of our tools > need to be modified? > This problem with Unix-style shared libraries is not specific to OCaml: you run into the same issues with a program entirely written in C, if I'm not mistaken. Popular wisdom says that .so files must be installed in /usr/lib or /usr/local/lib or some other public place advertised in /etc/ld.so.conf. (With semantic versioning, if applicable.) Some applications install their own .so files in a specific directory, then consist in a shell script that sets LD_LIBRARY_PATH before running the main executable. I'm not convinced OCaml tools should try to implement a different behavior. In particular, I would object to OPAM setting LD_LIBRARY_PATH in the environment to point to a directory owned by the user: it looks like a security risk. Kind regards, - Xavier Leroy > > Best, > > -- > François >