[SERVER-5561] Move definition of BOOST_FILESYSTEM_VERSION preprocessor constant out of pch.h Created: 10/Apr/12  Updated: 11/Jul/16  Resolved: 23/Oct/12

Status: Closed
Project: Core Server
Component/s: Internal Client
Affects Version/s: None
Fix Version/s: 2.3.0

Type: Improvement Priority: Major - P3
Reporter: Andy Schwerin Assignee: Andy Schwerin
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

The redefinition of BOOST_FILESYSTEM_VERSION 2 in pch.h makes it problematic if you are using version 3 in userland code.



 Comments   
Comment by Andy Schwerin [ 23/Oct/12 ]

Resolved by SERVER-4314

Comment by Pedro Larroy [ 18/Apr/12 ]

I think the best solution is just using v3. For future releases you could just require boost with BFSv3.

I'm afraid this won't work. Currently in my organization we were also using BFSv2 and we migrated to BFSv3 and removed this very macro. The surprise came when the mongodb driver was redefining this macro when including the client headers and thus making it incompatible. IIRC if the macro is not defined, the old API is not exported. As I understand this issue both APIS are mutually exclusive.

Even worse, changing like:

— a/SConstruct
+++ b/SConstruct
@@ -350,8 +350,9 @@ if has_option( "libpath" ):
if has_option( "cpppath" ):
env["CPPPATH"] = [get_option( "cpppath" )]

-env.Prepend( CPPDEFINES=[ "_SCONS" ,
+env.Prepend( CPPDEFINES=[ "_SCONS" ,
"MONGO_EXPOSE_MACROS" ,
+ "BOOST_FILESYSTEM_VERSION=2",
"SUPPORT_UTF8" ], # for pcre

Will break boost compilation as the environment is inherited.

generate_buildinfo(["build/buildinfo.cpp"], ['\n#include <string>\n#include <boost/version.hpp>\n\n#include "mongo/util/version.h"\n\nnamespace mongo {\n const char * gitVersion()

{ return "%(git_version)s"; }

\n std::string sysInfo()

{ return "%(sys_info)s BOOST_LIB_VERSION=" BOOST_LIB_VERSION ; }

\n} // namespace mongo\n'])
g++ -o build/linux2/normal/third_party/boost/libs/filesystem/v3/src/codecvt_error_category.o -c -Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -Werror -pipe -fno-builtin-memcmp -O3 -DBOOST_ALL_NO_LIB -D_SCONS -DMONGO_EXPOSE_MACROS -DBOOST_FILESYSTEM_VERSION=2 -DSUPPORT_UTF8 -D_FILE_OFFSET_BITS=64 -DJS_C_STRINGS_ARE_UTF8 -DMONGO_HAVE_EXECINFO_BACKTRACE -DXP_UNIX -Ibuild/linux2/normal/third_party/boost -Isrc/third_party/boost -Ibuild/linux2/normal/third_party/pcre-8.30 -Isrc/third_party/pcre-8.30 -Ibuild/linux2/normal -Isrc -Ibuild/linux2/normal/mongo -Isrc/mongo -Ibuild/linux2/normal/third_party/snappy -Isrc/third_party/snappy -Ibuild/linux2/normal/third_party/js-1.7 -Isrc/third_party/js-1.7 src/third_party/boost/libs/filesystem/v3/src/codecvt_error_category.cpp
In file included from src/third_party/boost/libs/filesystem/v3/src/codecvt_error_category.cpp:29:0:
src/third_party/boost/boost/filesystem/v3/config.hpp:16:5: error: #error Compiling Filesystem version 3 file with BOOST_FILESYSTEM_VERSION defined != 3
scons: *** [build/linux2/normal/third_party/boost/libs/filesystem/v3/src/codecvt_error_category.o] Error 1
scons: building terminated because of errors.

Comment by Andy Schwerin [ 16/Apr/12 ]

When I filed this bug, I didn't intend to upgrade Mongo to using the v3 version of boost::filesystem; only to insulate consumers of the C++ driver from Mongo's choice of version. The straight upgrade approach that you propose may interfere with organizations that require dynamic linking and boost versions prior to 1.44. Clearly, sticking to the v2 interface will be untenable in the future, however.

Anyhow, I have not forgotten this patch, but have not had time to consider these implications, fully. If you have time to experiment, could you see if defining BOOST_FILESYSTEM_VERSION=2 in the SCons CPPDEFINES variable and dropping it from pch.h provides a version of the C++ driver compatible with applications that also need v3 of boost::filesystem? If not, I will look into it when I have time.

Comment by Pedro Larroy [ 16/Apr/12 ]

Hi Andy, did you had time to look at this pull request? regards.

Comment by Pedro Larroy [ 10/Apr/12 ]

Hi

I created a pull request: https://github.com/mongodb/mongo/pull/208

Generated at Thu Feb 08 03:09:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.