VS2008 && /clr && boost::thread == error LNK2022

[primeMover]

Hi,

I have a VS2008 project where I'm using boost::thread. The project is
compiled with /clr, it's a classlibrary where I wrap access to a native
library.
Everything compiles fine. The linker gives this error:

1>Finished searching libraries
1>Search transition __pRawDllMain->__t2m@__pRawDllMain
1>Merging metadata
1>EditorFactory.obj : error LNK2022: metadata operation failed (8013119F) :
A TypeRef exists which should, but does not, have a corresponding TypeDef:
(dummy): (0x01000023).
1>Finished merging metadata
1>LINK : fatal error LNK1215: metadata operation failed (8013119F) :

What happens here? How can I fix this?

BR
pM

 

[primeMover]

BTW... when not compiling against the CLR, everything works fine.
Is this the wrong forum for this question?

--

 

[Ben Voigt [C++ MVP]]

BTW... when not compiling against the CLR, everything works fine.
Is this the wrong forum for this question?

No, it's the right forum.

Have you done a "rebuild all"?

 

[primeMover]

Yes, I did a rebuild all.
The type that leads to the problem is called dummy. How nice

I've found the problem, but I'm far from a solution...

These lines are the problem:

#ifdef BOOST_HAS_RVALUE_REFS
typedef T const& source_reference_type;
struct dummy;
typedef typename
boost::mpl::if_<boost::is_fundamental<T>,dummy&,T&&>::type rvalue_source_type;
typedef typename
boost::mpl::if_<boost::is_fundamental<T>,T,T&&>::type move_dest_type;

I'm unsure, why this compiles, but does not link.

--
Automotive Testbed Automation
AVL List Gmbh
http://www.avl.com

 

[Cholo Lennon]

Yes, I did a rebuild all.
The type that leads to the problem is called dummy. How nice

I've found the problem, but I'm far from a solution...

These lines are the problem:

#ifdef BOOST_HAS_RVALUE_REFS
typedef T const& source_reference_type;
struct dummy;
typedef typename
boost::mpl::if_<boost::is_fundamental<T>,dummy&,T&&>::type
rvalue_source_type; typedef typename
boost::mpl::if_<boost::is_fundamental<T>,T,T&&>::type move_dest_type;

I'm unsure, why this compiles, but does not link.

Well dummy is a forward declaration for (I guess) an empty type . Try declaring
the dummy structure in the file where linker is complaining (Maybe, for CLR, the
compiler needs to have a concrete type, not just a reference):

struct dummy { };

BTW, which version of boost are you using?

 

[Ben Voigt [C++ MVP]]

I don't think VS2008 supports rvalue references (that T&& syntax).

 

[Cholo Lennon]

I don't think VS2008 supports rvalue references (that T&& syntax).

Ahh ... you're right, I didn't notice that. Maybe the OP hasn't chosen the
proper toolset or the problem is in the #else section

 

[primeMover]

BTW, which version of boost are you using?

1.36

 

[primeMover]

I don't think VS2008 supports rvalue references (that T&& syntax).

Yes, at second sight

What still surprises me: Why does this compile? Is T&& legal?

 

[Ben Voigt [C++ MVP]]

Yes, at second sight

What still surprises me: Why does this compile? Is T&& legal?

Why do you think it is compiling? It's inside a #if block that by all
appearances evaluates to false.

 

[primeMover]

Why do you think it is compiling? It's inside a #if block that by all
appearances evaluates to false.

Because the T&& is within this if-Block and the linker complains about
"dummy", the compiler does not.

 

[Cholo Lennon]

Because the T&& is within this if-Block and the linker complains about
"dummy", the compiler does not.

In Boost 1.36, BOOST_HAS_RVALUE_REFS is only defined for gcc and metrowerk
compilers (check [boost_install]\boost\config\compilers) so it's impossible the
compilation for that piece of code using VC++. Could you tell us which is the
boost file please?

 

[primeMover]

In Boost 1.36, BOOST_HAS_RVALUE_REFS is only defined for gcc and metrowerk
compilers (check [boost_install]\boost\config\compilers) so it's impossible the
compilation for that piece of code using VC++. Could you tell us which is the
boost file please?

You're right. The 'struct dummy' the linker complains about is thread.hpp
I was on the wrong track.