Modify

Ticket #2226 (closed Bugs: wontfix)

Opened 8 years ago

Last modified 5 months ago

boost::thread 1.36.0 /clr Link Error LNK2022

Reported by: benjamin.sternlieb@… Owned by: anthonyw
Milestone: Boost 1.36.0 Component: thread
Version: Boost 1.37.0 Severity: Showstopper
Keywords: clr dummy thread LNK2022 Cc: teeks99@…, roffe@…

Description

The boost thread library in release 1.36.0 is incompatible with Microsofts /clr Common Language Runtime support.

Without /clr, the following compiles cleanly:

#include "boost/thread.hpp"


struct Thing {
  void operator()() {}
};

void Run() {
  Thing thing;
  boost::thread thread(thing);
}

However, with /clr, the following error is observed:

error LNK2022: metadata operation failed (8013119F) : A TypeRef? exists which should, but does not, have a corresponding TypeDef?: (dummy): (0x01000019). LINK : fatal error LNK1215: metadata operation failed (8013119F) :

Attachments

Change History

comment:1 Changed 7 years ago by Tom Kent <teeks99@…>

  • Cc teeks99@… added
  • Version changed from Boost 1.36.0 to Boost 1.37.0

I have an update, and a somewhat more complicated example....  http://www.teeks99.com/BoostManagedTest.zip

I found that some parts of the boost library (like sleep()) can be used (but only when linked dynamically! with a .dll, no static libs). Also, this bug verified to be still present in 1.37.0.

Here's my code:

// This demonstrates where boost's thread library is incompatible with Visual
// Studio 2005's (and presumably the other versions as well) /clr option.

// This project was created with the Visual Studio wizard for a native console
// application.  The path to the boost folder was added to all configurations' 
// "Additional Include Directories" and the path to the boost libraries was 
// added to all configurations' "Additional Library Directories".
// The Configuration manager was then used to copy the Debug and Release 
// configurations to the Debug-CLR and Release-CLR configurations.  Then the 
// "Common Language Runtime Support" option for these two new configurations
// was set to /clr. 
// Finally I copied the boost_thread-vc80-mt-1_37.dll and 
// boost_thread-vc80-mt-gd-1_37.dll to both configurations output directories.

// I have setup several test cases (listed below) to outline a couple issues 
// where there are incompatabilities.  All cases run fine in the Debug and 
// Release configurations, when in the Debug-CLR or Release-CLR configurations
// the following issues are found.  

// Define one of these cases to see the test
// CASE1 - No use of boost threadding...everything works
// CASE2 - Use boost threadding for the sleep() function, static link...fails at
//         runtime "The application failed to initialize properly (0xc000007b).
//         Click on OK to terminate the application." in both Debug and Release.
// CASE3 - Use boost threadding for the sleep() function, dynamic link....works
// CASE4 - Use boost threadding for thread creation/rejoin, static link...fails 
//         at compile time "BoostManagedTest.obj : error LNK2022: metadata 
//         operation failed (8013119F) : A TypeRef exists which should, but does
//         not, have a corresponding TypeDef: (dummy): (0x01000019)." in both
//         Debug and Release.
// CASE5 - Use boost threadding for thread creation/rejoin, dynamic link...fails
//         at compile time "BoostManagedTest.obj : error LNK2022: metadata 
//         operation failed (8013119F) : A TypeRef exists which should, but does
//         not, have a corresponding TypeDef: (dummy): (0x01000019)." in both
//         Debug and Release.
#define CASE1

// ----------- CASE SETUP -----------
#ifdef CASE2
# define THREAD_ENABLED
#endif
#ifdef CASE3
# define THREAD_ENABLED
# define DYNAMIC_LINK
#endif
#ifdef CASE4
# define THREAD_ENABLED
# define THREAD_CREATION
#endif
#ifdef CASE5
# define THREAD_ENABLED
# define THREAD_CREATION
# define DYNAMIC_LINK
#endif
// ----------- CASE SETUP -----------

#ifdef THREAD_ENABLED
# ifdef DYNAMIC_LINK
#define BOOST_THREAD_USE_DLL
# endif //DYNAMIC_LINK
#include <boost/thread.hpp>
#else if
#include <windows.h>
#endif // THREAD_ENABLED

#include <iostream>

class Spinner{
public:
   void operator() () {
      int threadSleepLength = 100;
      for(int counter=0; counter < 5; ) {
         std::cout << "tick " << ++counter << std::endl;
#ifdef THREAD_ENABLED
         boost::this_thread::sleep(boost::posix_time::millisec(threadSleepLength));
#else if // Use window's sleep
         Sleep(threadSleepLength);
#endif // THREAD_ENABLED
      }
   }
};

int main(int argc, char* argv[]){
   Spinner spin;
#ifdef THREAD_CREATION
   boost::thread spnThread(spin);
   spnThread.join();
#else if
   spin ();
#endif //THREAD_CREATION
	return 0;
}

comment:2 follow-up: ↓ 7 Changed 7 years ago by roffe@…

  • Cc roffe@… added

The linker Error LNK2022 when compiling with /clr can be resolved by adding

namespace boost {
	struct thread::dummy {};
}

after the inclusion of <boost/thread/thread.hpp>

Dynamically linked everything seems to work. However when statically linked, the application still fails to initialize with error 0xc000007b (which seems to be a different problem arising of the use of an undocumented PE hook mechanism).

comment:3 Changed 7 years ago by teeks99@…

That seemed to work pretty well for the dynamically linked examples. Do you know why it works?

comment:4 Changed 6 years ago by anonymous

I have the same bug on Boost 1.41.0 + VS2008SP1.

comment:5 Changed 6 years ago by anthonyw

  • Status changed from new to closed
  • Resolution set to wontfix

Boost thread does not work with managed C++ when statically linked.

comment:6 Changed 4 years ago by anonymous

Is there a workaround for this other than (possibly) building boost as a dll?

comment:7 in reply to: ↑ 2 Changed 5 months ago by anonymous

Replying to roffe@…:

The linker Error LNK2022 when compiling with /clr can be resolved by adding

namespace boost {
	struct thread::dummy {};
}

after the inclusion of <boost/thread/thread.hpp>

Dynamically linked everything seems to work. However when statically linked, the application still fails to initialize with error 0xc000007b (which seems to be a different problem arising of the use of an undocumented PE hook mechanism).

For anyone finding this issue, the above fix worked great for me. The reason it fixes it is because the compiler is expecting a boost::thread::dummy() method for whatever reason and cannot find one. Adding this definition in satisfies the compiler so that it can continue. Obviously the method does nothing but it doesn't need to.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.