Boost C++ Libraries: Ticket #10038: filesystem library with -std=c++11 causes undefined reference to copy_file

jim.king@… — Sun, 11 May 2014 11:15:00 GMT

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)

anonymous — Mon, 07 Jul 2014 21:28:43 GMT

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

anonymous — Wed, 09 Jul 2014 15:39:38 GMT

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

anonymous — Fri, 24 Oct 2014 09:02:43 GMT

I think is a duplicate of ticked #6124

jim.king@… — Fri, 24 Oct 2014 11:34:06 GMT

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?

status, milestone changed; resolution set

Beman Dawes — Fri, 24 Oct 2014 16:03:19 GMT

status new → closed
resolution → fixed
milestone To Be Determined → Boost 1.57.0

#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

bruno@… — Thu, 19 Mar 2015 17:11:04 GMT

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

Mon, 11 May 2015 15:25:49 GMT

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

attachment set

anonymous — Fri, 11 Dec 2015 23:38:49 GMT

attachment → bytecoind.bash-completion

anonymous — Sun, 31 Jan 2016 14:52:21 GMT

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

anonymous — Wed, 26 Oct 2016 03:24:39 GMT

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*)'

Wed, 26 Oct 2016 12:33:05 GMT

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

shanakard@… — Thu, 07 Jun 2018 10:51:20 GMT

I get the same error with boost 1.67 on RHEL 7.5