Archives Of The Caml Mailing List: Caml Light 7.1 For Mac
Currently, build environment relative paths are embedded in the generated ocaml libraries. This renders them functionally usless outside of the build environment itself. Andrew Cooper writes ('Xen-devel PATCH tools/ocaml: Fix library generation'): Currently, build environment relative paths are embedded in the generated ocaml libraries. This renders them functionally usless outside of the build environment itself. I'm not realy familiar enough with the ocaml tools to do a proper review of this. Should I hold off waiting for a test report, or shall I just apply it?:-) Thanks, Ian.
Xen-devel mailing list Xen-devel@lists.xen.org. From: Vincent Bernardoff Fix the commands given to the OCaml compiler to make the OCaml bindings to Xen usable outside the build environment. On 08/04/13 18:26, Vincent Bernardoff wrote: From: Vincent Bernardoff Fix the commands given to the OCaml compiler to make the OCaml bindings to Xen usable outside the build environment.
Signed-off-by: Vincent Bernardoff Tested-by: Andrew Cooper Ian: This supersedes the precurser of this patch in the thread 'ocaml bindings' and my patch by the same name. Vincent Bernardoff writes ('Xen-devel PATCH tools/ocaml: Fix library generation'): From: Vincent Bernardoff Fix the commands given to the OCaml compiler to make the OCaml bindings to Xen usable outside the build environment. Signed-off-by: Vincent Bernardoff It would have been good to point out somewhere that the changes to Rules.mk don't just affect the commands given to the ocaml compiler but to all users of libxc, libxl etc. And I'm afraid, viewing the changes in that light, this amounts to reverting b7ee8d2f432f726a1154d172016d3f2b22757fe3 'tools build: link to specific library version (libxs, libxl, xenstore, xenstat)'.
(CCing Roger, author of that commit.) So I'm afraid this patch is not acceptable in this form. Is there no way to get the ocaml compiler to link against a specified library file without embedding the path into the executable? Xen-devel mailing list Xen-devel@lists.xen.org. On 09/04/13 15:30, Ian Jackson wrote: Vincent Bernardoff writes ('Xen-devel PATCH tools/ocaml: Fix library generation'): From: Vincent Bernardoff Fix the commands given to the OCaml compiler to make the OCaml bindings to Xen usable outside the build environment. Signed-off-by: Vincent Bernardoff It would have been good to point out somewhere that the changes to Rules.mk don't just affect the commands given to the ocaml compiler but to all users of libxc, libxl etc. And I'm afraid, viewing the changes in that light, this amounts to reverting b7ee8d2f432f726a1154d172016d3f2b22757fe3 'tools build: link to specific library version (libxs, libxl, xenstore, xenstat)'.
(CCing Roger, author of that commit.) So I'm afraid this patch is not acceptable in this form. Is there no way to get the ocaml compiler to link against a specified library file without embedding the path into the executable? I was not aware of Rogers commit, but at the very least it break static linking. Furthermore, the library directory paths are specified on the command line, which take priority over system library paths. The only way I can see, given a brief read of the gcc manual, for the wrong versions to be linked is if there are stale versions of the libraries present in the build directory.
As far as I am concerned, having had to explicitly fix this up in XenServer, commit b7ee8d2f432f726a1154d172016d3f2b22757fe3 should be reverted, unless I am really misunderstanding the point of the patch. Andrew Xen-devel mailing list Xen-devel@lists.xen.org. Andrew Cooper writes ('Re: Xen-devel PATCH tools/ocaml: Fix library generat As far as I am concerned, having had to explicitly fix this up in XenServer, commit b7ee8d2f432f726a1154d172016d3f2b22757fe3 should be reverted, unless I am really misunderstanding the point of the patch. Going back to when this was done, says Minor build process fixes, to allow the use of LDFALGS and CFLAGS with folders that contain older versions of xen libraries and added a specific env variable to point to yajl header and library files. So AIUI the problem is that you have an LDFLAGS which mentions -L where contains other versions of the Xen libraries, you end up linking against them.
Xen-devel mailing list Xen-devel@lists.xen.org. On Tue, 2013-04-09 at 16:10 +0100, Ian Jackson wrote: Andrew Cooper writes ('Re: Xen-devel PATCH tools/ocaml: Fix library generat As far as I am concerned, having had to explicitly fix this up in XenServer, commit b7ee8d2f432f726a1154d172016d3f2b22757fe3 should be reverted, unless I am really misunderstanding the point of the patch. Going back to when this was donesays Minor build process fixes, to allow the use of LDFALGS and CFLAGS with folders that contain older versions of xen libraries and added a specific env variable to point to yajl header and library files. So AIUI the problem is that you have an LDFLAGS which mentions -L where contains other versions of the Xen libraries, you end up linking against them.
There was also an issue with linking against the libraries in /usr/lib instead of the fresh ones in the build tree, which IIRC was the real impetus behind this change. Xen-devel mailing list Xen-devel@lists.xen.org.
On 10/04/13 12:33, Ian Campbell wrote: On Tue, 2013-04-09 at 15:50 +0100, Andrew Cooper wrote: I was not aware of Rogers commit, but at the very least it break static linking. The change is only about dynamic linking against libraries in the current tree. This is the issue I reported 6 months ago in Although back then I was simply trying to make Xen 4.2 to compile in the XenServer build system, and did not pay too much attention to why the build had regressed from 4.1 Andrew Xen-devel mailing list Xen-devel@lists.xen.org.
On Wed, 2013-04-10 at 13:01 +0100, Andrew Cooper wrote: On 10/04/13 12:33, Ian Campbell wrote: On Tue, 2013-04-09 at 15:50 +0100, Andrew Cooper wrote: I was not aware of Rogers commit, but at the very least it break static linking. The change is only about dynamic linking against libraries in the current tree. This is the issue I reported 6 months ago in I replied to this at the time, my last comment in was: However taking a step back I think the underlying bug here is actually the use of $(LDLIBSlibxenstore) where we should be using $(LIBXENSTORE) when linking and not just as a dependency. Xen-devel mailing list Xen-devel@lists.xen.org. On Wed, 2013-04-03 at 19:02 +0100, Andrew Cooper wrote: Currently, build environment relative paths are embedded in the generated ocaml libraries.
This renders them functionally usless outside of the build environment itself. Nit: 'useless' but more importantly am I correct that the change here is for each library foo to go forom passing '-cclib /path/to/libfoo.so' to instead using '-cclib -lfoo -ldopt /path/to/libfoo.so'? I presume cclib is the thing to use when linking against this ocaml library and ldopt is the thing to use when actually linking the ocaml library itself? Could we get a brief description of the change in those terms in the commit message. Why does this only impact libxenctrl and libxeneventchn?
Are the libxl bindings not similarly affected?
OCaml for the Skeptical Some History Which ML? OCaml is a dialect of ML (for Meta Language), which started out as a language for mathematical theorem proving in the at the University of Edinburgh and which is descended from Algol and Lisp via P.J. Landin's never-implemented language ISWIM ('If you See What I Mean' - which was very influential due to several important journal articles in the late 1960's). Development of ML proceeded at Edinburgh, Stanford and AT&T Bell Labs; at the in France as Caml (for Categorical Abstract Machine Language, after the underlying compilation technique); and at Chalmers in Sweden (as Lazy ML). The original line eventually became Standard ML, which has several notable implementations (, etc). Lazy ML strongly influenced Haskell and is no longer actively developed. Caml development continues at INRIA.
A by Guy Cousineau, the original developer, provides some insights. There are three 'Caml' languages (at least: the excellent Caml compilers are very popular with researchers all over the world as a basis for experimental languages):. Caml: the original French implementation; no longer developed. Caml Light (and later Caml Special Light): the precursors to OCaml; practically the same as OCaml except for the object system that gives OCaml its 'O'; still available, quite stable and still supported I think (latest release was in 2002), but I don't know why you would choose it over OCaml. Objective Caml or OCaml: the latest and greatest version of the language, introduced the first strongly-typed object system with type inference. In summary, make sure you install and use OCaml and don't bother with the earlier Camls! Standard ML and OCaml have minor syntactic differences.
If you know OCaml, you can switch to ML very easily. The most important differences are in the libraries of the languages and in two significant OCaml advances: the object system (Standard ML has none) and the module system (very similar in basic use, though).
Getting OCaml OCaml is installed on merlot.lib and you can use it there. It's in the FreeBSD ports, the NetBSD packages, and Linux rpms are available (Debian, Mandrake and RedHat reportedly install OCaml). Binaries for Windows and Linux are available from INRIA and, of course, OCaml is free software so you can always download and install from source; it compiles and runs on most every version of Unix (MacOS X included). For more information see.
Third Party Software The best one-stop-shopping site for third party OCaml libraries is (newbies should go directly to the ). OCaml Documentation Official Documentation, incorporating:. (mostly data structures) and much more. OCaml Books Besides these books in English, there are eleven in French, and one each in German and Italian., Emmanuel Chailloux, Pascal Manoury and Bruno Pagano, preliminary translation of the book. This book is very good and typically O'Reillian; I highly recommend it., Guy Cousineau and Michel Mauny, Cambridge University Press, Cambridge, 1998, ISBN 0-521-57183-9 (hardcover), 0-521-57681-4 (paperback) This book is a little more formal; most would probably consider it rather dry.
Note that it covers the earlier language Caml rather than OCaml and so has no coverage of OCaml's object system nor the module system. But all the stuff about functional programming and types and syntax is applicable to OCaml., Matthias Felleisen and Daniel P. Friedman, The MIT Press, Cambridge MA, 1997, ISBN 0-262-56114-X Like the other Little books by the same authors ( Lisper, Schemer, Java), this is not a conventional introduction to ML. It's a programmed text with a sense of humor that will either enlighten you or infuriate you. It assumes no previous familiarity with ML but covers very advanced topics very quickly. It is almost completely concerned with types. While this is a book about Standard ML, it works fine for OCaml and the authors provide a one-page cheat sheet that explains how to translate the book's ML code into OCaml.) Finally it should be mentioned that there are many books on Standard ML and all of these are quite usable by OCaml programmers, once you've gone through any of the books above (you do want to initially learn OCaml from an OCaml book, I think, but after that you can branch out into the literature of Standard ML).
OCaml Tutorials I suggest doing these tutorials in this order, except for Kitt's, which, being so terse, is good to look at simultaneously with all of these. by David Matuszek.
A long single web page; worth reading. Jason Hickey's as used in his.
Archives Of The Caml Mailing List: Caml Light 7.1 For Mac Free
110-page well-hyperlinked PDF, very well done. by Richard W.M.
Substantial group of web pages; gets into some fairly advanced stuff quickly; covers some stuff that most tutorials don't (keyword and optional parameters, OCaml's Gtk bindings (Gtk is the popular, modern GUI toolkit used by the Gimp and the Gnome project), garbage collection, a great discussion of weak pointers, speed, etc); and frequently explains what's going on internally in the compiler and interpreter. A nice 10-page introduction. Kind of like a very long reference card. OCaml Mailing Lists and Newsgroups The official can also be (which I highly recommend) thanks to or directly.
There's also a list (also available ). OCaml is also discussed on Usenet in (which also covers Standard ML) and (which covers all functional languages). Footnotes. Michael J. Gordon; Robin Milner; Christopher P. Edinburgh LCF: A Mechanized Logic for Computation. New York: Springer Verlag, 1979.
'The Next 700 Programming Languages' in Communications of the ACM. Pages 157-66. Moscow ML is actually implemented using the Caml Light compiler!