Browse thread
[Caml-list] shared libraries [pcre-ocaml]
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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 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. 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 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. 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. Regards, Markus Mottl -- Markus Mottl markus@oefai.at Austrian Research Institute for Artificial Intelligence http://www.oefai.at/~markus ------------------- 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