Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
+++ This bug was initially created as a clone of Bug #999320. Somehow the fix didn't make it into RHEL7.
The bug is still present in the latest available version of boost-devel: 1.53.0-26. When applying the patch from https://svn.boost.org/trac/boost/ticket/8102 this issue disappears. +++
boost 1.53 (shipped with fedora 19) needs the patch (which is included in boost 1.54) from https://svn.boost.org/trac/boost/ticket/8102
when used with clang++ for compiling code using boost::signals2::signal
Othewise, compiling code like this fails:
#include <boost/signals2/signal.hpp>
int main()
{
boost::signals2::signal<void()> s;
s();
}
Compiled using
clang++ -c --std=c++11
The boost patch is not needed for compiling using g++ (4.8.1).
Note:
g++ --version = g++ (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1)
clang++ --version = clang version 3.3 (tags/RELEASE_33/rc3)
Compiler error:
In file included from test.cpp:1:
In file included from /usr/include/boost/signals2/signal.hpp:38:
In file included from /usr/include/boost/signals2/variadic_signal.hpp:21:
/usr/include/boost/signals2/detail/variadic_slot_invoker.hpp:89:16: error: no matching function for call to 'get'
func(std::get<indices>(args)...);
^~~~~~~~~~~~~~~~~
--- Additional comment from Fedora Update System on 2013-08-21 10:46:07 EDT ---
boost-1.53.0-12.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/boost-1.53.0-12.fc19
--- Additional comment from Fedora Update System on 2013-08-21 20:45:19 EDT ---
Package boost-1.53.0-12.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing boost-1.53.0-12.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-15101/boost-1.53.0-12.fc19
then log in and leave karma (feedback).
--- Additional comment from Fedora Update System on 2013-08-24 18:30:28 EDT ---
boost-1.53.0-12.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Jos Collin from comment #0)
> +++ This bug was initially created as a clone of Bug #999320. Somehow the
> fix didn't make it into RHEL7.
Because it never made it into boost-1.53.0-12.fc19 either.
> --- Additional comment from Fedora Update System on 2013-08-21 20:45:19 EDT
> ---
>
> Package boost-1.53.0-12.fc19:
> * should fix your issue,
This was incorrect, 1.53.0-12 fixed the unrelated Bug 971956.
(In reply to Jonathan Wakely from comment #2)
> > Package boost-1.53.0-12.fc19:
> > * should fix your issue,
>
> This was incorrect, 1.53.0-12 fixed the unrelated Bug 971956.
Oh my mistake, I was looking at the 1.53.0-12 pkg on the f20 branch. You're right, that version was the fix for f19, sorry.
I've done a bit more digging into the cause of the compiler error. Clang always identifies itself as GCC 4.2.1, which Boost 1.53 interprets to mean that no C++11 library features are supported. The <boost/config/stdlib/libstdcpp3.hpp> file has:
// C++0x headers in GCC 4.3.0 and later
//
#if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 3) || !defined(__GXX_EXPERIMENTAL_CXX0X__)
# define BOOST_NO_CXX11_HDR_ARRAY
# define BOOST_NO_CXX11_HDR_REGEX
# define BOOST_NO_CXX11_HDR_TUPLE
# define BOOST_NO_CXX11_HDR_UNORDERED_MAP
# define BOOST_NO_CXX11_HDR_UNORDERED_SET
# define BOOST_NO_CXX11_HDR_FUNCTIONAL
#endif
In fact, clang is using the RHEL libstdc++ headers from GCC 4.8, which do support the <tuple> header. This misdetection will happen for any version of Clang, because they all identify as GCC 4.2.1 so get treated the same by the logic above.
Instead of fixing the misuse of std::get (as the F19 patch does) we could teach the Boost.Config header to be smarter about detecting C++11 features when compiling with Clang+libstdc++. The patch seems simpler and safer though.
A possible workaround for the customer is to modify the code like so:
#include <boost/config.hpp>
#if defined(__clang__) && __cplusplus >= 201103L
# undef BOOST_NO_CXX11_HDR_TUPLE
#endif
#include <boost/signals2/signal.hpp>
int main()
{
boost::signals2::signal<void()> s;
s();
}