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 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.
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
> 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])
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.
> 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.
> 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.
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.
> 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?
> 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 ?
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).
On Wed, Oct 15, 2008 at 05:04:46PM +0200, 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.
[ 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
On Wednesday 15 October 2008 15:40:01 Damien Doligez wrote:
> 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
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.
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.
> 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?
> 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.
>> 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.
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-de...@yquem.inria.fr for more information on this regression.
>>> 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
On Wed, Oct 15, 2008 at 03:40:01PM +0200, Damien Doligez wrote: > 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.
>>> 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.
> 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-de...@yquem.inria.fr for more > information on this regression.
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).
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?
[mailto:caml-list-boun...@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
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?
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.
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
I'm slowly testing my stuff on WinXP SP2 and will do Windows Vista SP1 (both 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.
[mailto:caml-list-boun...@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
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?
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.
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
Apologies if I missed them, but are there any installation instructions for 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?
[mailto:caml-list-boun...@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
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?
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.
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
David Allsopp wrote: > 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.
> 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 wrote: > 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.
> 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?
|
