Comment author: administrator

sometimes it is necessary to install 3rd party C-libraries for some
OCaml-project. If I want to use shared libraries for this purpose,
the question arises how the loader can find those C-libraries if they
are not installed in a standard place (e.g. /usr/lib) but reside in
some OCaml-directory.

I second Jacques' suggestion: either the C library is useful by
itself, e.g. it could be usefully called from C programs, in which
case it should be installed in a standard place; or it is only useful
in conjunction with the C/Caml wrapper code, in which case it is
probably best to combine the two (C library + wrapper code) in one DLL,
installed in an OCaml-specific directory.

Would it be possible and useful to automatically add the directory of
dynamic OCaml-libraries "dll*.so" to the search path "LD_LIBRARY_PATH"
before "dlopen" so that required, locally installed C-libraries can
be found?

It makes me nervous to modify LD_LIBRARY_PATH from within the bytecode
interpreter. For one thing, the dynamic loader could have read and
cached this variable when ocamlrun started up, thus causing the
modifications to be ignored.

Cheers,

• Xavier Leroy

Comment author: administrator

On Wed, 13 Feb 2002, Jacques Garrigue wrote:

Since these are C libraries, the reasonnable thing to do seems to put
them in a standard directory.

Unfortunately, this only works if the user has root privileges.

Alternatively, you can choose to put them somewhere else and use
ocamlmklib's -dllpath option which (contrary to its name?) is not
intended for ocaml's dlls but for ld.so. This wires the location inside
dllpcre.so, but you can still give another path with LD_LIBRARY_PATH.

That's the way I currently solve this problem. I noticed that users have
difficulties handling LD_LIBRARY_PATH, which is required in certain
cases. Maybe the best thing would be, not to take away all work from
the user but to educate them with more documentation... ;)

A third solution is to link the whole library with the stubs. This may
need a bit of twiddling, but this suppress depencies. If the library
is small enough this may be a good idea.

This would require some awful hacks. I don't want to interfere too
much with the way the external library is buildt so as to avoid any
dependencies on its internals (saves me future work).

On Wed, 13 Feb 2002, Xavier Leroy wrote:

It makes me nervous to modify LD_LIBRARY_PATH from within the bytecode
interpreter. For one thing, the dynamic loader could have read and
cached this variable when ocamlrun started up, thus causing the
modifications to be ignored.

I had feared that you don't like this "runtime patching" of
LD_LIBRARY_PATH (neither do I, but it might work - on some systems ;)

I'll therefore stay with the current solution (hardwire the path in
dllpcre.so) and write some more documentation to prevent users from common
pitfalls related to shared libraries. Welcome in DLL-hell... (sigh)

Cheers,
Markus

--
Markus Mottl markus@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus

Comment author: administrator

From: markus@oefai.at

sometimes it is necessary to install 3rd party C-libraries for some
OCaml-project. If I want to use shared libraries for this purpose,
the question arises how the loader can find those C-libraries if they
are not installed in a standard place (e.g. /usr/lib) but reside in
some OCaml-directory.

Would it be possible and useful to automatically add the directory of
dynamic OCaml-libraries "dll*.so" to the search path "LD_LIBRARY_PATH"
before "dlopen" so that required, locally installed C-libraries can
be found?

The problem is that these libraries are loaded by ld.so, not by ocaml,
so that there is very little caml can do about it.

Since these are C libraries, the reasonnable thing to do seems to put
them in a standard directory. Alternatively, you can choose to put
them somewhere else and use ocamlmklib's -dllpath option which
(contrary to its name?) is not intended for ocaml's dlls but for
ld.so. This wires the location inside dllpcre.so, but you can still
give another path with LD_LIBRARY_PATH.

A third solution is to link the whole library with the stubs. This may
need a bit of twiddling, but this suppress depencies. If the library
is small enough this may be a good idea.

Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp
JG

Comment author: administrator

Basically, a C DLL install issue. Not much we can do about it.