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

[BOBOT Francois <Francois.BOBOT@cea.fr>]

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