[CXX-96] Enforce /MD with Windows C++ DLL driver Created: 05/Mar/12  Updated: 08/Jan/24  Resolved: 21/Apr/14

Status: Closed
Project: C++ Driver
Component/s: None
Affects Version/s: None
Fix Version/s: legacy-0.8.0

Type: Bug Priority: Major - P3
Reporter: Eric Milkie Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: cxxmove, legacy-cxx, windows
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-9770 Allow windows builds to use the dynam... Closed
is related to CXX-60 Default Windows builds of the C++ cli... Closed
is related to CXX-138 For windows builds, consider producin... Closed

 Description   

In order to prevent build mistakes, the C++ driver should ensure that _MD is defined, since we are compiling the shared library with /MD. This ensures that the same C RTL (and thus the same heap) is used across all translation units between the mongo library and the client code:

#if( !defined(_MD) )
#error _MD is not defined
#endif

We're already doing this in version.cpp, but of course this code isn't hit by consumers of the C++ driver. It needs to be in a header.

Also, confusingly, we are using /MDd for debug mode; I think this ought to be /MTd, since we're not building a DLL. This could cause weirdness if driver developers didn't also use /MDd.



 Comments   
Comment by Andrew Morrow (Inactive) [ 21/Apr/14 ]

See notes above. This ticket was intending to restrict to only building the driver as a dll and ensuring that clients consume the driver appropriately. However, we now permit building the driver as a static library, and there are other tickets (CXX-60 and CXX-138) that better cover the behavior we want to enforce.

Comment by Eric Milkie [ 21/Apr/14 ]

We should be enforcing that the library you link with your application was compiled the same way as your own application. But that is somewhat covered by other tickets. So I think closing this as WontFix is the right thing to do here.

Comment by Andrew Morrow (Inactive) [ 21/Apr/14 ]

milkie I think we should close this as wont fix. mira.carey@mongodb.com made it so that the static windows library works via some cool initializer related magic, so we can now build in both modes, and we don't really want to force this. Do you agree? Also, I don't think _MD is really a thing, reading this: http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.120).aspx. There is _MT, but that is about threading, not static/dynamic runtime.

There is also CXX-60, which is asking to enforce _DLL. I think we should do that, and can, since we now have STATIC_LIBMOGNOCLIENT to let us know whether the client has explicitly asked for a static lib and then suppress the _DLL check. I'll write up more in CXX-60 and we can see what we think.

Long term, I think the driver should move to a multi-build model where it emits several windows variant libraries, probably following the boost naming convention, so a build would get:

mongoclient.lib
mongoclient.dll
mongoclient-gd.lib
mongoclient-gd.dll
libmongoclient.lib
libmongoclient-gd.lib
libmongoclient-s.lib
libmongoclient-sgd.lib

However this is a fairly substantial overhaul of the build system, and is tracked in CXX-138, so I will add notes to that.

Comment by Githook User [ 12/Dec/13 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}

Message: Revert "SERVER-5214 Require Windows C++ driver consumers to link against the DLL version of the C++ runtime."

This reverts commit aac9e25fb096234bed6ea48217651a05afa9e10e, which currently
breaks the Windows build.
Branch: master
https://github.com/mongodb/mongo/commit/172bf6a4e24a65da9a6269507c2385c797d35cb7

Comment by Githook User [ 11/Dec/13 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}

Message: SERVER-5214 Require Windows C++ driver consumers to link against the DLL version of the C++ runtime.
Branch: master
https://github.com/mongodb/mongo/commit/aac9e25fb096234bed6ea48217651a05afa9e10e

Comment by Erich Siedler [ 08/Aug/12 ]

I very strongly agree with Tad.

BTW, _MT is always defined for native code. It indicates a multithreaded C/C++ runtime, which is always the case since VS2008.
And I hope that this means that I can compile mongod with /MD - a dll crt is serviceable by windows update, as has happened many times due to security fixes.

http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.90%29.aspx

And then there is this managed/mixed code thing.

Comment by Eric Milkie [ 08/Mar/12 ]

I found this on the C++ driver wiki page:

Windows Troubleshooting
error LNK2005: ___ already defined in msvcprt.lib(MSVCP100.dll) libboost_thread-vc100-mt-1_42.lib(thread.obj)
The boost library being linked against is expecting a /MT build. If this is a release build, try using /MT instead of /MD for compilation (under Properties.C++.Code Generation).

With the changes proposed in this ticket, we could expunge this embarrassing error and do away with documenting its explanation.

Comment by Eric Milkie [ 05/Mar/12 ]

(Also, note that /MT is the default, so if you don't specify anything on the command line, that is what you get.)

Comment by Eric Milkie [ 05/Mar/12 ]

Is it in our best interests to make it easy to accidentally build the C++ driver using incorrect flags, and thus have it result in odd runtime behavior? There's a line somewhere here. I can't think of a good reason why anyone would mix the flags, and I think it's very easy for an unsuspecting user to mess it up. Even our own build tool isn't doing it right.

Comment by Tad Marshall [ 05/Mar/12 ]

I vote against things placed in the code that say that you can't build it any way but our way. In my experience, developers may need to adapt code to fit the project they are working on, and if they have to change our header files to use MongoDB then this is not in our best interests. Once users have to modify our source code, they will become reluctant to stay current with our changes ... not what we want.

The incorrect use of /MDd in our own builds can be addressed separately. I agree with that part ... if the release build is compiled with a static CRT, then the debug build should be compiled with a static CRT.

Generated at Wed Feb 07 21:58:11 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.