Re: [Caml-list] ocamlmklib on Windows

[Dmitry Bely <dbely@mail.ru>]

Xavier Leroy <xavier.leroy@inria.fr>  writes:

>> Has anyone successfully compiled ocamlmklib on Windows? I'd like to
>> build a Windows native port of camlimages, but lack of this program in
>> the basic distribution is stopping me.
>
> There's a mismatch between the ocamlmklib approach and Windows DLLs
> that has prevented me so far from making the former work with the
> latter.
>
> Basically, ocamlmklib assumes that, from the *same* set of object C
> files, one can build both
> - a static library that can be statically linked with the Caml runtime system
>   and the application, and
> - a shared library (DLL) that can be dynamically linked with the Caml
>   runtime system and the application.
>
> This does *not* appear to be the case for Windows.  Namely, a static
> lib that accesses a global variable defined in the Caml runtime system
> does this directly, while a DLL must do it through one additional
> indirection.  Thus, the code for the library must be compiled differently
> (using / not using "__declspec(dllimport)" specifiers) depending on
> whether it is to be put in a static library or in a DLL.  With the
> Mingw toolchain, it seems possible to generate code that works in both
> contexts, but I was unable to do this with the MSVC toolchain.

That don't seems to be correct. Dynamic and static libs can be linked
with any Win32 compiler from the same set of object files. To illustrate
this, just let me quote myself (BTW, I hadn't got a reply):

[---cut---]
From: Dmitry Bely <dbely@mail.ru>
To: Xavier Leroy <xavier.leroy@inria.fr>
Subject: Re: [Caml-list] ocamlmklib missing in win32 ?
Date: Wed, 11 Sep 2002 23:47:26 +0400

<...>

> My impression was that if you do
>
> __declspec(dllimport) extern int x;
>
> in one of your files, and then link it *statically* against a file
> that defines x as
>
> __declspec(dllexport) int x;
>
> you'd get an error.

If I understand it correctly, no. __declspec(dllexport) is an instruction
to linker, not compiler. Moreover, you can substitute __declspec(dllexport)
with the proper .def file, not even giving any hint to the compiler. OK,
let's test your example:

[--- lib.c ---]
__declspec(dllexport) int x;
[--- end of lib.c ---]

[--- dll.c ---]
#include <windows.h>
BOOL WINAPI DllMain( HANDLE hdll,
                     DWORD  reason,
                     LPVOID reserved )
{
  return TRUE;
}
[--- end of dll.c ---]

[--- main.c ---]
#include <stdio.h>
__declspec(dllimport) extern int x;

int main()
{
  x = 1;
  printf("%d", x);
  return 0;
}
[--- end of main.c ---]


cl -c -MD lib.c

# static linking
cl -MD main.c lib.obj
# LINK : warning LNK4049: locally defined symbol "_x" imported
# but main.exe still works (the warhing can be supressed)

# dynamic linking; create the DLL first
cl -LD -MD dll.c lib.obj
cl -MD main.c dll.lib
# main.exe works

Note that we have used the same lib.obj for both dynamic and static version.

To get rid of the linker warning, we should switch between
"_declspec(dllimport) extern int x" and "extern int x" in our header files
depending on which library (dynamic or static) we are linking
with. Obviously, it does not affect the object files, which the library is
build from.

> I might have misunderstood something, though, and
> indeed this would open the way to simplifications in the OCaml/Win32
> port.

I also may misunderstood something, but hope that we will finally find the
truth :-)

- Dmitry Bely
[---cut---]

> So, no ocamlmklib under Windows.

It's a pity because it looks like to be possible.

> Still, you can look at some of the
> Win32 makefiles in the OCaml source distribution for examples of how
> to build mixed C/Caml libraries under Windows.  (Look at
> otherlibs/win32unix/Makefile.nt for instance.)

- Dmitry Bely


-------------------
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