From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA19295; Tue, 23 Apr 2002 08:51:45 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id IAA19280 for ; Tue, 23 Apr 2002 08:51:44 +0200 (MET DST) Received: from gromit.it.su.se (gromit.it.su.se [130.237.95.77]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g3N6phP08637 for ; Tue, 23 Apr 2002 08:51:43 +0200 (MET DST) Received: (from rnyberg@localhost) by gromit.it.su.se (8.11.6/8.11.6) id g3N6pTI22814; Tue, 23 Apr 2002 08:51:29 +0200 (CEST) (envelope-from rnyberg) Date: Tue, 23 Apr 2002 08:51:29 +0200 From: Richard Nyberg To: Jacques Garrigue Cc: skaller@ozemail.com.au, caml-list@inria.fr Subject: Re: [Caml-list] shared libraries [pcre-ocaml] Message-ID: <20020423085129.A22797@gromit.it.su.se> Mail-Followup-To: Richard Nyberg , Jacques Garrigue , skaller@ozemail.com.au, caml-list@inria.fr References: <20020422103046.B21430@gromit.it.su.se> <3CC472A7.5070901@ozemail.com.au> <20020423094308M.garrigue@kurims.kyoto-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020423094308M.garrigue@kurims.kyoto-u.ac.jp>; from garrigue@kurims.kyoto-u.ac.jp on Tue, Apr 23, 2002 at 09:43:08am +0900 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > 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. Well, you are both right of course, but the real problem here was me. There is no problem with pcre-ocaml if you tell it where to look for its libraries. I had just missed setting OCAML_LIB_INSTALL correctly when I installed pcre-ocaml. So, it's my bad and I promise to _read_ the documentation instead of just _looking_ at it next time ;) -Richard ------------------- 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