Compiling RTT in Windows/MinGW Native API

Status

The native API port of RTT can be found in the 1.10.x releases. Only minor issues are left and most unit tests pass.
  • it is based solely on mingw32, no msys or cygwin.
  • it use native windows threads. No need for pthreads.
  • only ports RTT, CORBA is supported as well.
  • it uses the fixes that Peter made regarding 'weak' symbol handling.
  • 1 unit test is till doing difficult
  • Priorities are supported on thread level, though creating new processes could help get better "realtime" support.

This document is slightly outdated.

Compiling RTT

  • CMake is used to generate the project: cmake -G"MinGW Makefiles" .

Linking and Compiling an application

To have something sort of working under native Win32/Visual Studio 2003 using the MinGW Compiled RTT (with the patches).

Using the info here: http://www.mingw.org/old/mingwfaq.shtml#faq-msvcdll

I managed to create DEF files, and use Microsofts LIB tool to turn the library it into something MSVC likes.

I'm no CMake expert, and don't have the time to learn **another** build scripting language, however I created the CMake files in the usual way, built RTT and ensure it compiled cleanly. I hacked the created makefiles by a search of my source tree for "--out-implib" and found that link.txt that lives in build\src\CMakeFiles\orocos-rtt-dynamic_win32.dir had that string in it. So I added the --output-def,..\..\libs\liborocos-rtt-win32.dll.def, to create the def file, and rebuilt RTT, this created the DEF file, I than ran it through the Microsoft LIB tool as described.

I then created a MSVC project, added the library to my linker settings, and made a very simply MSVC console application:

#include "rtt\os\main.h"
#include "rtt\rtt-config.h"
 
int ORO_main(int, char**)
{
      return 0;
}

I also needed to setup my MSVC preprocessor definitions:

NDEBUG
_CONSOLE
__i386__
__MINGW32__
OROCOS_TARGET=win32

Hopefully I am now at a stage when I can actually start to evaluate RTT :-) If anyone has any ideas on how to properly get the CMakeList.txt to generate the DEF files without nasty post-CMake hacks, then I would love to hear it...