#10038 closed Bugs (fixed)
filesystem library with -std=c++11 causes undefined reference to copy_file
Reported by: | 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)
Change History (13)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
I have exactly the same issue with Boost 1.55 (using Clang 3.5 under Ubuntu 14.04).
comment:3 by , 8 years ago
The problem is still there in Boost 1.56 RC1 released yesterday (using Clang 3.5).
comment:5 by , 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 , 8 years ago
Milestone: | To Be Determined → Boost 1.57.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
follow-up: 8 comment:7 by , 8 years ago
I guess a backport to 1.56 would save some pain to lot of people
comment:8 by , 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 , 7 years ago
Attachment: | bytecoind.bash-completion added |
---|
comment:9 by , 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 , 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 , 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?
Using "strings" I extracted the mangled name from the library:
This demangles to:
The ::enum_type is a different signature.
I built boost 1.56 with:
(where ... was a directory outside the source directory)