[Caml-list] A step short of -noautolink?

[Caml-list] A step short of -noautolink?

[Greg Kimberly]

I'm new to caml so apologies if this is too obvious.

I've installed Gerd Stolpmann's intriguing ocamlnet package. It and the 
required prerequisites (e.g. findlib) installed with only one problem on my 
RedHat 8 system. The one problem is that prerequisite package pcre-ocaml 
(version 5.02.0) contains a .cma file that refers to the pcre library. On 
RedHat 8 the pre-installed version of libpcre is 3.9-5 (it is in /lib/), 
while pcre-ocaml v5.02 needs a newer libpcre (I downloaded 4.1 and 
installed it in /usr/local/lib/).

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?

This concern may seem pedantic, but I find that figuring out how to do 
these sorts of things efficiently when starting to use a development 
environment makes life a lot easier down the road.

Thanks,

Greg

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

Re: [Caml-list] A step short of -noautolink?

[Jacques Garrigue]

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

Re: [Caml-list] A step short of -noautolink?

[Gerd Stolpmann]

Am Fre, 2003-04-18 um 02.14 schrieb Jacques Garrigue:
> 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).

You can also set LD_RUN_PATH when you build the dll???.so. In this case,
the path is stored in the file, and is automatically remembered when the
library is loaded.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

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

Re: [Caml-list] A step short of -noautolink?

[Jacques Garrigue]

From: Gerd Stolpmann <info@gerd-stolpmann.de>

> > 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).
> 
> You can also set LD_RUN_PATH when you build the dll???.so. In this case,
> the path is stored in the file, and is automatically remembered when the
> library is loaded.

Actually this is not an answer to the original question: it was about
changing the linking/path for an already built library.
My point was just that, unfortunately you cannot go into dll???.so to
modify it afterwards individually.

But ocamlmklib also builds lib???.a, which contains exactly the same
objects as dll???.so. So you can also act in this case by re-building
dll???.so from lib???.a, if you know enough about your system's
linker. (Currently when you compile C files with ocamlc, this produces
PIC objets, so that lib???.a shall contain only PIC objects, but this may
change in the future.)

If you want to set the runpath at build time with ocamlmklib, you can
already do it with the -rpath option. LD_RUN_PATH may be an
alternative on some systems.

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