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: -- (:)
From: Markus Mottl <markus@o...>
Subject: Re: [Caml-list] shared libraries [pcre-ocaml]
On Tue, 23 Apr 2002, Jacques Garrigue wrote:
> 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.

The only thing that needs to be changed is setting the installation path
(OCAML_LIB_INSTALL) correctly before "make"ing the library (as described
in the INSTALL-file; please do me all a favour and read it _before_
installation ;)

The linker stores the path to this directory in the generated
OCaml-library so that it can find any associated shared C-libraries.

The only known problem so far with the installation of Pcre-OCaml is
portability on MacOS X: shared libraries are not (yet) supported there,
because "libtool", which is used by the shipped C-library, obviously
misbehaves on this platform. Just compile the library statically then
as also described in the INSTALL-file.

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

My suggestion on the bug tracker was to automatically update the path to
shared C-libraries at runtime so that it also contains the directory in
which the associated OCaml-library resides.  This would make things much
easier for me, but as Xavier noted, this could cause endless troubles
with portability, because some systems may react differently to this hack.

Markus Mottl

Markus Mottl                                   
Austrian Research Institute
for Artificial Intelligence        
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: