[
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: | Jacques Garrigue <garrigue@k...> |
| Subject: | Re: [Caml-list] A step short of -noautolink? |
From: Greg Kimberly <lists@gak.com> > I'm new to caml so apologies if this is too obvious. This doesn't look obvious at all! [..] > So far, so good. Unfortunately, the default build for the examples fails > because the examples implicitly include pcre.cma which contains linker > directives which cause the /lib/libpcre.so.0 to be linked- which is the > wrong version. At this point I can see two possible fixes: > > Upgrade the version of libpcre in /lib - not good in the general case as it > might cause compatiblility problems elsewhere > > Use -noautolink in the example makefile to suppress the inclusion of the > linker directive -lpcre which has been inherited from pcre.cma > > This is the solution I'm using but it seems non-optimal to throw away all > included linker directives just to remove one unwanted dependency. Is there > some better way to deal with this issue that I'm overlooking? Is there some > way to tell camlc to ignore a particular inherited directive from a .cma? After some fiddling I think I have a solution to your problem. You can change the autolink information in a .cma by relinking it, with the -noautolink option. If you just want to strip this information you can write: ocamlc -a -noautolink -o mypcre.cma pcre.cma But you can also replace it with correct information: ocamlc -a -noautolink -o mypcre.cma pcre.cma -custom \ -ccopt -L/usr/local/lib -cclib -lpcre_stubs -cclib -lpcre (I'm not sure of the library name for pcre stubs) Note that all this may be irrelevant to dynamically loaded stubs: in that case details about where to find the C library are inside dll???.so, and you cannot change them. However, you can change the load path with LD_LIBRARY_PATH (the system ld.so is at work in this case, and ocaml knows nothing about it). Cheers, 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