Modify

Opened 4 years ago

Closed 3 years ago

Last modified 13 months 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 2 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 4 years ago by jim.king@…

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 Changed 3 years ago by anonymous

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

comment:3 Changed 3 years ago by anonymous

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

comment:4 Changed 3 years ago by anonymous

I think is a duplicate of ticked #6124

comment:5 Changed 3 years ago by jim.king@…

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 Changed 3 years ago by Beman Dawes

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 Changed 3 years ago by bruno@…

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

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

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

Changed 2 years ago by anonymous

Attachment: bytecoind.bash-completion added

comment:9 Changed 22 months ago by anonymous

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

comment:10 Changed 13 months ago by anonymous

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 Changed 13 months ago by James E. King, III <jking@…>

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Beman Dawes.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.