Version française
Home     About     Download     Resources     Contact us    
Browse thread
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Sven Luther <sven.luther@w...>
Subject: Re: [Caml-list] dependancy problems?
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