Hello,
did someone already successfully passed the RTT testcases on a Windows XP machine?
I've downloaded the Win32 git branch and followed the instructions in the Wiki (http://www.orocos.org/wiki/rtt/mingw-native) to build a native Win32 version.
I used the following tools: MinGW from the actual QT 4.5 distribution (MinGW GCC 3.4.5), the boost version 1.34.1 and the CMake binaries 2.6.4 (http://www.cmake.org/files/v2.6/cmake-2.6.4-win32-x86.exe) from the CMake homepage. I sucessfully built boost binaries and configured OROCOS RTT via CMake. I could sucessfully built the OROCOS RTT dll and all test cases but none of the test cases passed succesfully.
- state-test -
4 failures detected
- program-test -
crashed after the following log messages
...
0.015 [ Info ][SimulationThread] SimulationThread takes over system time.
0.015 [ Info ][SimulationThread] System time will increase significantly faster.
- parser-test -
freezes after the following log messages
..
3.769 [ Debug ][ExecutionEngine] Creating ExecutionEngine for space
4.097 [ Debug ][ExecutionEngine] Creating ExecutionEngine for subspace
- task-context-test -
73 failures detected
- task-test -
The application has requested the Runtime to terminate in an unusual way
- event-test -
freezes after the following log messages
...
0.225 [ Info ][SimulationThread] SimulationThread takes over system time.
0.241 [ Info ][SimulationThread] System time will increase significantly faster.
Does someone has any idea what is going wrong here. Should I provide further information? Could someone give me a direction to start for error search?
Thank you for any help.
Regards, Uwe
Status of Win32 Support and test cases
Hi Uwe,
On Wed, Jun 3, 2009 at 14:07, <uwe_kindler [..] ...> wrote:
> Hello,
>
> did someone already successfully passed the RTT testcases on a Windows XP machine?
This is work in progress. If you're still interested, you can check
out the rtt-2.0-mainline which has all 'known' win32 patches applied
to it and has had major cleanups. I'll soon remove the win32 branch
since it gets outdated. You need to 'git checkout rtt-2.0-mainline' in
the orocos-rtt directory and proceed as usual. CMake 2.6.x is required
for this version.
You could also test the cmake flag OS_NO_ASM=ON to exclude the
compilation of any assembler constructs and see if that makes a
difference. I'm aiming for MSVS *and* MINGW32 compatibility but I
haven't had time yet to actually test the latest patches on XP.
Peter
Status of Win32 Support and test cases
Hi Peter,
thank you very much for your answer. We are still very interested in OROCOS for future use in machine control projects in our company. We mainly use CANopen networks in our devices and I really would like to use OROCOS components to improve the overall design of the control applications. We use MINGW32 + QT and therfore MSVS support does not matter for me.
I will checkout the rtt-2.0-mainline to continue OROCOS evaluation. Is the os\win32 stuff the only part that I need to test and that I might need to fix or should I take care of any other parts that are relevant for RTT Win32 support?
Regards, Uwe
Status of Win32 Support and test cases
On Tue, Jun 23, 2009 at 16:17, <uwe_kindler [..] ...> wrote:
> Hi Peter,
>
> thank you very much for your answer. We are still very interested in OROCOS for future use in machine control projects in our company. We mainly use CANopen networks in our devices and I really would like to use OROCOS components to improve the overall design of the control applications. We use MINGW32 + QT and therfore MSVS support does not matter for me.
>
> I will checkout the rtt-2.0-mainline to continue OROCOS evaluation. Is the os\win32 stuff the only part that I need to test and that I might need to fix or should I take care of any other parts that are relevant for RTT Win32 support?
Yes. I tried to be as platform independent as possible outside the
os/win32 directory. The only thing not streamlined now is the
OS_NO_ASM cmake option that must be manually set in cmake in case you
don't get the assembly compiled on your platform.
Peter
Status of rtt-2.0-mainline compilation for Win32
Hi Peter,
I checked out the rtt-2.0-mainline and tried to configure and build the dynamic library and the tests. If the option BUILD_TESTING is active and the OROCOS_TARGET is win32 then I get the following error from CMake:
CMake Error at tests/CMakeLists.txt:99 (SET_TARGET_PROPERTIES):
set_target_properties called with incorrect number of arguments.
If I disable BUILD_TESTING or if I set the OROCOS_TARGET to gnulinux then the error disappears. Because it is the first time I use CMake I'm not able to fix this at the moment and have to learn more about CMake. Therefeore I disabled BUILD_TESTING for now.
During the build process a number of errors occured. I could fix two issues in win32\fosi.h: for MinGW as well because the type HANDLE and DWORD are unknown
1. #include
2. use struct oro_timespec for MinGW as well because struct timespec is not existing in MinGW
After fixing these two issues the following build error occured:
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\bin>make > makelog.txt': >'* RTT::ValueDataSource::clone() const [with T = RTT::ProgramInterface*]'* RTT::AssignableDataSource::clone() const [with T = RTT::ProgramInterface*]'* RTT::ValueDataSource::copy(std::map, std::allocator > >&) const [with T = RTT::ProgramInterface*]'* RTT::AssignableDataSource::copy(std::map, std::allocator > >&) const [with T = RTT::ProgramInterface*]'': >'* RTT::ValueDataSource::clone() const [with T = bool]'* RTT::AssignableDataSource::clone() const [with T = bool]'* RTT::ValueDataSource::copy(std::map, std::allocator > >&) const [with T = bool]'* RTT::AssignableDataSource::copy(std::map, std::allocator > >&) const [with T = bool]'
In file included from C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\CommandExecFunction.cpp:39:
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSources.hpp: In instantiation of `RTT::ValueDataSource
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSources.hpp:265: instantiated from `RTT::detail::UnboundDataSource
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/CommandExecFunction.hpp:110: instantiated from here
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSources.inl:54: error: invalid covariant return type for `RTT::DataSource
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSource.hpp:193: error: overriding `RTT::AssignableDataSource
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSources.inl:59: error: invalid covariant return type for `RTT::DataSource
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSource.hpp:195: error: overriding `RTT::AssignableDataSource
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSources.hpp: In instantiation of `RTT::ValueDataSource
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSources.hpp:265: instantiated from `RTT::detail::UnboundDataSource
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/CommandExecFunction.hpp:111: instantiated from here
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSources.inl:54: error: invalid covariant return type for `RTT::DataSource
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSource.hpp:193: error: overriding `RTT::AssignableDataSource
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSources.inl:59: error: invalid covariant return type for `RTT::DataSource
C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSource.hpp:195: error: overriding `RTT::AssignableDataSource
make[2]: *** [src/CMakeFiles/orocos-rtt-dynamic_win32.dir/CommandExecFunction.cpp.obj] Error 1
make[1]: *** [src/CMakeFiles/orocos-rtt-dynamic_win32.dir/all] Error 2
At the moment I do not have enougth knowledge about OROCOS to fix this but I will try to unterstand the design to fix this in future.
Should I try to fix this or should I wait some time until the 2.0 mainline build for win32 was sucessfully tested?
Regards, Uwe
Status of rtt-2.0-mainline compilation for Win32
On Wed, Jun 24, 2009 at 08:58, <uwe_kindler [..] ...> wrote:
> Hi Peter,
>
> I checked out the rtt-2.0-mainline and tried to configure and build the dynamic library and the tests. If the option BUILD_TESTING is active and the OROCOS_TARGET is win32 then I get the following error from CMake:
>
> CMake Error at tests/CMakeLists.txt:99 (SET_TARGET_PROPERTIES):
> set_target_properties called with incorrect number of arguments.
I fixed this, and pushed it to github.
>
> If I disable BUILD_TESTING or if I set the OROCOS_TARGET to gnulinux then the error disappears. Because it is the first time I use CMake I'm not able to fix this at the moment and have to learn more about CMake. Therefeore I disabled BUILD_TESTING for now.
>
> During the build process a number of errors occured. I could fix two issues in win32\fosi.h:
> 1. #include <windows.h> for MinGW as well because the type HANDLE and DWORD are unknown
> 2. use struct oro_timespec for MinGW as well because struct timespec is not existing in MinGW
Patch welcome !
>
> After fixing these two issues the following build error occured:
>
> C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\bin>make > makelog.txt
> In file included from C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\CommandExecFunction.cpp:39:
> C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSources.hpp: In instantiation of `RTT::ValueDataSource<RTT::ProgramInterface*>':
> C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSources.hpp:265: instantiated from `RTT::detail::UnboundDataSource<RTT::ValueDataSource
> C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSources.inl:54: error: invalid covariant return type for `RTT::DataSource<T>* RTT::ValueDataSource<T>::clone() const [with T = RTT::ProgramInterface*]'
> C:\CodingXP\Sources & Projects\orocos\orocos- rtt-2.0-mainline\src\/DataSource.hpp:193: error: overriding `RTT::AssignableDataSource<T>* RTT::AssignableDataSource<T>::clone() const [with T = RTT::ProgramInterface*]'
Which mingw32 compiler version are you using ? From cygwin ?
Aparently the traditional gcc and MSVS compilers don't have a problem
with this construct. I'll need to dig into this (or another
experienced users knows a remedy maybe ?).
> At the moment I do not have enougth knowledge about OROCOS to fix this but I will try to unterstand the design to fix this in future.
>
> Should I try to fix this or should I wait some time until the 2.0 mainline build for win32 was sucessfully tested?
When I integrated the win32 port, I was focussing on MSVC. So a
mingw32 tester is welcome, but you need to be prepared for a bumpy
ride...
The problem that the compiler reports is that we return in a sub-class
a different type in clone() than in the base class. This is allowed if
the returned type itself is also subclass of the type returned in the
base class. In our example: RTT::ValueDataSource<T>* is returned in
the subclass, and it is derived from RTT::AssignableDataSource<T>
which is returned in the base class. The compiler seems to be confused
and sees a RTT::DataSource<T>* returned in the subclass (which is not
a subclass of RTT::AssignableDataSource<T>).
So we might be hitting a compiler bug. Maybe there is a work-around,
we need to find out.
Peter
Inclusion problem
Hi Peter,
I made a small test application (see attachment) that uses the same inheritance hirarchy and could successfully compile this application. So it does not seem to be a compiler bug.
I think it is an inclusion problem because the compiler doest not know that RTT::ValueDataSource* returned in the subclass is derived from RTT::AssignableDataSource which is returned in the base class. To check this I removed the line #include "DataSource.inl" from file DataSources.inl. After this fix, at least CommandExecFunction.cpp that caused the error could compile successfully and make process goes a little bit further.
Regards, Uwe
Inclusion problem
I got a full compile of orocos-rtt-win32 with mingw, but the linking
takes forever (already more than 1h). I only have 1GB of ram, probably
I should enable -O2 to get a lower symbol count.
The patches are in attachment for your testing... They are in addition
to your earlier patch.
Peter
On Fri, Jun 26, 2009 at 11:24, <uwe_kindler [..] ...> wrote:
> Hi Peter,
>
> I made a small test application (see attachment) that uses the same
> inheritance hirarchy and could successfully compile this application. So it
> does not seem to be a compiler bug.
> I think it is an inclusion problem because the compiler doest not know that
> RTT::ValueDataSource<T>* returned in the subclass is derived from
> RTT::AssignableDataSource<T> which is returned in the base class. To check
> this I removed the line #include "DataSource.inl" from file DataSources.inl.
> After this fix, at least CommandExecFunction.cpp that caused the error could
> compile successfully and make process goes a little bit further.
>
> Regards, Uwe
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
Inclusion problem
On Fri, Jun 26, 2009 at 15:44, Peter Soetens<peter [..] ...> wrote:
> I got a full compile of orocos-rtt-win32 with mingw, but the linking
> takes forever (already more than 1h). I only have 1GB of ram, probably
> I should enable -O2 to get a lower symbol count.
>
> The patches are in attachment for your testing... They are in addition
> to your earlier patch.
Another patch that fixes some garbage in the fosi layer.
Peter
Test case bulding for Win32
Hi,
if I try to build the test cases via "make check" against the dynamic win32 RTT library I get a lot of unresolved references because most of the RTT classes that are tested in the test cases are not exported via __declspec(dllexport) (RTT_API or RTT_EXPORT).
Does this mean that the test cases should be build against the static version of the RTT library or should I add RTT_API to class declarations to export the required classes?
Uwe
Test case bulding for Win32
On Sat, Jun 27, 2009 at 21:00, <uwe_kindler [..] ...> wrote:
> Hi,
>
> if I try to build the test cases via "make check" against the dynamic win32 RTT library I get a lot of unresolved references because most of the RTT classes that are tested in the test cases are not exported via __declspec(dllexport) (RTT_API or RTT_EXPORT).
>
> Does this mean that the test cases should be build against the static version of the RTT library or should I add RTT_API to class declarations to export the required classes?
We need to enable auto exporting for now. In the long term, we'll have
the RTT_API macro's added. I believe previous attempts of running RTT
on Windows were indeed using static classes.
This link might be relevant :
<http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html>
It looks like they are exported automatically but not imported
automatically. Could you check if the linker of the unit tests uses
--enable-auto-import ? You can add it to the CMAKE_SHARED_LINKER_FLAGS
and/or CMAKE_LD_FLAGS_ADD cmake variables. You can access them with
ccmake and using 't' to toggle advanced variables.
Peter
Test case bulding for Win32
Hi Peter,
I finally managed to build and run the test cases (built against static RTT library). During build of RTT library and test cases a number of issues arised:
1.
Until now I used boost version 1.34.1. With this version building the library works fine but building test cases fails because test cases require some files (i.e. from boost folder intrusive) that does not exist in boost version 1.34.1. Then I tried to build RTT with boost 1.39. This build failed because some stuff changed in boost 1.39. Then I tried boost 1.36 - and finally I could build RTT and test cases. Therefore it would be good to state which boost version is required for building (or which boost versions are known to work). Which boost version did you use?
2.
Building test cases with dynamic RTT library failed (linker uses --enable-auto-import). Error message:
CMakeFiles\parser-test.dir\types_test.cpp.obj(.text$_ZN3RTT14DataSourceBaseC2ERKS0_[RTT::DataSourceBase::DataSourceBase(RTT::DataSourceBase const&)]+0x8):types_test.cpp: variable 'vtable for RTT::DataSourceBase
' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
The same error occured for ActionInterface and ConditionInterface.
3.
If I enable the option BUILD_STATIC the dynamic and static libraries are built. Is this option a switch (dynamic or static) or is this an addition (dynamic and static)?
4.
My MinGW version (gcc 3.4.2) (from actual QT distribution) does not have the usleep function and the RTT usleep implementation is required. I have another MinGW installation here (gcc 3.4.5) that includes usleep support. Therefore usleep implementation need to be conditional for MinGW dependig on the version that is used. Should I supply a patch that checks the GCC version for usleep implementation?
5.
If I build dynamic RTT library with boost 1.36 then I get the following error:
make[2]: *** No rule to make target `C:/CodingXP/mingw/lib/libboost_program_options-mt.a', needed by `src/liborocos-rtt-win32.dll'. Stop.
The library name is libboost_program_options-mt.lib. If I rename the library to libboost_program_options-mt.a then build finishes.
6.
When building the static RTT library then on compilation of DataSource.cpp the follwing error occures (snippet):
C:\CodingXP\Sources & Projects\orocos\orocos-rtt\src\DataSource.cpp:47: warning: function 'RTT::DataSourceBase::DataSourceBase()' is defined after prior declaration as dllimport: attribute ignored
C:\CodingXP\Sources & Projects\orocos\orocos-rtt\src\DataSource.cpp: In constructor `RTT::DataSourceBase::DataSourceBase()':
C:\CodingXP\Sources & Projects\orocos\orocos-rtt\src\DataSource.cpp:47: warning: function 'RTT::DataSourceBase::DataSourceBase()' is defined after prior declaration as dllimport: attribute ignored
C:\CodingXP\Sources & Projects\orocos\orocos-rtt\src\DataSource.cpp: In member function `void RTT::DataSourceBase::ref() const':
...
I think when building static library then RTT_API and RTT_EXPORT should be empty but they are __declspec(dllimport).
I solved this only for quick testting by manually editing rtt-config.h
7.
When static and dynamic RTT libraries are build and "make check" is executed then the linker tries to link the test cases against dynamic RTT library. I manually removed the dynamic library files and then the linker linked against the static library.
8. I did run the test cases that was built against the static library. This is the result:
Constructing a list of tests
Done constructing a list of tests
Changing directory into C:/CodingXP/Sources & Projects/orocos/orocos-rtt/bin/tests
1/ 10 Testing main-test
Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\main-test.exe"
Test timeout computed to be: 9.99988e+006
-- Process completed
Passed
2/ 10 Testing list-test
Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\list-test.exe"
Test timeout computed to be: 9.99988e+006
Running 2 test cases...
*** No errors detected
-- Process completed
Passed
3/ 10 Testing core-test
Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\core-test.exe"
Test timeout computed to be: 9.99988e+006
Running 23 test cases...
rtos_task_delete
rtos_task_delete rtos_task_delete rtos_task_delete *** No errors detected
-- Process completed
Passed
4/ 10 Testing task-test
Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\task-test.exe"
Test timeout computed to be: 9.99988e+006
Running 21 test cases...
rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_d
elete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_
task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete
rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_d
elete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_
task_delete rtos_task_delete rtos_task_delete C:/CodingXP/Sources & Projects/orocos/orocos-rtt/tests/taskthread_test.cpp(497): error in "testThreadConfig": check tt->getPriority() == 4 failed [15 != 4]
C:/CodingXP/Sources & Projects/orocos/orocos-rtt/tests/taskthread_test.cpp(501): error in "testThreadConfig": check tt == TimerThread::Instance(4,0.0123) failed
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
-- Process completed
***Failed
5/ 10 Testing event-test
Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\event-test.exe"
Test timeout computed to be: 9.99988e+006
Running 20 test cases...
rtos_task_delete rtos_task_delete rtos_task_delete
*** No errors detected
-- Process completed
Passed
6/ 10 Testing taskcontext-test
Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\taskcontext-test.exe"
Test timeout computed to be: 9.99988e+006
Running 29 test cases...
rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_d
elete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_
task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete
rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_d
elete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_ta
sk_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete r
tos_task_delete rtos_task_delete *** No errors detected
-- Process completed
Passed
7/ 10 Testing parser-test
Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\parser-test.exe"
Test timeout computed to be: 9.99988e+006
-- Process completed
Passed
8/ 10 Testing program-test
Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\program-test.exe"
Test timeout computed to be: 9.99988e+006
Running 19 test cases...
rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_d
elete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete *** No errors detected
-- Process completed
Passed
9/ 10 Testing state-test
Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\state-test.exe"
Test timeout computed to be: 9.99988e+006
Running 11 test cases...
rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_d
elete
*** No errors detected
-- Process completed
Passed
10/ 10 Testing dev-test
Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\dev-test.exe"
Test timeout computed to be: 9.99988e+006
Running 2 test cases...
*** No errors detected
-- Process completed
Passed
90% tests passed, 1 tests failed out of 10
The following tests FAILED:
4 - task-test (Failed)
Errors while running CTest
Regards, Uwe
Test case bulding for Win32
On Sun, Jun 28, 2009 at 19:23, <uwe_kindler [..] ...> wrote:
> Hi Peter,
>
> I finally managed to build and run the test cases (built against static RTT library). During build of RTT library and test cases a number of issues arised:
>
> 1.
> Until now I used boost version 1.34.1. With this version building the library works fine but building test cases fails because test cases require some files (i.e. from boost folder intrusive) that does not exist in boost version 1.34.1. Then I tried to build RTT with boost 1.39. This build failed because some stuff changed in boost 1.39. Then I tried boost 1.36 - and finally I could build RTT and test cases. Therefore it would be good to state which boost version is required for building (or which boost versions are known to work). Which boost version did you use?
I used 1.37 iirc. I want to use version macros to compile with all
versions of boost from 1.32.0 on...
>
> 2.
> Building test cases with dynamic RTT library failed (linker uses --enable-auto-import). Error message:
> CMakeFiles\parser-test.dir\types_test.cpp.obj(.text$_ZN3RTT14DataSourceBaseC2ERKS0_[RTT::DataSourceBase::DataSourceBase(RTT::DataSourceBase const&)]+0x8):types_test.cpp: variable 'vtable for RTT::DataSourceBase
> ' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details.
>
> The same error occured for ActionInterface and ConditionInterface.
Ok, I'll look at the documentation. Could you try to add
--enable-runtime-pseudo-relocs to the ld flags when linking the unit
tests ?
>
> 3.
> If I enable the option BUILD_STATIC the dynamic and static libraries are built. Is this option a switch (dynamic or static) or is this an addition (dynamic and static)?
Dynamic is always built, static is an optional 'add-on'.
>
> 4.
> My MinGW version (gcc 3.4.2) (from actual QT distribution) does not have the usleep function and the RTT usleep implementation is required. I have another MinGW installation here (gcc 3.4.5) that includes usleep support. Therefore usleep implementation need to be conditional for MinGW dependig on the version that is used. Should I supply a patch that checks the GCC version for usleep implementation?
That would be cool !
>
> 5.
> If I build dynamic RTT library with boost 1.36 then I get the following error:
> make[2]: *** No rule to make target `C:/CodingXP/mingw/lib/libboost_program_options-mt.a', needed by `src/liborocos-rtt-win32.dll'. Stop.
>
> The library name is libboost_program_options-mt.lib. If I rename the library to libboost_program_options-mt.a then build finishes.
Hmm, we should probably check for this in the boost detection...
>
> 6.
> When building the static RTT library then on compilation of DataSource.cpp the follwing error occures (snippet):
> C:\CodingXP\Sources & Projects\orocos\orocos-rtt\src\DataSource.cpp:47: warning: function 'RTT::DataSourceBase::DataSourceBase()' is defined after prior declaration as dllimport: attribute ignored
> C:\CodingXP\Sources & Projects\orocos\orocos-rtt\src\DataSource.cpp: In constructor `RTT::DataSourceBase::DataSourceBase()':
> C:\CodingXP\Sources & Projects\orocos\orocos-rtt\src\DataSource.cpp:47: warning: function 'RTT::DataSourceBase::DataSourceBase()' is defined after prior declaration as dllimport: attribute ignored
> C:\CodingXP\Sources & Projects\orocos\orocos-rtt\src\DataSource.cpp: In member function `void RTT::DataSourceBase::ref() const':
> ...
>
> I think when building static library then RTT_API and RTT_EXPORT should be empty but they are __declspec(dllimport).
>
> I solved this only for quick testting by manually editing rtt-config.h
rtt-config.h thinks we're compiling a user application. We'll have to
define RTT_NO_DLL_EXPORT when building static then and adapt
rtt-config.h to not emit these declspec statements in that case.
>
> 7.
> When static and dynamic RTT libraries are build and "make check" is executed then the linker tries to link the test cases against dynamic RTT library. I manually removed the dynamic library files and then the linker linked against the static library.
We just should fix dynamic asap :-)
>
> 8. I did run the test cases that was built against the static library. This is the result:
>
> Constructing a list of tests
> Done constructing a list of tests
> Changing directory into C:/CodingXP/Sources & Projects/orocos/orocos-rtt/bin/tests
> 1/ 10 Testing main-test
> Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\main-test.exe"
> Test timeout computed to be: 9.99988e+006
> -- Process completed
> Passed
> 2/ 10 Testing list-test
> Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\list-test.exe"
> Test timeout computed to be: 9.99988e+006
>
> Running 2 test cases...
> *** No errors detected
> -- Process completed
> Passed
> 3/ 10 Testing core-test
> Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\core-test.exe"
> Test timeout computed to be: 9.99988e+006
> Running 23 test cases...
> rtos_task_delete
> rtos_task_delete rtos_task_delete rtos_task_delete *** No errors detected
> -- Process completed
> Passed
> 4/ 10 Testing task-test
> Test command: "C:\CodingXP\Sources & Projects\orocos\orocos-rtt\bin\tests\task-test.exe"
> Test timeout computed to be: 9.99988e+006
> Running 21 test cases...
> rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_d
> elete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_
> task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete
> rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_d
> elete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_task_delete rtos_
> task_delete rtos_task_delete rtos_task_delete C:/CodingXP/Sources & Projects/orocos/orocos-rtt/tests/taskthread_test.cpp(497): error in "testThreadConfig": check tt->getPriority() == 4 failed [15 != 4]
> C:/CodingXP/Sources & Projects/orocos/orocos-rtt/tests/taskthread_test.cpp(501): error in "testThreadConfig": check tt == TimerThread::Instance(4,0.0123) failed
We can probably fix this quickly, priority issues are a low priority on XP :-)
> 90% tests passed, 1 tests failed out of 10
>
> The following tests FAILED:
> 4 - task-test (Failed)
Good ! You're really set to go (statically). That one test doesn't
really jeopardise your applications on XP.
I'm out for Robocup 2009 this week, so I'll be low profile on the list
and development/patches. Will pick up next week to test your input
myself.
Peter
RTT compiled sucessfully with MinGW
Hi Peter,
thank you very much for the patches. With all your patches applied I could successfully compile RTT from 2.0-mainline with MinGW. Linkage lasted only some minutes here.
I will now try to compile and run test cases. Should the tests compile successfully with the changes in 2.0-mainline branch or are there so much changes in that branche that test cases need to get adjusted?
Regards, Uwe
Inclusion problem
On Fri, Jun 26, 2009 at 11:24, <uwe_kindler [..] ...> wrote:
> Hi Peter,
>
> I made a small test application (see attachment) that uses the same
> inheritance hirarchy and could successfully compile this application. So it
> does not seem to be a compiler bug.
It is a compiler bug. I found out that when you move the offending
functions inside the function class body, the compiler accepts it
fine. It seems the mingw compiler has trouble linking the function
definition to the correct function declaration and gets confused. The
use of templates and multiple classes has probably something to do
with it.
I'm preparing a patch...
Peter
Status of rtt-2.0-mainline compilation for Win32
Thank you for the quick fix and the detailed explanation. I will try to find a work around.
Attached is a small patch for fosi.h that fixes the two mentioned build issues.
I use the MinGW version that is packaged with the most recent QT 4.5.1 distribution. It is not cygwin based. If I type gcc -v it prints:
gcc version 3.4.2 (mingw-special)
Just for testing I downloaded an installed the last MinGW distribution MinGW-5.1.4.exe. If I type gcc -v it prints:
gcc version 3.4.5 (mingw-vista special r3)
If I compile with this version, the same build error occures. Furthermore this new version comes with a unistd.h file that contains a int usleep(useconds_t useconds) function that conflicts with the void usleep(long us) function in the fosi.h and fosi.c file.
Regards, Uwe