Bug 1021009 - boost thread c++98 vs c++11 issues
boost thread c++98 vs c++11 issues
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: boost (Show other bugs)
19
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Machata
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-18 14:43 EDT by MM
Modified: 2015-05-04 21:38 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-21 13:46:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description MM 2013-10-18 14:43:35 EDT
Description of problem:


Version-Release number of selected component (if applicable):
1.53

How reproducible:


Steps to Reproduce:
1. Link in c++11 from g++ 4.8.1 a program that uses boost::thread

Actual results:
linker error
mainthread.cpp:(.text+0x2cf): undefined reference to `boost::thread::start_thread()'

Expected results:
Linking should succeed.
Looking with nm -C -D at the libboost_thread-mt.so file, it shows this symbol instead:
start_thread_noexcept()

Additional info:
Comments from Petr Machata:
Building in C++11 might be the cause here.  Some boost libraries just
have different interfaces in C++03 and C++11 (the obvious suspect being
move ctor, but not only).  Currently we build boost DSO's in C++98, as
building in C++11 has the potential of subtly breaking stuff (we have
over 200 clients in Fedora alone).  But building in C++11, even if safe
for boost DSO's, won't solve the larger problem anyway.  That then
shifts to boost clients that expose boost types in their API.  Those may
and up with actual ABI differing depending on whether their clients
(that's clients of boost clients) build in C++98 or C++11 mode.

Frankly, I'm not entirely sure how to solve this.  Ideally we would make
sure that C++11 portion of boost forms a pure, ABI compatible superset
of C++98 portion of boost.  Detecting this is possible with symbols in
DSO's (we would compare debuginfo's, probably, somehow), but how to do
this analysis for general header files is unclear.  Maybe Dodji
Seketeli's ABI checker might be of use here.  Then if the superset
theory holds, we can safely assume it's safe to build stuff against
boost in C++11 mode.
Comment 1 Petr Machata 2013-10-21 05:06:20 EDT
Please provide a reproducer.  The following works for me:

#include <boost/thread.hpp>
void fun () {
  std::cout << "boo!" << std::endl;
}
int main () {
  boost::thread t (fun);
  t.join ();
}

$ ~/opt/gcc48/bin/g++ -std=c++0x bleble.cc -lboost_thread
$ ./a.out
boo!
Comment 2 MM 2013-10-21 08:38:56 EDT
I couldn't reproduce with your example either.

I did move the -lboost_thread-mt flag in the compile line for g++ --std=c++11 before and after my library containing the reference to boost::thread::start_thread() with no luck.

However, I have just switched the linker from ld.bdf to ld.gold as a default, and it linked properly.

Is the gold linker the one used to build F19? If so, is this error due to using different linkers?
Comment 3 Petr Machata 2013-10-21 11:46:01 EDT
I use BFD-based ld as well.
Please provide a reproducer.
Comment 4 MM 2013-10-21 11:59:45 EDT
I couldn't reproduce with a smaller example and so I did
A clean rebuild from scratch, and that worked, with BFD too.
It was not an issue with gold vs BFD nor c++11 vs c++98. The remark you've made is probably still valid though I guess.

I do apologize for the confusion and time.
I suppose the ticket can be closed, apologies again
Comment 5 Petr Machata 2013-10-21 13:46:35 EDT
OK.  If you ever figure out the how you ended up with start_thread exposed and undefined, please don't hesitate to reopen.  For now, I'm closing this.

Note You need to log in before you can comment on or make changes to this bug.