[Caml-list] ocamlmklib on Windows

[Caml-list] ocamlmklib on Windows

[Richard Jones]

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.

For reference, it needs ar and tries to build libfoo.a files, which
presumably aren't going to work on Windows.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
"I wish more software used text based configuration files!"
 -- A Windows NT user, quoted on Slashdot.

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

Re: [Caml-list] ocamlmklib on Windows

[Xavier Leroy]

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

So, no ocamlmklib under Windows.  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.)

- Xavier Leroy

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

Re: [Caml-list] ocamlmklib on Windows

[Richard Jones]

On Thu, Jul 17, 2003 at 10:37:55PM +0200, Xavier Leroy wrote:
> 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 is surely similar to the need for compiling C object files with
-fPIC/-fpic under Linux if they are to become DLLs. Of course you
/can/ compile without this flag, but as I understand it, if you do so
you get shared libraries which aren't shared very effectively.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
 All new technology is irrelevant until it is taken up by the public.

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

Re: [Caml-list] ocamlmklib on Windows

[Xavier Leroy]

> This is surely similar to the need for compiling C object files with
> -fPIC/-fpic under Linux if they are to become DLLs. 

The Windows issue is much worse than this.  An object file compiled
with -fpic can be linked statically just fine.  The code generated
with -fpic might be slightly less efficient, but behaves the same.
So, the same object files can be shared between a static lib and a
DLL.  Not so under Windows.

- Xavier Leroy

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

Re: [Caml-list] ocamlmklib on Windows

[Dmitry Bely]

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

Re: [Caml-list] ocamlmklib on Windows

[Xavier Leroy]

> 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

At least with the version of VC++ I use, your example stops working
when you put the .obj files *in a static library* (which is the point
of the exercise):

  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)
  # static linking via a static lib
  lib /out:staticlib.lib lib.obj
  cl -MD main.c staticlib.lib
  # main.obj : error LNK2001: unresolved external symbol __imp__x
  # main.exe : fatal error LNK1120: 1 unresolved externals

If you know how to work around this, that'd be great.  I'd suggest we
take this discussion off caml-list, though, as DLL hackery is getting
out of topic.

- Xavier Leroy

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

Re: [Caml-list] ocamlmklib on Windows

[Jerome Simeon]

I would be interested to follow the discussion. DLL/Dynamic linking is
currently one of the main problem we have in Galax.

Our (surprisingly ambitious) goal was to to wrap Caml code transparently
behind a C/C++/Java API. The Java part requires dynamic linking. Here
were our results so far:

 (1) Things worked ok on Linux and on most other Unix-gcc based systems
we tried, although finding the right compiler flags was sometime tricky
(why on earth is the '-mimpure-text' needed under Solaris?).

 (2) It took us more than two weeks to get some dynamic linking going
with the MinGW port of Caml, and it only worked so far with the bytecode
runtime. I'm still trying to figure out what goes wrong for the
nativecode. I was starting to think we should try with the VC++ port,
but the current discussion seems to indicate its another big mess.

 (3) Dynamic linking does not work under MacOS X.

Any chance of things improving in the near future? My dream would be
some kind of compilation magic to wrap Caml inside a C dynamic library,
but improvements on (2) and (3) above would already be a big help.

Thanks,
- Jerome Simeon

On Fri, 2003-07-18 at 12:18, Xavier Leroy wrote:
> > 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
> 
> At least with the version of VC++ I use, your example stops working
> when you put the .obj files *in a static library* (which is the point
> of the exercise):
> 
>   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)
>   # static linking via a static lib
>   lib /out:staticlib.lib lib.obj
>   cl -MD main.c staticlib.lib
>   # main.obj : error LNK2001: unresolved external symbol __imp__x
>   # main.exe : fatal error LNK1120: 1 unresolved externals
> 
> If you know how to work around this, that'd be great.  I'd suggest we
> take this discussion off caml-list, though, as DLL hackery is getting
> out of topic.
> 
> - Xavier Leroy
> 
> -------------------
> 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
-- 
Jerome Simeon <simeon@research.bell-labs.com>

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