On Fri, Feb 11, 2022 at 7:18 PM BOBOT Francois <Francois.BOBOT@cea.fr> 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