Re: [Caml-list] ocamlmklib on Windows

[Jerome Simeon <simeon@research.bell-labs.com>]

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