From: John Max Skaller <skaller@ozemail.com.au>
> Richard Nyberg wrote:
> 
> >Hello I've some problems with ocaml and shared libraries. I'm running
> >a recent FreeBSD-4-STABLE and have ocaml 3.04 installed from ports.
> >
> >pcre-ocaml is built with shared libraries and is installed in
> >/usr/local/lib/ocaml/site-lib/pcre
> >
> >If I use ocamlopt to compile everything is fine but when I use ocamlc
> >the following error occurs.
> >
> >----------compiling
> ># ocamlc -o myprog -I +site-lib/netstring -I +site-lib/pcre \
> >         unix.cma pcre.cma netstring.cma myprog.ml
> >
> >Error on dynamically loaded library: Shared object "libpcre.so.0" not found
> >----------
> >
> >I ran truss to see the syscalls made by ocamlc (relevant bit below) and
> >to me it seems as if it finds dllpcre.so but not libpcre.so.0 on which
> >dllpcre.so depends. However if I run ldconfig to include pcre-ocaml's
> >installation directory everything works just fine.
> >
> >So, should I have to use ldconfig or is there something wrong?
> 
> Argg... crappy unix hackery. The dynamic loader typically searches for
> relative filenames in the ldconfig'd search path, augmented by LD_PATH
> environment variable. Absolute filenames just get opened directly.
> 
> You can see below that ocaml is manually stat'ing dllpcre.so in places
> it knows about before doing a dlopen on an absolute filename.
> Unfortunately, it depends on another shared lib, and ld is
> searching for that by itself.
> 
> It doesn't find it, since /usr/local/ocaml/site-lib/pcre isn't on the 
> ldconfig path.
> This suggests the binding to dllpcre.so.0 installed in dllpcre.so is a 
> relative
> filename. So does the ld.conf file above .. and if you run ldconfig on that,
> of course now the load works.
> 
> Running ldconfig on the ld.conf file will work.
> Another solution is simply to install dllpcre.so.0 in /usr/local/lib.
> Another is to put a symbolic link there. None of these solutions is
> very good ..

Almost correct answer: the problem is of course with libpcre.so.0, not
dllpcre.so. So if you put libpcre.so.0 in any place where the system
loader can find it (like /usr/local/lib, but also any directory in
LD_LIBRARY_PATH), things will work smooth.

More basically, I would say that pcre-ocaml is not packaged correctly:
for this kind of use, either the code of libpcre.so should be included
in dllcpre.so (not too hard), or libcpre.so.0 should be installed to a
public directory. Unfortunately the system loader does not provide any
interface to change the load path cleanly.

Best regards,

Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners