Opened 8 years ago

Closed 8 years ago

Last modified 4 years ago

#10038 closed Bugs (fixed)

filesystem library with -std=c++11 causes undefined reference to copy_file

Reported by: jim.king@… Owned by: Beman Dawes
Milestone: Boost 1.57.0 Component: filesystem
Version: Boost 1.56.0 Severity: Problem
Keywords: filesystem copy_file undefined Cc:

Description

#include <boost/filesystem.hpp>

int main(void)
{
    boost::filesystem::copy_file("a", "b");
    return 0;
}

Using either g++ 4.8.1 or clang++ 3.5 when I enable the compiler option -std=c++11, the boost::filesystem::detail::copy_file cannot be found in the library:

root@dvm-3:/tmp# g++ --version
g++ (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1

# g++ -g -I/usr/include/boost-1_56 fscopy.cpp -o fscopy -lboost_filesystem-clang35-mt-d-1_56 -lboost_system-clang35-mt-d-1_56 

# g++ -std=c++11 -g -I/usr/include/boost-1_56 fscopy.cpp -o fscopy -lboost_filesystem-clang35-mt-d-1_56 -lboost_system-clang35-mt-d-1_56 
/usr/include/boost-1_56/boost/filesystem/operations.hpp:385: error: undefined reference to 'boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::copy_option, boost::system::error_code*)'
collect2: error: ld returned 1 exit status

# /usr/bin/clang++ -g -I/usr/include/boost-1_56 fscopy.cpp -o fscopy -lboost_filesystem-clang35-mt-d-1_56 -lboost_system-clang35-mt-d-1_56 

# /usr/bin/clang++ -std=c++11 -g -I/usr/include/boost-1_56 fscopy.cpp -o fscopy -lboost_filesystem-clang35-mt-d-1_56 -lboost_system-clang35-mt-d-1_56 
/usr/include/boost-1_56/boost/filesystem/operations.hpp:385: error: undefined reference to 'boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::copy_option, boost::system::error_code*)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The boost 1.56 libraries were built with clang-3.5 on Ubuntu 12.04.2 LTS with libstdc++ from g++-4.8.1 installed.

Attachments (1)

bytecoind.bash-completion (44 bytes ) - added by anonymous 7 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 by jim.king@…, 8 years ago

Using "strings" I extracted the mangled name from the library:

# strings /usr/lib/libboost_filesystem-clang35-mt-d-1_56.so | grep copy_file
_ZN5boost10filesystem6detail9copy_fileERKNS0_4pathES4_NS0_11copy_option9enum_typeEPNS_6system10error_codeE
...

This demangles to:

boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::copy_option::enum_type, boost::system::error_code*)

The ::enum_type is a different signature.

I built boost 1.56 with:

./b2 toolset=clang --prefix=/usr  --build-type=complete --build-dir=... --layout=versioned install

(where ... was a directory outside the source directory)

comment:2 by anonymous, 8 years ago

I have exactly the same issue with Boost 1.55 (using Clang 3.5 under Ubuntu 14.04).

comment:3 by anonymous, 8 years ago

The problem is still there in Boost 1.56 RC1 released yesterday (using Clang 3.5).

comment:4 by anonymous, 8 years ago

I think is a duplicate of ticked #6124

comment:5 by jim.king@…, 8 years ago

It looks like that other ticket was marked resolved because someone found a workaround, not because the root cause was addressed. That said, the workaround might be helpful. Thanks for connecting the dots... so the question remains, can one use a single c++0x build to satisfy c++0x and non-c++0x, or do we need to add yet another variant to the build cycle and another library name variant to the output library file names?

comment:6 by Beman Dawes, 8 years ago

Milestone: To Be DeterminedBoost 1.57.0
Resolution: fixed
Status: newclosed

#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

comment:7 by bruno@…, 8 years ago

I guess a backport to 1.56 would save some pain to lot of people

in reply to:  7 comment:8 by mancha <mancha1@…>, 7 years ago

Replying to bruno@…:

I guess a backport to 1.56 would save some pain to lot of people


I've prepared a backport to 1.56:

http://sf.net/projects/mancha/files/misc/boost-1.56.0_copy_file.diff

--mancha

by anonymous, 7 years ago

Attachment: bytecoind.bash-completion added

comment:9 by anonymous, 7 years ago

I have exactly the same issue with latest Boost 1.60 (using Clang 3.7 with c++11 under Gentoo).

comment:10 by anonymous, 6 years ago

How to deal with this problem?

I have exactly the same issue with Boost 1.54.0(using arm-gcc 4.8.3 under Android)

How to write the Makefile via Android.mk?

libboost_system, libboost_thread, libboost_filesystem and libboost_log are used.

When I build the libboost_log, the issue occurs.

The cxx_flags of filesystem is:

-std=c++0x -Wextra -pedantic -Wno-long-long -ansi -fpermissive -fexceptions -Wno-variadic-macros -Wunused-function -DBOOST_SYSTEM_NO_DEPRECATED

It successed

and the boost_log is:

-std=c++0x -fexceptions -fpermissive -Wmissing-field-initializers -ftemplate-depth-1024 -fno-strict-aliasing -DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_SPIRIT_USE_PHOENIX_V3

boost/filesystem/operations.hpp:384: undefined reference to `boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::copy_option, boost::system::error_code*)'

comment:11 by James E. King, III <jking@…>, 6 years ago

There is a report that this was seen in boost-1.60. Shouldn't it be rejected/reopened until that is proven incorrect?

comment:12 by shanakard@…, 4 years ago

I get the same error with boost 1.67 on RHEL 7.5

Note: See TracTickets for help on using tickets.