[Caml-list] Dynamic link of C library

[Caml-list] Dynamic link of C library

[BOBOT Francois]

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?

Best,

-- 
François

Re: [Caml-list] Dynamic link of C library

[Xavier Leroy]

[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2756 bytes --]

Re: [Caml-list] Dynamic link of C library

[BOBOT Francois]

Le dimanche 13 février 2022 à 17:55 +0100, Xavier Leroy a écrit :
> On Fri, Feb 11, 2022 at 7:18 PM BOBOT Francois 
> 
> 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.

Thank you a lot for this bit of wisdom, I though LD_LIBRARY_PATH was
more widely used by tools.

> 
> 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.


It is true that it has been in the past source of security holes
(setuid program, sudo, ...), perhaps other holes remain.

Should we use -rpath[1] with $ORIGIN or @loader_path in order to use
relative path? I discarded this as too hackish, but other community
uses it (go, npm). Windows doesn't seems to have direct support for it,
but there are always an unknown way on this plateform[2].

More importantly if -rpath with relative path would solve the problem
for .cmxs it seems not to work for .cmxa. Since the OCaml part is
statically linked, the relative path will be to the executable not the
directory of the library, isn't it? An ld for OCaml executable[3] would
solve the problem (by not using .cmxa) but it is untested even if easy
to add to Dune.


[1]: https://www.lekensteyn.nl/rpath.html#what-is-rpath
[2]:
https://stackoverflow.com/questions/107888/is-there-a-windows-msvc-equivalent-to-the-rpath-linker-flag
[3] https://github.com/ocaml/dune/issues/3866

Kind regards,

-- 
François

Re: [Caml-list] Dynamic link of C library

[BOBOT Francois]

Hi,

Le vendredi 11 février 2022 à 19:18 +0100, François Bobot a écrit :
> However static linking lose the
> advantage of a C library with the *L*GPL licence (no?). 

A colleague pointed that my understanding of the LGPL was wrong. The
linking exception applies also for static linking if the source of the
LGPL library are provided and script are provided for relinking with
another version of the library.

https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic

I forgot section 6.a of LGPL v2.1. The additional static linking
exception of the OCaml LICENCE exempt of less than what I though.

So in the context of an OCaml stub of an LGPL library distributed as an
OPAM package (source), even if the library is statically linked in the
.cmxs and .a of the OCaml library, any OCaml projet can use it.

Best regards,

-- 
François