linking ocaml in multithreaded shared dll app

linking ocaml in multithreaded shared dll app

[Charles Neveu]

I'm trying to link the ocaml library into a Windows NT 4.0, MS VC++ 6.0
application that uses MFC in a shared dll (because another library,
OpenInventor, has to be linked this way).
I'm getting an unresolved external symbol error for the symbols
__pctype, ___mb_cur_max, and __dosmaperr from files like win32.obj,
read.obj, write.obj, etc. (complete text at bottom). 

I'm not a MSVC++ expert, but I'm guessing that the libunix library is
compiled to be linked with a statically-linked MFC library. Is this
right? Is there anyway to compile it to link to a dynamically-linked MFC
library?

Or is there something else going on?

Charles

Here is the linker output (ignore the first few Maestro errors, I'm
porting that):
--------------------Configuration: talkdll - Win32
Debug--------------------
Compiling...
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
cl /MDd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D
"_MBCS" /D "_AFXDLL" /Fp"Debug/talkdll.pch" /Yc"stdafx.h" /Fo"Debug/"
/Fd"Debug/" /FD /GZ /c 
   "E:\neveu\Development\talkdll\StdAfx.cpp"
StdAfx.cpp
Note: reusing persistent precompiled header 
Compiling...
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for
80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
cl /MDd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D
"_MBCS" /D "_AFXDLL" /Fp"Debug/talkdll.pch" /Yu"stdafx.h" /Fo"Debug/"
/Fd"Debug/" /FD /GZ /c 
   "E:\neveu\Development\talkdll\Mbr.cpp"
   "E:\neveu\Development\talkdll\talkdll.cpp"
   "E:\neveu\Development\talkdll\talkdllDlg.cpp"
Skipping... (no relevant changes detected)
Mbr.cpp
talkdll.cpp
talkdllDlg.cpp
Linking...
msvcirtd.lib(MSVCIRTD.dll) : error LNK2005: "public: class ostream &
__thiscall ostream::operator<<(class ostream & (__cdecl*)(class ostream
&))" (??6ostream@@QAEAAV0@P6AAAV0@AAV0@@Z@Z) already defined in
libmae-nt.lib(Maestro_Types.obj)
msvcirtd.lib(MSVCIRTD.dll) : error LNK2005: "class ostream & __cdecl
endl(class ostream &)" (?endl@@YAAAVostream@@AAV1@@Z) already defined in
libmae-nt.lib(Maestro_Types.obj)
libmae-nt.lib(Maestro_GroupMember.obj) : error LNK2001: unresolved
external symbol "class ostream_withassign  cerr"
(?cerr@@3Vostream_withassign@@A)
libmae-nt.lib(Maestro_GroupMember.obj) : error LNK2001: unresolved
external symbol "class ostream_withassign  cout"
(?cout@@3Vostream_withassign@@A)
libmae-nt.lib(win32.obj) : error LNK2001: unresolved external symbol
__pctype
libmae-nt.lib(win32.obj) : error LNK2001: unresolved external symbol
___mb_cur_max
libmae-nt.lib(read.obj) : error LNK2001: unresolved external symbol
__dosmaperr
libmae-nt.lib(write.obj) : error LNK2001: unresolved external symbol
__dosmaperr
libmae-nt.lib(close_on.obj) : error LNK2001: unresolved external symbol
__dosmaperr
libmae-nt.lib(createprocess.obj) : error LNK2001: unresolved external
symbol __dosmaperr
libmae-nt.lib(spawn-nt.obj) : error LNK2001: unresolved external symbol
__dosmaperr
libmae-nt.lib(dup.obj) : error LNK2001: unresolved external symbol
__dosmaperr
libmae-nt.lib(lseek.obj) : error LNK2001: unresolved external symbol
__dosmaperr
libmae-nt.lib(open.obj) : error LNK2001: unresolved external symbol
__dosmaperr
libmae-nt.lib(close.obj) : error LNK2001: unresolved external symbol
__dosmaperr
libmae-nt.lib(dup2.obj) : error LNK2001: unresolved external symbol
__dosmaperr
libmae-nt.lib(pipe.obj) : error LNK2001: unresolved external symbol
__dosmaperr
libmae-nt.lib(winwait.obj) : error LNK2001: unresolved external symbol
__dosmaperr
libmae-nt.lib(envir.obj) : error LNK2001: unresolved external symbol
__environ
libmae-nt.lib(execvp.obj) : error LNK2001: unresolved external symbol
__environ
Debug/talkdll.exe : fatal error LNK1120: 6 unresolved externals
Error executing link.exe.

talkdll.exe - 21 error(s), 0 warning(s)

-- 
Dr. Charles Frederick Neveu     T: 650 604-2525
Autonomy and Robotics Group     F: 650 604-4036
NASA Ames Research Center       E: neveu@artemis.arc.nasa.gov
Mail Stop 269-4                 W: http://img.arc.nasa.gov/~neveu
Moffett Field, CA 94035-1000

RE: linking ocaml in multithreaded shared dll app

[Lionel Fourquaux]

> -----Message d'origine-----
> De : Pierre.Weis@inria.fr [mailto:Pierre.Weis@inria.fr]De la part de
> Charles Neveu
> Envoye : mardi 7 novembre 2000 20:19
> A : caml-list@inria.fr
> Objet : linking ocaml in multithreaded shared dll app
>
>
> I'm trying to link the ocaml library into a Windows NT 4.0,
> MS VC++ 6.0
> application that uses MFC in a shared dll (because another library,
> OpenInventor, has to be linked this way).
> I'm getting an unresolved external symbol error for the symbols
> __pctype, ___mb_cur_max, and __dosmaperr from files like win32.obj,
> read.obj, write.obj, etc. (complete text at bottom).

	That's because you're linking with msvcrt.dll (DLL version of
Microsoft's C runtime). OCaml is linked with libcmt.lib (static
multithreaded
version of the same).


>
> I'm not a MSVC++ expert, but I'm guessing that the libunix library is
> compiled to be linked with a statically-linked MFC library. Is this
> right? Is there anyway to compile it to link to a
> dynamically-linked MFC
> library?

	Not exactly. OCaml doesn't use MFC. The problem is with the C library.
Moreover, you can't build the libunix library for linking with msvcrt.dll,
because it uses the internal function _dosmaperr, which is not exported by
the DLL.


>
> Or is there something else going on?
>
> Charles
>
> Here is the linker output (ignore the first few Maestro errors, I'm
> porting that):
> --------------------Configuration: talkdll - Win32
> Debug--------------------
> Compiling...
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for
> 80x86
> Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
> cl /MDd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D
     ^^^^

	This should be /MT. (See the documentation of the compiler.)


> "_MBCS" /D "_AFXDLL" /Fp"Debug/talkdll.pch" /Yc"stdafx.h" /Fo"Debug/"
> /Fd"Debug/" /FD /GZ /c
>    "E:\neveu\Development\talkdll\StdAfx.cpp"
> StdAfx.cpp
> Note: reusing persistent precompiled header
> Compiling...
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for
> 80x86
> Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
> cl /MDd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D
> "_MBCS" /D "_AFXDLL" /Fp"Debug/talkdll.pch" /Yu"stdafx.h" /Fo"Debug/"
> /Fd"Debug/" /FD /GZ /c
>    "E:\neveu\Development\talkdll\Mbr.cpp"
>    "E:\neveu\Development\talkdll\talkdll.cpp"
>    "E:\neveu\Development\talkdll\talkdllDlg.cpp"
> Skipping... (no relevant changes detected)
> Mbr.cpp
> talkdll.cpp
> talkdllDlg.cpp
> Linking...
> msvcirtd.lib(MSVCIRTD.dll) : error LNK2005: "public: class ostream &
> __thiscall ostream::operator<<(class ostream &
> (__cdecl*)(class ostream
> &))" (??6ostream@@QAEAAV0@P6AAAV0@AAV0@@Z@Z) already defined in
> libmae-nt.lib(Maestro_Types.obj)
> msvcirtd.lib(MSVCIRTD.dll) : error LNK2005: "class ostream & __cdecl
> endl(class ostream &)" (?endl@@YAAAVostream@@AAV1@@Z) already
> defined in
> libmae-nt.lib(Maestro_Types.obj)
> libmae-nt.lib(Maestro_GroupMember.obj) : error LNK2001: unresolved
> external symbol "class ostream_withassign  cerr"
> (?cerr@@3Vostream_withassign@@A)
> libmae-nt.lib(Maestro_GroupMember.obj) : error LNK2001: unresolved
> external symbol "class ostream_withassign  cout"
> (?cout@@3Vostream_withassign@@A)
> libmae-nt.lib(win32.obj) : error LNK2001: unresolved external symbol
> __pctype
> libmae-nt.lib(win32.obj) : error LNK2001: unresolved external symbol
> ___mb_cur_max
> libmae-nt.lib(read.obj) : error LNK2001: unresolved external symbol
> __dosmaperr
> libmae-nt.lib(write.obj) : error LNK2001: unresolved external symbol
> __dosmaperr
> libmae-nt.lib(close_on.obj) : error LNK2001: unresolved
> external symbol
> __dosmaperr
> libmae-nt.lib(createprocess.obj) : error LNK2001: unresolved external
> symbol __dosmaperr
> libmae-nt.lib(spawn-nt.obj) : error LNK2001: unresolved
> external symbol
> __dosmaperr
> libmae-nt.lib(dup.obj) : error LNK2001: unresolved external symbol
> __dosmaperr
> libmae-nt.lib(lseek.obj) : error LNK2001: unresolved external symbol
> __dosmaperr
> libmae-nt.lib(open.obj) : error LNK2001: unresolved external symbol
> __dosmaperr
> libmae-nt.lib(close.obj) : error LNK2001: unresolved external symbol
> __dosmaperr
> libmae-nt.lib(dup2.obj) : error LNK2001: unresolved external symbol
> __dosmaperr
> libmae-nt.lib(pipe.obj) : error LNK2001: unresolved external symbol
> __dosmaperr
> libmae-nt.lib(winwait.obj) : error LNK2001: unresolved external symbol
> __dosmaperr
> libmae-nt.lib(envir.obj) : error LNK2001: unresolved external symbol
> __environ
> libmae-nt.lib(execvp.obj) : error LNK2001: unresolved external symbol
> __environ
> Debug/talkdll.exe : fatal error LNK1120: 6 unresolved externals
> Error executing link.exe.
>
> talkdll.exe - 21 error(s), 0 warning(s)
>
> --
> Dr. Charles Frederick Neveu     T: 650 604-2525
> Autonomy and Robotics Group     F: 650 604-4036
> NASA Ames Research Center       E: neveu@artemis.arc.nasa.gov
> Mail Stop 269-4                 W: http://img.arc.nasa.gov/~neveu
> Moffett Field, CA 94035-1000
>


	There are several solutions :
 * if the source is available, build OpenInventor with /MT instead of /MD,
   and use static libs everywhere (including MFC)
 * split your program into several DLLs that uses different versions of
   the C runtime (Be careful with this !)
 * try to build OCaml with /MD, using DOSMAP.C from the CRT source if you
   need libunix.


	And some people from this mailing list will probably suggest better
solutions !


	I hope this will help you.


		Lionel Fourquaux

RE: linking ocaml in multithreaded shared dll app

[Ken Wakita]

In message (<000001c04a50$fbed35c0$b2328aa4@wfr01946>)
from "Lionel Fourquaux" <lionel.fourquaux@wanadoo.fr>,
talking about "RE: linking ocaml in multithreaded shared dll app",
on Thu, 9 Nov 2000 14:28:41 +0100

> > -----Message d'origine-----
> > De : Pierre.Weis@inria.fr [mailto:Pierre.Weis@inria.fr]De la part de
> > Charles Neveu
> > Envoye : mardi 7 novembre 2000 20:19
> > A : caml-list@inria.fr
> > Objet : linking ocaml in multithreaded shared dll app
> >
> >
> > I'm trying to link the ocaml library into a Windows NT 4.0,
> > MS VC++ 6.0
> > application that uses MFC in a shared dll (because another library,
> > OpenInventor, has to be linked this way).
> > I'm getting an unresolved external symbol error for the symbols
> > __pctype, ___mb_cur_max, and __dosmaperr from files like win32.obj,
> > read.obj, write.obj, etc. (complete text at bottom).
> 
> 	That's because you're linking with msvcrt.dll (DLL version of
> Microsoft's C runtime). OCaml is linked with libcmt.lib (static
> multithreaded
> version of the same).

A while ago when Cygwin patch for ocaml was announced in this list, I
tried to use it with the Mingw framework.  Mingw is a version of gcc
targeted for MFC environment.  It allows production of executable that
does not depend on Cygwin but on msvcrt.dll.  This way we can
distribute executable O'Caml binary executables to those who are not
using Cygwin.  I also tried compiling the GTk on Mingw and make
lablgtk package and execute a small lablgtk application.

> > I'm not a MSVC++ expert, but I'm guessing that the libunix library is
> > compiled to be linked with a statically-linked MFC library. Is this
> > right? Is there anyway to compile it to link to a
> > dynamically-linked MFC
> > library?
> 
> 	Not exactly. OCaml doesn't use MFC. The problem is with the C library.
> Moreover, you can't build the libunix library for linking with msvcrt.dll,
> because it uses the internal function _dosmaperr, which is not exported by
> the DLL.

Mingw lacks many of the unix interface provided by the Cynwin.  I
think we need much porting effort to get most of the Unix and Threads
package to work.

Ken Wakita

Re: linking ocaml in multithreaded shared dll app

[Charles Neveu]

Catching up on an old thread: I'm trying to link ocaml in an application
with another library (OpenInventor) which must be linked using the
multithreaded-DLL flavor of the runtime libraries. Ocaml must be linked
using the multithreaded-static library version of the runtime libs. The
OpenInventor vendor says an multithreaded-static version is not an
option. 

So, is it possible to build the ocaml library multithreaded-DLL?

If not, where do I find DOSMAP.C? I've searched my CD's, harddrive and
the net...


Chas

> >
> 
>         There are several solutions :
>  * if the source is available, build OpenInventor with /MT instead of /MD,
>    and use static libs everywhere (including MFC)
>  * split your program into several DLLs that uses different versions of
>    the C runtime (Be careful with this !)
>  * try to build OCaml with /MD, using DOSMAP.C from the CRT source if you
>    need libunix.
> 
>         And some people from this mailing list will probably suggest better
> solutions !
> 
>         I hope this will help you.
> 
>                 Lionel Fourquaux

-- 
Dr. Charles Frederick Neveu     T: 650 604-2525
Autonomy and Robotics Group     F: 650 604-4036
NASA Ames Research Center       E: neveu@artemis.arc.nasa.gov
Mail Stop 269-4                 W: http://img.arc.nasa.gov/~neveu
Moffett Field, CA 94035-1000

Re: linking ocaml in multithreaded shared dll app

[Xavier Leroy]

> So, is it possible to build the ocaml library multithreaded-DLL?

As Lionel Fourquaux said, it should be possible: just replace /MT by
/MD in the source file config/Makefile.nt and rebuild the whole system.

However, there is an issue with the Unix library, which uses an
undocumented C library function _dosmaperr() to convert from Win32
error codes to Unix-style error codes.  This function is not exported
by the DLL version of the MSVC C library.  Yes, it's a stupid mistake
of mine to rely on this function, and I should have reimplemented my
own.

What Lionel suggests is to get the source code for _dosmaperr() from
the MSVC C library sources, recompile it and add it to your code.
Ponder legal issues before doing this, though.

> If not, where do I find DOSMAP.C? I've searched my CD's, harddrive and
> the net...

The MSVC CD should contain (or used to contain) a ZIP file with the
sources for the C run-time library (look for files or directories
called CRT or something like it).  The source code for _dosmaperr() is
somewhere in there.

Good luck,

- Xavier Leroy