Giter Site home page Giter Site logo

Installation sur Linux about ocaml HOT 4 CLOSED

vicuna avatar vicuna commented on May 18, 2024
Installation sur Linux

from ocaml.

Comments (4)

vicuna avatar vicuna commented on May 18, 2024

Comment author: administrator

Bonjour,

j'ai installé sans problèmes plusieurs versions d'OCaml sur différentes
plates-formes sans jamais rencontrer aucun problème. Bizarrement, je
n'arrive pas à compiler (version 2.04 et 2.99) sur certaines machines
Linux (les nouvelles machines élèves Linux de l'ENS; pas de problèmes
sur d'autres Linux).

Merci pour le strace, qui m'a permis (je crois) de localiser le probleme.
Mon impression est que c'est un bug... dans Linux!

Explication: l'erreur se produit lorsque OCaml ecrit un fichier d'interface
compilee, en l'occurrence pervasives.cmi. L'algorithme pour ecrire ces
fichiers
est le suivant:

  • ecrire un paquet de donnees binaires
  • rouvrir le fichier en lecture
  • calculer un checksum MD5 des donnees qu'on vient d'ecrire
  • ecrire ce checksum a la fin du fichier.

Sur le strace, dans le cas qui reussit, on voit bien ces etapes:

open("pervasives.cmi", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
creation du fichier en ecriture
write(3, "Caml1999I005\204\225\246\276\0\0"..., 4096) = 4096
write(3, "\365\341\0\1\1\256\260\262\4\367"..., 4096) = 4096
write(3, "\341\0\1\0031\2\5\365\341\0\1\003"..., 3297) = 3297
ecriture de 4096+4096+3297=11489 octets
open("pervasives.cmi", O_RDONLY) = 4
reouverture en lecture
lseek(4, 0, SEEK_END) = 11489
lseek(4, 0, SEEK_SET) = 0
determination de la taille courante du fichier = 11489
read(4, "Caml1999I005\204\225\246\276\0\0"..., 4096) = 4096
read(4, "\365\341\0\1\1\256\260\262\4\367"..., 4096) = 4096
read(4, "\341\0\1\0031\2\5\365\341\0\1\003"..., 4096) = 3297
calcul du MD5
close(4) = 0
write(3, "\204\225\246\276\0\0\0\37\0\0\0\4"..., 51) = 51
ecriture du MD5 et d'autres infos
close(3) = 0

Sur le strace du cas d'echec, il se produit quelque chose de tres bizarre:

open("pervasives.cmi", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
write(3, "Caml1999I005\204\225\246\276\0\0"..., 4096) = 4096
write(3, "\365\341\0\1\1\256\260\262\4\367"..., 4096) = 4096
write(3, "\341\0\1\0031\2\5\365\341\0\1\003"..., 3297) = 3297
ecriture de 4096+4096+3297=11489 octets, c'est normal
open("pervasives.cmi", O_RDONLY) = 4
lseek(4, 0, SEEK_END) = 11540
mais ici la taille courante du fichier est 11540, et non 11489!!!
lseek(4, 0, SEEK_SET) = 0
read(4, "Caml1999I005\204\225\246\276\0\0"..., 4096) = 4096
read(4, "\365\341\0\1\1\256\260\262\4\367"..., 4096) = 4096
read(4, "\341\0\1\0031\2\5\365\341\0\1\003"..., 4096) = 3297
read(4, "", 4096) = 0
on essaye de lire 11540 octets, et bien sur ca echoue car il n'y
en a que 11489

Je précise que l'on travaille en NFS (le serveur NFS est un Sun sous
Solaris).
Avez-vous une idée d'où cela peut venir ?

Je pense qu'il s'agit d'un probleme de NFS entre Linux et Solaris.
J'ai vaguement entendu parler de problemes de cet ordre, certains pouvant etre
corriges en appliquant un patch de Sun sur la machine Solaris, mais je ne
me souviens pas des details. Peut-etre que les archives de la liste
linux-kernel ou du newsgroup comp.os.linux.development.kernel contiennent
plus d'infos la-dessus.

  • Xavier Leroy

from ocaml.

vicuna avatar vicuna commented on May 18, 2024

Comment author: administrator

Looks like an NFS incompatibility between Linux and Solaris

from ocaml.

vicuna avatar vicuna commented on May 18, 2024

Comment author: administrator

Bonjour,

je vous avais signalé un problème que nous rencontrons pour compiler
OCaml sur les Linux du réseau de l'ENS. Apparemment, il s'agit d'un
problème de NFS, lié à l'algorithme d'écriture des sommes de controle
dans les fichiers signature (le meme fichier est ouvert en ecriture
et en lecture dans 2 fd différents; je ne sais pas si NFS est censé
gérer cela).

J'ai patché env/typing.ml pour fermer le fichier avant de calculer
la somme MD5 et l'ouvrir de nouveau en mode append. J'ai vérifié, cela
fonctionne et permet effectivement de compiler sur les Linux connectés à
un serveur NFS Solaris (avant, nous compilions sur un Linux standalone).

Voici la version modifiée de la fonction concernée:

let save_signature sg modname filename =
Btype.cleanup_abbrev ();
let comps =
components_of_module empty Subst.identity
(Pident(Ident.create_persistent modname)) (Tmty_signature sg) in
let oc = open_out_bin filename in
output_string oc cmi_magic_number;
output_value oc (modname, sg);
flush oc;
close_out oc;
let crc = Digest.file filename in
let crcs = (modname, crc) :: imported_units() in
let oc = open_out_gen
[Open_wronly; Open_append; Open_binary] 0o666 filename in
output_value oc crcs;
close_out oc;
(* Enter signature in persistent table so that imported_unit()
will also return its crc *)
let ps =
{ ps_name = modname; ps_sig = sg; ps_comps = comps; ps_crcs = crcs }
in
Hashtbl.add persistent_structures modname ps

Et le diff avec la version 2.99:
765a766

close_out oc;
767a769,770
let oc = open_out_gen
[Open_wronly; Open_append; Open_binary] 0o666 filename in

(je vois à l'instant, dans le CVS que la fonction a été modifiée depuis la
2.99)

Bien cordialement,

Alain Frisch

from ocaml.

vicuna avatar vicuna commented on May 18, 2024

Comment author: administrator

je vous avais signalé un problème que nous rencontrons pour compiler
OCaml sur les Linux du réseau de l'ENS. Apparemment, il s'agit d'un
problème de NFS, lié à l'algorithme d'écriture des sommes de controle
dans les fichiers signature (le meme fichier est ouvert en ecriture
et en lecture dans 2 fd différents; je ne sais pas si NFS est censé
gérer cela).

Mais si, mais si, NFS n'est pas MSDOS :-)

Le problème en question semble être un bug connu de Solaris, un patch
est disponible chez Sun:

We had the same problem with Linux<-->Solaris. It was fixed by a patch
fom Sun. The problem would occur when Linux padded the NFS
packet. Solaris used the size of the packet, not the size field of the
packet to determine the amount of data in the packet. Most Linux NFS
requests are block-sized request so this error rarely appears.

J'ai patché env/typing.ml pour fermer le fichier avant de calculer
la somme MD5 et l'ouvrir de nouveau en mode append. J'ai vérifié, cela
fonctionne et permet effectivement de compiler sur les Linux connectés à
un serveur NFS Solaris (avant, nous compilions sur un Linux standalone).

Plutôt que de contourner le bug de Solaris dans Caml, je vous
encourage à patcher votre serveur Solaris. D'autres applications que
Caml peuvent être affectées. Autrement dit, quand on a 40 de fièvre,
il vaut mieux soigner la fièvre que casser le thermomètre :-)

  • Xavier Leroy

from ocaml.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.