Problem with copy_file in 1.47

[morandidodo@…]

Hi, I'm having a strange behaviour with copy_file in boost 1.47.

I've got a file with a piece of code like this:

string filename, old_filename;
...
copy_file(old_filename, filename);

It compiles, but it doesn't link. The linker says that copy_file doesn't exists:

/usr/local/include/boost/filesystem/v3/operations.hpp:303: undefined reference to `boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option, boost::system::error_code*)'

I'm using other functions from the filesystem library, and if I don't include the "-lboost_filesystem" flag I got other errors, so the library is correctly found.

The boost library is not pre-compiled -- I built it by myself, but I didn't specified any particular flag to the b2.

Thanks -- dodomorandi

[morandidodo@…]

I found a possible cause. Take this piece of code as test:

#include <boost/filesystem.hpp>

using namespace boost::filesystem;

int main()
{
   copy_file("a", "b");
   return 0;
}

I'm using g++ 4.5.2, and I noticed the problem occurs only when I compile the code with -std=c++0x. What I don't know is if the problem is related to the boost library or the compiler. However if I use boost 1.42 (the library provided from my Linux distribution) everything goes well.

Any suggestion? -- dodomorandi

[anonymous]

I'm experiencing the same problem with g++ 4.6.1 with -std=c++0x.

[anonymous]

Just another information, maybe it could be useful: I just installed the new Linux Mint 12. The problem is reproducible with default packages. Boost is 1.46.1, g++ 4.6.1.

[morandidodo@…]

Got the problem - finally! It's necessary to build the Boost library using the "-std=c++0x" flag, like this: ./b2 cxxflags="-std=c++0x"

I think it's quite important to check before the compilation (using autoconf scripts, cmake scripts and so on) if the compiled libraries can be linked with the "c++0x" flag.

However, anyone knows if there's a reason to compile the Boost without c++0x? It could be possible to compile programs using the C++03 standard? If it's completely retro-compatible maybe it could be useful to enable the c++0x flag by default, isn't it?

-- dodomorandi

[Beman Dawes]

#6124, #6779, and #10038 are all the same problem. The private library interface has been changed to use a plain-old C++03 enum. This is the fix suggested by Andy in 6779.

The fix was too late for 1.57 beta 1, but should be in the final 1.57 release.

Thanks for your patience,

--Beman