Discussion :

[chaying]

Mais donc quand japplique le protocole qui a marche precedemment :
mon gz, il est installe ou pas ? et comment le verifier ?

Parce quen fait tous (enfin sauf un gz dans /usr/bin qui maurait bien rassure.. jai bien un gzexe et un gzip, mais je crois pas que ce soit ca ) les fichiers ont lair present dans les repertoires..

[InOCamlWeTrust]

Quand tu as installé avec le Makefile modifié (celui que je t'ai donné), tu as eu cette réponse :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
mkdir -p /usr/lib/ocaml/3.09.2/site-lib/
/usr/bin/install -c -m 644 gz.cm[ix] gz.mli bz.cm[ix] bz.mli gz.a gz.cma gz.cmxa dllmlgz.so libmlgz.a /usr/lib/ocaml/3.09.2/site-lib/
You need to put a link to the shared stub in /usr/lib/ocaml/3.09.2/stublibs

Normalement, les fichiers gz.cm[ix], gz.mli, bz.cm[ix], bz.mli, gz.a, gz.cma, gz.cmxa, dllmlgz.so et libmlgz.a doivent être présents dans /usr/lib/ocaml/3.09.2/site-lib/ ; vérifie-le.

Ensuite, il te faut mettre un lien, je crois, dans le dossier /usr/lib/ocaml/3.09.2/stublibs vers /usr/lib/ocaml/3.09.2/site-lib/dllmlgz.so... enfin, moi c'est comme ça que je sens le truc. Beaucoup de librairies partagées ont des liens, afin d'en raccourcir le nom (souvent, le fichier .so ou .a contient le numéro de la version) ou de l'avoir "virtuellement" à disposition ailleurs.

Par exemple, chez moi, dans /usr/lib/, j'ai libxml2.so qui n'est qu'un lien vers libxml2.so.2.6.26.

D'ailleurs, c'est vraiment bizarre de mélanger les noms commençant par dll et les extensions en .so ...

[chaying]

Ca devrait marcher je pense : il faut que jessaie avec de compiler le reste du projet pour voir si ca marche. Je reviens des que cest fait.

Un grand merci en tout cas.