Boost logo

Boost :

Subject: Re: [boost] [filesystem] 1.49 linking with c++0x
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2012-07-11 14:05:10

> 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
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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at