Given:
// cp.cpp #include <boost/filesystem.hpp> int main( int argc, char** argv ) { if( argc < 3 ) return -1; boost::filesystem::copy_file( argv[1], argv[2] ); return 0; }
g++ -o cp cp.cpp -std=c++0x -I /usr/local/include /usr/local/lib/libboost_filesystem.a /usr/local/lib/libboost_system.a
Undefined symbols for architecture x86_64: "boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option, boost::system::error_code*)", referenced from: boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&) in ccUAyvBD.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status
If I remove the -std=c++0x flag then it links just fine.
g++ --version g++ (MacPorts gcc47 4.7.0_3) 4.7.0 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This is a case where I compiled boost with a different version of g++ (or perhaps without c++0x support??) resulting in binary incompatibility when the BOOST_SCOPED_ENUM is used in the header of a compiled library. This seems like a bad API choice as it requires all programs that use boost::filesystem::copy_file to use the same version of G++ with the same compile options. In this case, the library should (in theory) implement both the scoped enum and unscoped enum implementation so that I can mix and match C++03 code with C++0x code without having two different versions of boost::filesystem. The problem appears to also exist in 1.50 upon inspecting the code. My work arounds are to disable SCOPED_ENUM in my build process or to use the boost::filesystem::copy instead of boost::filesystem::copy_file...
Dan