From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id A2ECBBC8C for ; Tue, 18 Jan 2005 13:27:59 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j0ICRx97022011 for ; Tue, 18 Jan 2005 13:27:59 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA00640 for ; Tue, 18 Jan 2005 13:27:58 +0100 (MET) Received: from smtp4.wanadoo.fr (smtp4.wanadoo.fr [193.252.22.27]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j0ICRwFU023413 for ; Tue, 18 Jan 2005 13:27:58 +0100 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0401.wanadoo.fr (SMTP Server) with ESMTP id 537761C00316; Tue, 18 Jan 2005 13:27:58 +0100 (CET) Received: from pegasos (AStrasbourg-251-1-59-193.w82-126.abo.wanadoo.fr [82.126.135.193]) by mwinf0401.wanadoo.fr (SMTP Server) with ESMTP id 2831F1C0031B; Tue, 18 Jan 2005 13:27:58 +0100 (CET) X-ME-UUID: 20050118122758165.2831F1C0031B@mwinf0401.wanadoo.fr Received: from luther by pegasos with local (Exim 4.34) id 1CqsS0-0007Ke-Jg; Tue, 18 Jan 2005 13:27:12 +0100 Date: Tue, 18 Jan 2005 13:27:12 +0100 To: stef@payrard.net, Ocaml , pixel@mandrakesoft.com Subject: Re: [Caml-list] dependancy problems? Message-ID: <20050118122712.GA28131@pegasos> References: <20050118073327.GA8298@cachan-2-82-67-232-89.fbx.proxad.net> <200501180809.15056.jon@jdh30.plus.com> <20050118082522.GB8298@cachan-2-82-67-232-89.fbx.proxad.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050118082522.GB8298@cachan-2-82-67-232-89.fbx.proxad.net> User-Agent: Mutt/1.5.6+20040907i From: Sven Luther X-Miltered: at concorde with ID 41ED00CF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41ED00CE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 dependancy:01 sven:01 luther:01 sven:01 luther:01 wrote:01 wrote:01 ocaml:01 cameleon:01 rpms:01 usr:01 lib:01 ocaml:01 lablgtk:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_BL_SPAMCOP_NET autolearn=disabled version=3.0.0 X-Spam-Level: * On Tue, Jan 18, 2005 at 09:25:22AM +0100, Stéphane Payrard wrote: > Hi, > > note to pixel: you are in copy because you may be interested. > > > On Tue, Jan 18, 2005 at 08:09:14AM +0000, Jon Harrop wrote: > > On Tuesday 18 January 2005 07:33, Stéphane Payrard wrote: > > > Hi, > > > > > > I am an ocaml beginner and I try to compile the last snapshot of > > > cameleon. I am using mandrake with the following rpms: > > > ocaml-lablgtk-1.2.7-1mdk > > > ocaml-3.08.2-1mdk > > > > > > I get the following message when trying to compile: > > > > > > Files /usr/lib/ocaml/lablgtk/gtkThread.cmx > > > and /usr/lib/ocaml/threads/threads.cmxa > > > make inconsistent assumptions over implementation Thread > > > > > > Should I use different versiosn of either lablgtk or ocaml? > > > The INSTALL file suggest OCaml 3.07 and LablGtk 1.2.6 . > > > Or is there an easy way to tweak cameleon to get it to compile > > > with the ocaml and lablgtk versions I have. > > > > I think this problem is due to different ocaml versions being used to generate > > lablgtk and threads. > > Does this mean that the mandrake people have not done a proper job > about dependancies? I have installed unison that also uses > lablgtk. There is no problem there. So I am puzzled. Probably yes. Or maybe just the binary compatibility problem with 3.08.1 ro 3.08.2 migration, so it did not hit only debian. You should fill a bug report about this to mandrake so they fix it. > > Interfaces between OCaml compilation units are *very* brittle. This is being > > discussed on the list at the moment, as even a minor version change of the > > compiler (e.g. 3.08.2 -> 3.08.3) breaks compatibility. > > Naive question: is this due to some internal layout of compiled structures like > classe vtables in C++? Or is this just because modules are updated and > their signature change? See a previous thread about this where i participated (last week and sunday i think) for answers on this. Friendly, Sven Luther