Bug 1021009

Summary:	boost thread c++98 vs c++11 issues
Product:	[Fedora] Fedora	Reporter:	MM <finjulhich>
Component:	boost	Assignee:	Petr Machata <pmachata>
Status:	CLOSED WORKSFORME	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	dakingun, denis.arnaud_fedora, mnewsome, pertusus, pmachata
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-21 17:46:35 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description MM 2013-10-18 18:43:35 UTC

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 09:06:20 UTC

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 12:38:56 UTC

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 15:46:01 UTC

I use BFD-based ld as well.
Please provide a reproducer.

Comment 4 MM 2013-10-21 15:59:45 UTC

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 17:46:35 UTC

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.