[cwn] Attn: Development Editor, Latest Caml Weekly News

[Alan Schmitt]

Hello,

Here is the latest Caml Weekly News, for the week of September 01 to 08,
2009.

1) Dynamic loading of native code : what about librairies and packs ?
2) Windows Vista/7 specific functions
3) Documentation to start
4) Camomile library tutorial/examples?
5) OCaml on Android
6) ocamlfind and GODI packaging sprint this Wednesday, 9/9
7) Other Caml News

========================================================================
1) Dynamic loading of native code : what about librairies and packs ?
Archive: <
http://groups.google.com/group/fa.caml/browse_thread/thread/cf68c5465cda89ed/9c767ce0eec07e0b
>
------------------------------------------------------------------------
** Continuing this old thread, Pierre-Loïc Garoche asked:

I am still having some problems with the dynamic loading of native code.
Allow
me to give you an extremely simple example to illustrate my problem. I hope
you can clarify my understanding of it.

My problem concerns the dynamic loading of native code where the dynamic
code
loaded depends on another library.

Basically there are three files:
- main.ml, dynamically loading the plugin
- plugin.ml, the loaded code that depends on the external lib
- mylib.ml, the external lib

///////
main.ml:
let _ = print_string "main\n"
let _ = Dynlink.loadfile "MyPlugin.cmxs"

compiled with ocamlopt -o MyProg dynlink.cmxa main.ml

///////
mylib.ml:
let _ = print_string "mylib\n"
let myval : (int , int) Hashtbl.t = Hashtbl.create 13

compiled with ocamlopt -a -linkall -o mylib.cmxa mylib.ml

//////
plugin.ml:
let _ = print_string "plugin\n"
let cst = Mylib.myval

compiled and linked to build a shared library with
ocamlopt -shared -linkall -o MyPlugin.cmxs mylib.cmxa plugin.ml

Running it gives me the following error
error loading shared library: blabla/MyPlugin.cmxs: undefined symbol:
camlHashtbl__create_79


Remark1 : Of course, building a standalone plugin works:
ocamlopt -o PluginSelf mylib.cmxa plugin.cmx

Remark2: If I don't rely on an external module and replace myval by an
integer
or any other self defined type value, it works as well.

Remark3: The linkall option does not seems to have an impact on such simple
example.


Question: How should I link it to rely on external libraries and produce a
valid MyPlugin.cmxs ?

Any hint or comment will be greatly appreciated !

** Christophe Troestler suggested:

You should reference « Hashtbl » in your main program :

 main.ml:
 module ForLinking_1 = Hashtbl
 let () = print_string "main\n"
 let () = Dynlink.loadfile "MyPlugin.cmxs"

BTW, if you want your program to work in both bytecode and native
code, you should use:

 Dynlink.loadfile (Dynlink.adapt_filename "MyPlugin.cmo")

** Alain Frisch also added:

You need to ensure that the main program is linked with all the modules that
are needed by the dynamically loaded modules (including the modules from the
standard library). Linking the main program with -linkall should solve your
problem.

========================================================================
2) Windows Vista/7 specific functions
Archive: <
http://groups.google.com/group/fa.caml/browse_thread/thread/0f878746f238e961#
>
------------------------------------------------------------------------
** Reed Wilson asked:

I am going to be writing a native-code 64-bit program which takes advantage
of
some Windows Vista-only features (transactional NTFS), and I was wondering
how
to get it working in OCaml. I have made numerous interfaces to Windows XP
functions, but the problem is that the NTFS transactional functions are only
available through MSVS 2008 and the Vista/7 SDKs, which OCaml seems to not
compile with. I tried using the new Windows 7 SDK tools to compile the
program
to native code, but it kept giving me errors with not being able to find
bufferoverflowu.lib.

Does anybody know if there is any way to compile a 64-bit OCaml with the
newer
Windows SDKs, or failing that, to at least tell OCaml how to properly link
things with them?

** David Allsopp replied:

Having hacked away with the Win64 port before I thought I?d have a go. The
first thing I noticed is that Microsoft have finally released the x86 and
x64
compilers in the same package (this was a pain if you wanted to build MSVC
and
MSVC64 ports as you needed two SDKs to do it...) ? though I haven?t tried
building the 32-bit MSVC port from this SDK yet.

Here?s what I did (you?ll have to excuse my idiosyncratic way of copying
binary files into the OCaml tree ? these can be replaced with PATH changes
if
you want. I copy things around so that ocamlopt always works without needing
a
special build environment or vast compiler suites permanently in my PATH).

The build is slightly complicated because you need to build flexdll
directly.

Make sure you have Cygwin base with with Devel\make and Devel\subversion
added

I installed the Win7 SDK to C:\Dev\WinSDK (though it still irritatingly puts
the compilers in C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC). I
didn?t bother installing Documentation, Samples or the IA64 libraries.

Add the following to your LIB environment variable:
  C:\Program Files (x86)\Microsoft Visual Studio
9.0\VC\lib\amd64;C:\Dev\WinSDK\lib\x64

Add the following to your INCLUDE environment variable:
  C:\Program Files (x86)\Microsoft Visual Studio
9.0\vc\include;C:\Dev\WinSDK\Include

Set OCAMLLIB to C:\Dev\OCaml-MSVC64\lib

A whole load of files now get copied to C:\Dev\OCaml-MSVC64\bin: