[CXX-128] Sconscript does not respect Boost naming conventions on Windows Created: 09/Mar/14  Updated: 23/Apr/14  Resolved: 23/Apr/14

Status: Closed
Project: C++ Driver
Component/s: None
Affects Version/s: legacy-0.0-26compat-2.6.0-rc1
Fix Version/s: legacy-0.8.0

Type: Bug Priority: Minor - P4
Reporter: James Coulter Assignee: Andrew Morrow (Inactive)
Resolution: Done Votes: 0
Labels: legacy-cxx, windows
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, 64-bit, Visual Studio 2012, Visual Studio 2010



 Description   

The Boost pre-built binaries include metadata in the library filenames that Scons does not recognize. For example: libboost_system-vc110-mt-sgd-1_53.lib. But the Sconscript looks for boost_system-mt.lib. Needless to say, the Sconscript does not find them:

Checking for C++ library boost_thread-mt... no
Checking for C++ library boost_thread... no
Checking for C++ library boost_filesystem-mt... no
Checking for C++ library boost_filesystem... no
Checking for C++ library boost_program_options-mt... no
Checking for C++ library boost_program_options... no
Checking for C++ library boost_system-mt... no
Checking for C++ library boost_system... no

Yes, the boost libraries can be built in a way that doesn’t include the extra metadata (or they can be manually renamed). However, given that the MongoDB C++ Driver depends on Boost, it would make more sense to conform to the naming that Boost provides. The Boost headers themselves are designed to properly link to the correct lib file with full metadata in the filename. Furthermore, the reduced names can lead to build issues due to simple human error of pointing to a lib file that does not exactly match the build context (debug/release and dynamic/static). The extra metadata in the name ensures the correct lib file is selected.

While the “sgd” portion of the Boost lib filename can be deduced from options like --static and --dbg:on, the “vc110” and “1_53” portions could be specified as new program options to the Sconscript.

Furthermore, when the --static flag is specified, the Sconscript still appears to look for boost_system-mt (the dynamic version of the lib) yet it should be looking for, libboost_system-mt (the static version of the lib). That is, fully static should really be fully static.



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

Hi james.coulter -

Is there anything else we can do for you in relation to this ticket? If not I would like to close it. You can always re-open it if needed.

Thanks,
Andrew

Comment by James Coulter [ 21/Mar/14 ]

Thanks again for all the helpful info. I will give the new fixes for static builds a try. I really like the new direction for the C++ driver. Keep up the great work!

Comment by Andrew Morrow (Inactive) [ 17/Mar/14 ]

james.coulter A few comments in addition to what Eric mentioned above:

  • We have just recently fixed the ability to use the static archive on windows in the 26compat branch. The fix is available in the 26compat RC1 release.
  • If you intend to consume the static library you should build the consuming application with STATIC_LIBMONGOCLIENT defined to suppress the import/export macros.
Comment by Eric Milkie [ 17/Mar/14 ]

At the moment, the static C++ driver library does not correctly work on Windows, as there is no ability with MS LINK to reproduce the behavior of the --whole-archive Unix ld option. We're working on possible solutions to this.

The --variant-dir flag allows you to explicitly set SCons' VariantDir explicitly, rather than have it build the path dynamically from the arguments passed to scons. Because we are passing so many arguments for this particular build, the dynamically built variant directory name ends up being longer than the longest allowed pathname on Windows, so we must override it to be something shorter. (For an illustration of this, try omitting the --variant-dir=m flag.)

We are also working on a better functioning macro to remove the declspec() calls when compiling with /MT[d].

Comment by James Coulter [ 14/Mar/14 ]

Indeed, despite the sconscript reporting that it does not find the boost libs, it does appear to link correctly if the --libpath is set. I was able to get both 64-bit release and debug builds to work, but only for dynamic linking /MD or /MDd using mongoclient.lib and mongoclient.dll, with the help of your suggestions:

scons --64 -j 3 --sharedclient --dynamic-windows --release --full  --win-version-min=win7  --prefix=C:\Dev_Sources\Mongo\mongo_client\legacy --use-system-boost --cpppath=C:\local\boost_1_53_0 --libpath=C:\local\boost_1_53_0\lib64-msvc-11.0 --variant-dir=m install-mongoclient

What exactly does the --variant flag accomplish? I could not find a clear explanation for that in the docs. Also, there is some weirdness with the debug build where, in my console output, I see some debug warnings:

_DEBUG warning trying to lock a mongo::mutex during static shutdown

Although, despite these warnings, everything seems to work fine. At least now I can work on the actual application using the successful builds and play with scons settings in the background. Hurrah!

I'd really like to have /MT and /MTd. but whenever I try to link against libmongoclient.lib, I get link errors along the lines of:

DriverTest.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl mongo::DBClientConnection::DBClientConnection(bool,class mongo::DBClientReplicaSet *,double)" (__imp_??0DBClientConnection@mongo@@QEAA@_NPEAVDBClientReplicaSet@1@N@Z) referenced in function "void __cdecl run(void)" (?run@@YAXXZ)

If anyone has been successful with fully static linking, I'd appreciate any tips on how you did it. I've tried many combinations of settings.

Comment by James Coulter [ 11/Mar/14 ]

Thanks Eric and Kaloian for this helpful information. I will do some additional tests as soon as time permits. My preference is to build a fully static client lib so that no DLLs are required (neither Boost nor a mongoclient.dll), if possible.

Comment by Kaloian Manassiev [ 10/Mar/14 ]

FYI, you could use the following command line as a sample of how to build the C++ client:

scons --64 -j 4 --sharedclient --dynamic-windows --release --full --prefix=<path to place the binaries> --use-system-boost --cpppath=<boost root> --libpath=<boost root>\lib64-msvc-[10|11|12].0 --variant-dir=m install-mongoclient

Comment by Eric Milkie [ 10/Mar/14 ]

The filenames are leftover from when the build used the vendorized Boost that came included in the source tree. Building the driver this way was problematic, of course. The recommended way to build the driver is to --use-system-boost, which on Windows will do the right thing and use Boost's auto-linking support. As part of the new C++ driver development, I believe it will be changed to default to using the system installed Boost and you will no longer have to specify it on the build command line.

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