From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: fjh@cs.mu.OZ.AU
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] The DLL-hell of O'Caml
Date: Wed, 20 Mar 2002 20:43:22 +0900 [thread overview]
Message-ID: <20020320204322L.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <20020320222038.A3148@hg.cs.mu.oz.au>
From: Fergus Henderson <fjh@cs.mu.OZ.AU>
> Adding new functions to a module ought not break binary backwards
> compatibility. If it does, then you lose many of the benefits of
> separate compilation.
Could you specify what benefits?
The current situation in OCaml is that you have to recompile all
dependencies everytime you change anything in the interface.
If you use a Makefile, even changing a comment will trigger a
recompilation.
But, in my experience most C makefiles are written in the same way
meaning that you have to recompile everytime a header changes.
The real problem is about how to check that binary (and semantics)
compatibility is satisfied. Adding a function might be OK, but
changing a type is not OK (at least not always; Jun Furuse had some
work on it).
The OCaml approach being to chomp all the interface in a single MD5
value, any meaningful change (including addition of a function) will
prevent you from linking without recompiling.
There were good remarks on the list on how a progressive hashing
algorithm (allowing versioning) would be needed to improve that.
> Does adding new functions to a module actually break binary backwards
> compatibility in O'Caml?
At least it breaks for bytecode, where simple indexes are used to get
closures.
But this is not the point: the compiler will not let you link anyway.
I suppose this would be easily corrected if the semantics problem were
solved.
I have a strong feeling that what we need is a good versioning system,
at the language or (probably simpler) library level. But the problem
doesn't seem trivial, in particular if you want efficient checking for
dynamic linking.
Cheers,
Jacques Garrigue
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2002-03-20 11:43 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-11 4:28 Mark D. Anderson
2002-03-11 7:12 ` Mattias Waldau
2002-03-11 12:15 ` Gerd Stolpmann
2002-03-12 0:19 ` Jeff Henrikson
2002-03-12 22:00 ` Gerd Stolpmann
2002-03-20 11:20 ` Fergus Henderson
2002-03-20 11:43 ` Jacques Garrigue [this message]
2002-03-20 17:16 ` Fergus Henderson
2002-03-20 12:53 ` Gerd Stolpmann
2002-03-20 13:05 ` Johan Georg Granström
2002-03-20 13:40 ` Gerd Stolpmann
2002-03-20 19:46 ` Alain Frisch
2002-03-20 20:39 ` Xavier Leroy
2002-03-20 21:16 ` Markus Mottl
2002-03-21 9:07 ` Warp
2002-03-21 10:18 ` Christopher Quinn
2002-03-21 18:13 ` Xavier Leroy
2002-03-21 14:13 ` Jeff Henrikson
2002-03-21 14:13 ` [Caml-list] Type-safe DLL's with OO (was DLL-hell of O'Caml) Tim Freeman
2002-03-21 18:10 ` [Caml-list] The DLL-hell of O'Caml Xavier Leroy
2002-03-21 18:39 ` Sven
2002-03-21 19:22 ` james woodyatt
2002-03-21 19:43 ` Jeff Henrikson
2002-03-22 2:02 ` Brian Rogoff
2002-03-22 10:11 ` Warp
2002-03-21 18:50 ` Sven
-- strict thread matches above, loose matches on Subject: below --
2002-03-22 10:24 Dave Berry
2002-03-22 10:14 Dave Berry
2002-03-02 0:11 [Caml-list] troubleshooting problem related to garbage collection james woodyatt
2002-03-02 7:57 ` [Caml-list] The DLL-hell of O'Caml Mattias Waldau
2002-03-02 11:56 ` Markus Mottl
2002-03-02 21:40 ` Alexander V. Voinov
2002-03-02 14:46 ` Alain Frisch
2002-03-02 19:00 ` Chris Hecker
2002-03-02 19:42 ` Mattias Waldau
2002-03-02 22:41 ` Chris Hecker
2002-03-03 15:56 ` Vitaly Lugovsky
2002-03-04 9:57 ` Sven
2002-03-04 12:20 ` Jacques Garrigue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020320204322L.garrigue@kurims.kyoto-u.ac.jp \
--to=garrigue@kurims.kyoto-u.ac.jp \
--cc=caml-list@inria.fr \
--cc=fjh@cs.mu.OZ.AU \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).