[Caml-list] OCaml version 3.11.0+beta1
Damien Doligez
We are pleased to celebrate the birthday of Friedrich Nietzsche
by releasing OCaml version 3.11.0+beta1. We need YOU to test
it thoroughly and report any problems you might have. Does
your favorite software work with it?
It is available as a source release only (plus documentation),
from this address:
< http://caml.inria.fr/pub/distrib/ocaml-3.11/ >
It is also available from our CVS server at:
< http://camlcvs.inria.fr/ >
Use tag "ocaml3110beta1" to get the beta release, and tag
"release311" to track the bug fixes between this and the
final release of 3.11.0.
Have fun and PLEASE send us some feedback, positive or negative.
-- The OCaml team.
--------------------- Camlp5 HOW-TO ------------------------
Camlp5 version 5.09 does not work with OCaml 3.11.0+beta1 out of the
box. A new version compatible with OCaml 3.11.0 should be released
very soon. In the meantime you can use the following commands (in the
root directory of the Camlp5 5.09 sources) to compile Camlp5 5.09 with
OCaml 3.11.0+beta1. Note that you will need to provide the path name
to a copy of the OCaml 3.11.0+beta1 sources at the line labelled
"HERE".
cp -R ocaml_stuff/3.11 ocaml_stuff/3.11.0
cp ocaml_src/main/ast2pt.ml_3.11 ocaml_src/main/ast2pt.ml_3.11.0
ed main/ast2pt.ml <<-EOF
g/OCAML_3_11/s//& OR OCAML_3_11_0/
wq
EOF
ed top/rprint.ml <<-EOF
g/OCAML_3_11/s//& OR OCAML_3_11_0/
wq
EOF
/configure --transitional
make steal OCAML_SRC=<path-to-ocaml-source-dir> # HERE
make core
make bootstrap_sources
/configure --transitional
make world.opt
That's all. Now you can "make install" as usual.
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Dario Teixeira
> We are pleased to celebrate the birthday of Friedrich
> Nietzsche by releasing OCaml version 3.11.0+beta1. We need YOU
> to test it thoroughly and report any problems you might have.
> Does your favorite software work with it?
Great news, thanks! One note to GODI users: trying out the beta
version is very simple; just ask GODI to build the godi-ocaml and
godi-ocaml-src packages, and configure the latter one by setting
OCAML_CVS_CHECKOUT to "yes" and OCAML_CVS_REVISION to "release311"
(or "ocaml3110beta1" if you want the Beta 1 static snapshot).
GODI will then automatically recompile all packages.
Btw, I noticed that type-conv will *not* compile with this beta
(a Camlp4 incompatibility?). Anyone experiencing a similar
problem? The GODI protocol is listed at the end.
Kind regards,
Dario Teixeira
/bin/mkdir -p /home/dario/.godi_3.11/build/godi/godi-type-conv/work/type-conv-1.6.2
===> Patching for godi-type-conv-1.6.2godi1
===> Configuring for godi-type-conv-1.6.2godi1
===> Building for godi-type-conv-1.6.2godi1
make[1]: Entering directory `/home/dario/.godi_3.11/build/godi/godi-type-conv/work/type-conv-1.6.2/lib'
ocamlc -c -I +camlp4 pa_type_conv.mli
ocamlc -c -pp "camlp4orf " -I +camlp4 pa_type_conv.ml
File "pa_type_conv.ml", line 190, characters 16-17:
While expanding quotation "ctyp" in a position of "patt":
Parse error: [a_LIDENT] expected after "?" (in [ctyp])
File "pa_type_conv.ml", line 1, characters 0-1:
Error: Preprocessor error
make[1]: *** [pa_type_conv.cmo] Error 2
make: *** [all] Error 2
make[1]: Leaving directory `/home/dario/.godi_3.11/build/godi/godi-type-conv/work/type-conv-1.6.2/lib'
*** Error code 2
Stop.
godi_make: stopped in /home/dario/.godi_3.11/build/godi/godi-type-conv
*** Error code 1
Andres Varon
On Oct 15, 2008, at 9:40 AM, Damien Doligez wrote:
> Dear OCaml Users,
>
> We are pleased to celebrate the birthday of Friedrich Nietzsche
> by releasing OCaml version 3.11.0+beta1. We need YOU to test
> it thoroughly and report any problems you might have. Does
> your favorite software work with it?
Thanks for the good work. I would like to know exactly what
architectures support the native Dynlink? I did not see this
information in the release notes.
I need to update configure scripts to include it or not in the link
step because dynlink.cmxa is needed by camlp4fulllib.cmxa, but now I
realize that it's not just a matter of having OCaml >= 3.11.
many thanks again,
Andres
> ./configure --transitional
> make steal OCAML_SRC=<path-to-ocaml-source-dir> # HERE
> make core
> make bootstrap_sources
> ./configure --transitional
Alain Frisch
> Thanks for the good work. I would like to know exactly what
> architectures support the native Dynlink? I did not see this information
> in the release notes.
The native Dynlink is known to work under Linux x86, Linux AMD64, Win32
(mingw/msvc ports). It has been lightly tested under Win64, some flavors
of BSDs and also the Cygwin port.
-- Alain
Andres Varon
On Oct 15, 2008, at 11:04 AM, Alain Frisch wrote:
> Andres Varon wrote:
>> Thanks for the good work. I would like to know exactly what
>> architectures support the native Dynlink? I did not see this
>> information in the release notes.
>
> The native Dynlink is known to work under Linux x86, Linux AMD64,
> Win32 (mingw/msvc ports). It has been lightly tested under Win64,
> some flavors of BSDs and also the Cygwin port.
Great, thanks for the info. Is there a set of tests that I can run? I
would like to see how it works in Mac OS X which is my primary
development environment and the second most important among our users.
One more question: is it always compiled? or is dynlink.cmxa simply
not available in some architectures? if yes, what are those?
Andres
Daniel Bünzli
Le 15 oct. 08 à 16:55, Andres Varon a écrit :
> Thanks for the good work. I would like to know exactly what
> architectures support the native Dynlink? I did not see this
> information in the release notes.
I was looking for the same information. This should be added to the
release notes.
Le 15 oct. 08 à 17:04, Alain Frisch a écrit :
> The native Dynlink is known to work under Linux x86, Linux AMD64,
> Win32 (mingw/msvc ports). It has been lightly tested under Win64,
> some flavors of BSDs and also the Cygwin port.
And on macosx ? It seems here on 10.5.5 that only dynlink.cma and
dynlink.cmi for bytecode get installed. So I guess there's no support.
What about the future ?
Thanks,
Daniel
Andres Varon
On Oct 15, 2008, at 11:22 AM, Daniel Bünzli wrote:
>
>> The native Dynlink is known to work under Linux x86, Linux AMD64,
>> Win32 (mingw/msvc ports). It has been lightly tested under Win64,
>> some flavors of BSDs and also the Cygwin port.
>
> And on macosx ? It seems here on 10.5.5 that only dynlink.cma and
> dynlink.cmi for bytecode get installed. So I guess there's no
> support. What about the future ?
It was installed here: Mac OS X 10.5.5 x86. Maybe this is an issue
that I mentioned before in the list and got no response?: At least one
cmxa only get installed if you make opt.opt. camlp4fulllib.cmxa was
not installed with only make opt (which led to broken installations
that would not let my apps compile).
Andres
Stefano Zacchiroli
> Andres Varon wrote:
>> Thanks for the good work. I would like to know exactly what
>> architectures support the native Dynlink? I did not see this
>> information in the release notes.
> The native Dynlink is known to work under Linux x86, Linux AMD64, Win32
> (mingw/msvc ports). It has been lightly tested under Win64, some flavors
> of BSDs and also the Cygwin port.
[ Sorry for being lazy to check by myself, but apparently the question
is of wide-interest. ]
Is that something that packagers should worry about or not? I mean,
the specific modules/libraries/... are already detected by configure
and not built/installed/... on architectures missing them or should we
(packages) enforce that?
Many thanks in advance (and for native Dynlink of course :-))!
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'č sempre /oo\ All one has to do is hit the right
uno zaino -- A.Bergonzoni \__/ keys at the right time -- J.S.Bach
Jaap Boender
> We are pleased to celebrate the birthday of Friedrich Nietzsche
> by releasing OCaml version 3.11.0+beta1. We need YOU to test
> it thoroughly and report any problems you might have. Does
> your favorite software work with it?
For ease of testing, I've very quickly updated the FreeBSD port (lightly
tested, as in "it seems to work for me"). It is available at
http://www.pps.jussieu.fr/~boender/ocamlport.tar.gz (to be untarred at the
root of your ports tree).
Have fun,
Jaap Boender
--
On two occasions I have been asked [by members of Parliament!], "Pray, Mr.
Babbage, if you put into the machine wrong figures, will the right answers
come out?" I am not able rightly to apprehend the kind of confusion of
ideas that could provoke such a question.
-- Charles Babbage
Alain Frisch
> And on macosx ? It seems here on 10.5.5 that only dynlink.cma and
> dynlink.cmi for bytecode get installed. So I guess there's no support.
> What about the future ?
Native dynlink used to work on Mac OS X < 10.5 (x86 only). The new
linker in 10.5 does not support linking shared libraries with non-PIC
code. It is still possible to use the old linker, called ld_classic, but
some libraries (like X11) does not work, so this has been disabled in
the configure script.
The clean solution to make natdynlink work on recent Mac OS X systems
(beside convincing Apple to support the old behavior of their linker in
their new implementation) is to change OCaml's x86 backend so that it
produces only PIC code (this has been done for the AMD64 port). I don't
think there is currently any plan to work on that.
Alain
Alain Frisch
> One more question: is it always compiled? or is dynlink.cmxa simply not
> available in some architectures? if yes, what are those?
As far as I can tell, dynlink.cmxa is always compiled. You will get
error when "ocamlopt -shared" on those architecture where natdynlink is
not supported.
Andres Varon
On Oct 15, 2008, at 11:37 AM, Alain Frisch wrote:
> Andres Varon wrote:
>> One more question: is it always compiled? or is dynlink.cmxa simply
>> not available in some architectures? if yes, what are those?
>
> As far as I can tell, dynlink.cmxa is always compiled. You will get
> error when "ocamlopt -shared" on those architecture where natdynlink
> is not supported.
OK. Would you recommend that configure scripts use this test to verify
if the functionality is supported?
Andres
Alain Frisch
> OK. Would you recommend that configure scripts use this test to verify
> if the functionality is supported?
Yes.
Andres Varon
On Oct 15, 2008, at 11:32 AM, Alain Frisch wrote:
> Daniel Bünzli wrote:
>> And on macosx ? It seems here on 10.5.5 that only dynlink.cma and
>> dynlink.cmi for bytecode get installed. So I guess there's no
>> support. What about the future ?
>
> Native dynlink used to work on Mac OS X < 10.5 (x86 only). The new
> linker in 10.5 does not support linking shared libraries with non-
> PIC code. It is still possible to use the old linker, called
> ld_classic, but some libraries (like X11) does not work, so this has
> been disabled in the configure script.
>
>
> The clean solution to make natdynlink work on recent Mac OS X systems
> (beside convincing Apple to support the old behavior of their linker
> in their new implementation) is to change OCaml's x86 backend so
> that it produces only PIC code (this has been done for the AMD64
> port). I don't think there is currently any plan to work on that.
Ouch, this makes it almost a dead end for us. I can offer some time to
help in this effort, working in the port, or providing feedback. The
native dynlink and toplevel are, at least to me, the killer features
in 3.11, but adding another hole for Mac OS X intel (in addition to
not supporting x86_64) does not seem like the best choice for an
increasingly popular architecture.
Again, thanks for the good work!
Andres
Xavier Leroy
>> linker in 10.5 does not support linking shared libraries with non-PIC
>> code. It is still possible to use the old linker, called ld_classic,
>> but some libraries (like X11) does not work, so this has been disabled
>> in the configure script.
>>
>> The clean solution to make natdynlink work on recent Mac OS X systems
>> (beside convincing Apple to support the old behavior of their linker
>> in their new implementation) is to change OCaml's x86 backend so that
>> it produces only PIC code (this has been done for the AMD64 port). I
>> don't think there is currently any plan to work on that.
>
> Ouch, this makes it almost a dead end for us. I can offer some time to
> help in this effort, working in the port, or providing feedback. The
> native dynlink and toplevel are, at least to me, the killer features in
> 3.11, but adding another hole for Mac OS X intel (in addition to not
> supporting x86_64) does not seem like the best choice for an
> increasingly popular architecture.
Well, we'd very much like to support native dynlink on OS X 10.5,
but Apple is not helping in the least by crippling their linker
compared with the one in 10.4. If anyone from Apple is on this list,
feel free to contact us at caml-...@yquem.inria.fr for more
information on this regression.
- Xavier Leroy
Daniel Bünzli
Le 15 oct. 08 à 17:27, Andres Varon a écrit :
>>> The native Dynlink is known to work under Linux x86, Linux AMD64,
>>> Win32 (mingw/msvc ports). It has been lightly tested under Win64,
>>> some flavors of BSDs and also the Cygwin port.
>>
>> And on macosx ? It seems here on 10.5.5 that only dynlink.cma and
>> dynlink.cmi for bytecode get installed. So I guess there's no
>> support. What about the future ?
>
> It was installed here: Mac OS X 10.5.5 x86. Maybe this is an issue
> that I mentioned before in the list and got no response?: At least
> one cmxa only get installed if you make opt.opt. camlp4fulllib.cmxa
> was not installed with only make opt (which led to broken
> installations that would not let my apps compile).
In fact it was compiled but not installed. I'm using fastword.sh on
10.5.5. x86 and it seems install.sh doesn't install dynlink.cmxa and
dynlink.mli
Best,
Richard Jones
> We are pleased to celebrate the birthday of Friedrich Nietzsche
> by releasing OCaml version 3.11.0+beta1. We need YOU to test
> it thoroughly and report any problems you might have. Does
> your favorite software work with it?
Excellent news. For Fedora we'll probably leave this until Fedora 11,
which should begin in a week or two.
Rich.
--
Richard Jones
Red Hat
Andres Varon
I'm glad to report that I just tried with XCode 3.1.1 and the linker
did not complain (as it did with XCode 3.0). I wrote a little test and
the native Dynlink worked with that version of XCode (using 10.5.5,
Intel -- I had to drop an -I flag in the linker call from the OCaml
compiler when I was trying it).
Andres
David Allsopp
Windows Vista not included in the list because it's not supported or because
it's not been tested with it?
David
David Allsopp
MinGW build).
Very much looking forward to adding plug-in support back into two products
now that native Dynlink is available so many thanks to the OCaml team for
the work on this release!
Both the MSVC and MinGW ports seem to have an error in the Makefile -
they're linking against tk83.dll and tcl83.dll - the OCaml 3.10.2 line to
link against tk84.lib and tcl84.lib is commented out.
Changing the Makefile to link against tk84.dll and tcl84.dll seems to fix
the problem.
David
-----Original Message-----
From: caml-lis...@yquem.inria.fr
[mailto:caml-lis...@yquem.inria.fr] On Behalf Of Damien Doligez
Sent: 15 October 2008 15:40
To: caml users
Subject: [Caml-list] OCaml version 3.11.0+beta1
David Allsopp
flexdll for Win32 building OCaml 3.11? I copied flexdll.h,
flexdll_initer_mingw.o, flexdll_mingw.o and flexlink.exe to my (empty) OCaml
bin directory (C:\Dev\OCaml\bin which is in PATH) before starting to build
which seemed to allow things to work.
[Aside: As I don't expect to use flexdll for anything else, the OCaml bin
directory seems as good a place as any to put it - I, out of personal
choice, put development tools in C:\Dev rather than C:\Program Files]
The install target of flexdll's Makefile suggests copying:
flexdll_initer.c, flexdll.c
Surely these aren't needed once it's compiled?
cmdline.o, coff.o, reloc.o, version.o
Aren't these all part of flexlink.exe and therefore not needed?
default.manifest
Is this necessary for a MinGW build?
There seems to be an interesting chicken-and-egg source dependency between
flexdll and OCaml 3.11 - you can't build OCaml 3.11 from source or use it
afterwards without flexdll and you can't build flexdll from source without
OCaml. Doesn't that suggest a binary copy of flexdll should be included in
OCaml's boot directory? All of the other *binary* dependencies for Windows
OCaml don't require OCaml themselves... just a thought!
There are now some documentation inconsistencies in the sections for linking
C code - but I'll finish working through the various libraries I use before
reporting back. It's great that ocamlmklib is now available for all ports on
Win32 as well (that's one typo in manual032!) as it means that most of my
broken calls to gcc (rather than flexlib) can be replaced with the much more
portable ocamlmklib anyway!
Is there a useful way of submitted patches to the documentation? The HTML
docs are all generated from something, right?
David
-----Original Message-----
From: caml-lis...@yquem.inria.fr
[mailto:caml-lis...@yquem.inria.fr] On Behalf Of Damien Doligez
Sent: 15 October 2008 15:40
To: caml users
Subject: [Caml-list] OCaml version 3.11.0+beta1
Alain Frisch
> The install target of flexdll's Makefile suggests copying:
>
> flexdll_initer.c, flexdll.c
> Surely these aren't needed once it's compiled?
Indeed. However, some people might want to recompile them (e.g. to keep
debug symbols, or to use a specific version of their C compiler).
>
> cmdline.o, coff.o, reloc.o, version.o
> Aren't these all part of flexlink.exe and therefore not needed?
As far as I can tell, the install target does not copy these files.
> default.manifest
> Is this necessary for a MinGW build?
No.
> There seems to be an interesting chicken-and-egg source dependency between
> flexdll and OCaml 3.11 - you can't build OCaml 3.11 from source or use it
> afterwards without flexdll and you can't build flexdll from source without
> OCaml. Doesn't that suggest a binary copy of flexdll should be included in
> OCaml's boot directory? All of the other *binary* dependencies for Windows
> OCaml don't require OCaml themselves... just a thought!
You're right about the circular dependency, but the answer is much
simpler than for the chicken-and-egg question: OCaml came first.
I don't see a compelling reason to include a binary version of flexdll
in the OCaml distribution. Just consider flexdll as an external
dependency that comes in binary form (like the MS C compiler). It just
happens to be produced by the OCaml compiler.
Note that flexlink.exe can be compiler with an old OCaml compiler. Also,
if you insist to bootstrap everything, it shouldn't be too difficult to
get a minimal (=no dynamic linking of external C code) ocamlrun.exe for
3.11 that does not require flexlink.
-- Alain
Adrien
> David Allsopp wrote:
>> There seems to be an interesting chicken-and-egg source dependency between
>> flexdll and OCaml 3.11 - you can't build OCaml 3.11 from source or use it
>> afterwards without flexdll and you can't build flexdll from source without
>> OCaml. Doesn't that suggest a binary copy of flexdll should be included in
>> OCaml's boot directory? All of the other *binary* dependencies for Windows
>> OCaml don't require OCaml themselves... just a thought!
>
> You're right about the circular dependency, but the answer is much
> simpler than for the chicken-and-egg question: OCaml came first.
> I don't see a compelling reason to include a binary version of flexdll
> in the OCaml distribution. Just consider flexdll as an external
> dependency that comes in binary form (like the MS C compiler). It just
> happens to be produced by the OCaml compiler.
>
> Note that flexlink.exe can be compiler with an old OCaml compiler. Also,
> if you insist to bootstrap everything, it shouldn't be too difficult to
> get a minimal (=no dynamic linking of external C code) ocamlrun.exe for
> 3.11 that does not require flexlink.
>
How often should we expect new releases of flexlink ? Basically, the
question is : will it have to be updated from time to time or can we
just drop it somewhere and forget everything about it ?
---
Adrien Nader
Alain Frisch
> How often should we expect new releases of flexlink ? Basically, the
> question is : will it have to be updated from time to time or can we
> just drop it somewhere and forget everything about it ?
There will be new releases when bugs are found and fixed. It's hard to
predict. I don't expect any correlation between OCaml releases and new
flexlink versions.
-- Alain
Andres Varon
On Oct 16, 2008, at 5:58 AM, David Allsopp wrote:
> Both the MSVC and MinGW ports seem to have an error in the Makefile -
> they're linking against tk83.dll and tcl83.dll - the OCaml 3.10.2
> line to
> link against tk84.lib and tcl84.lib is commented out.
>
> Changing the Makefile to link against tk84.dll and tcl84.dll seems
> to fix
> the problem.
Did you manage to do it with *.dll or *.lib? I don't have those dll's
and have been unable to compile the MinGW port with a setup that
succeeded since 3.09.3. I keep getting:
Cannot export tcl84_NULL_THUNK_DATA: symbol not found
Could it be a path issue? Could you please show me an example of the a
path that you are using successfully?
Andres
Andres Varon
On Oct 16, 2008, at 12:22 PM, Andres Varon wrote:
>
> On Oct 16, 2008, at 5:58 AM, David Allsopp wrote:
>
>> Both the MSVC and MinGW ports seem to have an error in the Makefile -
>> they're linking against tk83.dll and tcl83.dll - the OCaml 3.10.2
>> line to
>> link against tk84.lib and tcl84.lib is commented out.
>>
>> Changing the Makefile to link against tk84.dll and tcl84.dll seems
>> to fix
>> the problem.
>
> Did you manage to do it with *.dll or *.lib? I don't have those
> dll's and have been unable to compile the MinGW port with a setup
> that succeeded since 3.09.3. I keep getting:
>
> Cannot export tcl84_NULL_THUNK_DATA: symbol not found
>
> Could it be a path issue? Could you please show me an example of the
> a path that you are using successfully?
Let me clarify what I'm asking: I have in config/Makefile
TK_ROOT=c:/tcl
Do you write your paths somehow differently there? In all honesty I
don't think that this is a wrongly written path (there are no
complains of not finding the libraries), but I'm clueless and I don't
have enough experience in Windows.
best,
Andres
Andres Varon
On Oct 16, 2008, at 12:31 PM, Andres Varon wrote:
>>> Changing the Makefile to link against tk84.dll and tcl84.dll seems
>>> to fix
>>> the problem.
>>
>> Did you manage to do it with *.dll or *.lib? I don't have those
>> dll's and have been unable to compile the MinGW port with a setup
>> that succeeded since 3.09.3. I keep getting:
>>
>> Cannot export tcl84_NULL_THUNK_DATA: symbol not found
>>
>> Could it be a path issue? Could you please show me an example of
>> the a path that you are using successfully?
>
To answer myself: the path is not anymore lib/tcl84.lib but bin/
tcl84.dll and correspondingly to tk. Sorry for the noise.
Xavier Leroy
> The Win64 port is listed as requiring Windows XP 64 or Server 64 - is 64 bit
> Windows Vista not included in the list because it's not supported or because
> it's not been tested with it?
Because it hasn't been tested with Vista 64. But I'm pretty sure that
if Microsoft's PSDK for x86-64 works well on Vista 64, so should
OCaml.
- Xavier Leroy