Bug 411871 - boost::detail::is_convertible_impl fails to compile with a template argument that is in anonymous namespace
boost::detail::is_convertible_impl fails to compile with a template argument ...
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-12-05 07:18 EST by Caolan McNamara
Modified: 2007-12-12 15:24 EST (History)
1 user (show)

See Also:
Fixed In Version: 4.1.2-36
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-12 15:24:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test case (384 bytes, text/plain)
2007-12-05 07:18 EST, Caolan McNamara
no flags Details

  None (edit)
Description Caolan McNamara 2007-12-05 07:18:21 EST
Description of problem:
The attached code fails to compile with gcc-4.1.2-35 and boost-1.34.1-5.fc8 with
the error...

/usr/include/boost/type_traits/is_convertible.hpp:128: error: static data member
‘boost::detail::is_convertible_basic_impl<<unnamed>::baz&, int>::_m_from’ used,
but not defined

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

How reproducible:

Steps to Reproduce:
1. g++ test.cxx

I'm confused as to why in the example the non-anonymous foo works, while the
anonymous baz fails, and wildly unsure is this is a g++ problem or a boost one.
Or if the situation is just that now "you cannot use boost type_traits on
anonymous namespace classes". There are about 10 or 12 places in OOo which fail
to compile at the moment. The workaround is easy in that removing the anonymous
namespace from the OOo classes works, but it's not something I really want to
force on upstream if at all avoidable.
Comment 1 Caolan McNamara 2007-12-05 07:18:21 EST
Created attachment 278231 [details]
test case
Comment 2 Jakub Jelinek 2007-12-06 08:02:39 EST
This is a gcc bug, see http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00182.html
for a fix.  I'm waiting for review of that patch now...
Comment 3 Jakub Jelinek 2007-12-12 15:24:17 EST
The PR34094 diagnostics has been reverted in 4.1.2-36 (and on the trunk too).

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