[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 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, | |||
| 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:
| |||
| 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:
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:
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:
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:
| |||
| 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. |