dynamically finding libraries

dynamically finding libraries

[Vu Ngoc San]

I have a program compiled to native code on a linux machine, which uses 
some more-or-less "standard" library like libpangocairo-1.0.so.0.
Since this library is not universally present on all linux boxes, I 
suspect it might be not so easy for an average user to install it. 
Moreover, it's very small. Therefore I decide to ship it with my software.

The question is: is there a way to decide, at run-time, whether the user 
already has this library or not ? If so, I can ignore (and even delete) 
the version I shipped, and use the user's library. If not, I fall back 
on "my" version.


San


PS: sorry for the first message which appeared - at least with my news 
reader (icedove) - in the wrong thread.

Re: [Caml-list] dynamically finding libraries

[Vu Ngoc San]

skaller a écrit :

> Of course there is a way to do this, but probably you shouldn't.
> Modern Linices usually have package managers, so you should
> just tell the client to install the library.
> 

I like packages, but I like as well the idea of a completely relocatable 
and distribution independent sotfware which could run, for instance, 
from a USB pen-drive.

I first tried to write a script setting LD_LIBRARY_PATH, but I have no 
idea about how to make it work with relative paths and allow symbolic links.

> Otherwise, you can write a C program that tries to call
> a function from the library, and compile, link, and run it,
> and check the result. This is a configuration time check.
> 
> For a run time check, you can call dlopen() and dlsym()
> on the library and a known symbol in the library.
> If you do this, however, you will have to access ALL the
> symbols in the library with dlsym (that is, indirectly).
> 

Darn. No ocaml trick for this ?

> Although Elf does allow load time lazy linkage of symbols,
> so missing symbols don't abort the program until they're
> used, there is no way I know of to have 'maybe' linkage
> of libraries. If your code is linked against a library
> the program will abort if it isn't found at run time,
> and before you get control.
> 
> The best you can do is try to figure out the error code,
> and restart the program in a script that adds 
> the directory containing your version in LD_LIBRARY_PATH.
> 

Style and organization of code

[ian]

I'm looking for a guidebook or just some rules of thumb on how to organize my
OCaml code.

One example:

Say I have a function called "solveHardProblem".   solveHardProblem relies on
several helper functions, which are not going to be useful to any other
functions in the program.  So, my first instinct would be to define all the
helpers using let blocks within the definition of solveHardProblem.

But that would make the definition of solveHardProblem really long -- several
screens of text -- which I've been taught to avoid.  Is it wrong to use a module
to hide those functions if the module signature will contain only that of
solveHardProblem?

And say you DO choose to use a module...  The OCaml documentation says that the
compiler can automatically infer the signature without the need to create a .mli
file for it.  Does anyone actually use that feature in practice, or is creating
a sig hard-wired to the act of creating a struct?

Thanks,
-Ian

dynamically finding libraries

[Vu Ngoc San]

I have a program compiled to native code on a linux machine, which uses 
some more-or-less "standard" library like libpangocairo-1.0.so.0.
Since this library is not universally present on all linux boxes, I 
suspect it might be not so easy for an average user to install it. 
Moreover, it's very small. Therefore I decide to ship it with my software.

The question is: is there a way to decide, at run-time, whether the user 
already has this library or not ? If so, I can ignore (and even delete) 
the version I shipped, and use the user's library. If not, I fall back 
on "my" version.


San