Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] shared libraries [pcre-ocaml]
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-04-23 (00:43)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] shared libraries [pcre-ocaml]
From: John Max Skaller <>
> 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
> >
> >Error on dynamically loaded library: Shared object "" not found
> >----------
> >
> >I ran truss to see the syscalls made by ocamlc (relevant bit below) and
> >to me it seems as if it finds but not on which
> > 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 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 installed in 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 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, not So if you put 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 should be included
in (not too hard), or 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 Archives:
Bug reports: FAQ:
Beginner's list: