Last updates on rtt/master

I have merged my last patches on master for rtt.

These are the major changes:

- All-round fixes for compiling with clang. This didn't break gcc builds, but
It would be nice if the Win32 guys could check if it didn't break theirs
- 'extern template' declarations for the RTT types in a Types.hpp header. I
checked with Visual studio documentation, this should be supported.
- Merged all win32 work I could get. The fix for CorbaConversion is still
lacking.

If anyone could assist me with setting up a hudson job for building
automatically on win32, I'd be happy to include it in my workflow such that
breakage could be sooner detected.

Please test this version as the 2.3 release won't be much different than this.
I pushed updates for rtt, ocl and log4cpp, all on master.

Peter

Last updates on rtt/master

2011/2/9 Peter Soetens <peter [..] ...>

> I have merged my last patches on master for rtt.
>
> These are the major changes:
>
> - All-round fixes for compiling with clang. This didn't break gcc builds,
> but
> It would be nice if the Win32 guys could check if it didn't break theirs
> - 'extern template' declarations for the RTT types in a Types.hpp header. I
> checked with Visual studio documentation, this should be supported.
> - Merged all win32 work I could get. The fix for CorbaConversion is still
> lacking.
>
> If anyone could assist me with setting up a hudson job for building
> automatically on win32, I'd be happy to include it in my workflow such that
> breakage could be sooner detected.
>
> Please test this version as the 2.3 release won't be much different than
> this.
> I pushed updates for rtt, ocl and log4cpp, all on master.
>
>
>
The win32 build is broken with some linking errors. I will try to fix that
this afternoon.

Philippe

Last updates on rtt/master

On Wed, Feb 9, 2011 at 7:29 PM, Philippe Hamelin
<philippe [dot] hamelin [..] ...> wrote:
> 2011/2/9 Peter Soetens <peter [..] ...>
>>
>> I have merged my last patches on master for rtt.
>>
>> These are the major changes:
>>
>> - All-round fixes for compiling with clang. This didn't break gcc builds,
>> but
>> It would be nice if the Win32 guys could check if it didn't break theirs
>> - 'extern template' declarations for the RTT types in a Types.hpp header.
>> I
>> checked with Visual studio documentation, this should be supported.
>> - Merged all win32 work I could get. The fix for CorbaConversion is still
>> lacking.
>>
>> If anyone could assist me with setting up a hudson job for building
>> automatically on win32, I'd be happy to include it in my workflow such
>> that
>> breakage could be sooner detected.
>>
>> Please test this version as the 2.3 release won't be much different than
>> this.
>> I pushed updates for rtt, ocl and log4cpp, all on master.
>>
>>
>
> The win32 build is broken with some linking errors. I will try to fix that
> this afternoon.

Can you post the missing symbols and when linking which libraries or
applications ?

Sorry for the damage, it's not easy keeping 5+ compilers happy at the same time.

Peter

Last updates on rtt/master

Le 09/02/2011 22:31, Peter Soetens a écrit :
> On Wed, Feb 9, 2011 at 7:29 PM, Philippe Hamelin
> <philippe [dot] hamelin [..] ...> wrote:
>> 2011/2/9 Peter Soetens<peter [..] ...>
>>>
>>> I have merged my last patches on master for rtt.
>>>
>>> These are the major changes:
>>>
>>> - All-round fixes for compiling with clang. This didn't break gcc builds,
>>> but
>>> It would be nice if the Win32 guys could check if it didn't break theirs
>>> - 'extern template' declarations for the RTT types in a Types.hpp header.
>>> I
>>> checked with Visual studio documentation, this should be supported.
>>> - Merged all win32 work I could get. The fix for CorbaConversion is still
>>> lacking.
>>>
>>> If anyone could assist me with setting up a hudson job for building
>>> automatically on win32, I'd be happy to include it in my workflow such
>>> that
>>> breakage could be sooner detected.
>>>
>>> Please test this version as the 2.3 release won't be much different than
>>> this.
>>> I pushed updates for rtt, ocl and log4cpp, all on master.
>>>
>>>
>>
>> The win32 build is broken with some linking errors. I will try to fix that
>> this afternoon.
>
> Can you post the missing symbols and when linking which libraries or
> applications ?

A quick feedback.

I'm also investigating this issue. There are severals problem, the
biggest one is due to some changes regarding the DataSources.

The problem arises at least with the shared libraries marshalling and
transport-corba when linking with orocos-rtt library. I think, it's due
to the explicit instantiation of the various datasources in Types*.inc
and their declarations as extern types in Types.h and RTTTypes.h. The
missing symbols are only .*DataSource ones For example:

"public: virtual bool __cdecl RTT::internal::DataSource<class
RTT::ConnPolicy>::evaluate(void)const "
(?evaluate@?$DataSource@VConnPolicy@RTT@@@internal@RTT@@UEBA_NXZ)
"__cdecl RTT::internal::ValueDataSource<class
RTT::ConnPolicy>::ValueDataSource<class RTT::ConnPolicy>(class
RTT::ConnPolicy)"

adding an ifndef WIN32 in Types*.inc, Types.h and RTTTypes.h makes the
project build, but I don't know if I keep the intended behaviour. ie,
the DataSource are not instantiated int the rtt core lib.

Since there are other missing symbols, the tests don't link completelty
with this workaround.

Last updates on rtt/master

On Thursday 10 February 2011 11:16:51 Mathieu Gautier wrote:
> Le 09/02/2011 22:31, Peter Soetens a écrit :
> > On Wed, Feb 9, 2011 at 7:29 PM, Philippe Hamelin
> >
> > <philippe [dot] hamelin [..] ...> wrote:
> >> 2011/2/9 Peter Soetens<peter [..] ...>
> >>
> >>> I have merged my last patches on master for rtt.
> >>>
> >>> These are the major changes:
> >>>
> >>> - All-round fixes for compiling with clang. This didn't break gcc
> >>> builds, but
> >>> It would be nice if the Win32 guys could check if it didn't break
> >>> theirs - 'extern template' declarations for the RTT types in a
> >>> Types.hpp header. I
> >>> checked with Visual studio documentation, this should be supported.
> >>> - Merged all win32 work I could get. The fix for CorbaConversion is
> >>> still lacking.
> >>>
> >>> If anyone could assist me with setting up a hudson job for building
> >>> automatically on win32, I'd be happy to include it in my workflow such
> >>> that
> >>> breakage could be sooner detected.
> >>>
> >>> Please test this version as the 2.3 release won't be much different
> >>> than this.
> >>> I pushed updates for rtt, ocl and log4cpp, all on master.
> >>
> >> The win32 build is broken with some linking errors. I will try to fix
> >> that this afternoon.
> >
> > Can you post the missing symbols and when linking which libraries or
> > applications ?
>
> A quick feedback.
>
> I'm also investigating this issue. There are severals problem, the
> biggest one is due to some changes regarding the DataSources.
>
> The problem arises at least with the shared libraries marshalling and
> transport-corba when linking with orocos-rtt library. I think, it's due
> to the explicit instantiation of the various datasources in Types*.inc
> and their declarations as extern types in Types.h and RTTTypes.h. The
> missing symbols are only .*DataSource ones For example:
>
> "public: virtual bool __cdecl RTT::internal::DataSource<class
> RTT::ConnPolicy>::evaluate(void)const "
> (?evaluate@?$DataSource@VConnPolicy@RTT@@@internal@RTT@@UEBA_NXZ)
> "__cdecl RTT::internal::ValueDataSource<class
> RTT::ConnPolicy>::ValueDataSource<class RTT::ConnPolicy>(class
> RTT::ConnPolicy)"
>
> adding an ifndef WIN32 in Types*.inc, Types.h and RTTTypes.h makes the
> project build, but I don't know if I keep the intended behaviour. ie,
> the DataSource are not instantiated int the rtt core lib.

The purpose of these constructs is to reduce the symbol count and instantiated
templates in each plugin, transport or component library. They are strictly
not neccessary and opt-in for each build outside RTT. You opt-in by including
the 'rtt/types/Types.hpp' header. Otherwise, it remains as in 2.2. The RTT
scripting and corba plugins have included this header as a means of 'test-
driving' it. If we can't get it to work soon, just remove (or #ifdef) the
Types.hpp include in these plugins. I'm refering to these includes:

&#10;./marsh/CPFDemarshaller.cpp:66:#include &quot;../typekit/Types.hpp&quot;&#10;./marsh/TinyDemarshaller.cpp:59:#include &quot;../typekit/Types.hpp&quot;&#10;./marsh/CPFMarshaller.cpp:41:#include &quot;../typekit/Types.hpp&quot;&#10;./transports/mqueue/MQLib.cpp:46:#include &quot;../../typekit/Types.hpp&quot;&#10;./transports/corba/CorbaLib.cpp:53:#include &quot;../../typekit/Types.hpp&quot;&#10;

>
> Since there are other missing symbols, the tests don't link completelty
> with this workaround.

I'll first test & push a fix that links the marsh and transports to the typekit
and you can see then if this works for you. If it doesn't, we'll remove these
includes.

Peter

Last updates on rtt/master

On Thursday 10 February 2011 11:49:38 Peter Soetens wrote:
> On Thursday 10 February 2011 11:16:51 Mathieu Gautier wrote:
> > Le 09/02/2011 22:31, Peter Soetens a écrit :
> > > On Wed, Feb 9, 2011 at 7:29 PM, Philippe Hamelin
> > >
> > > <philippe [dot] hamelin [..] ...> wrote:
> > >> 2011/2/9 Peter Soetens<peter [..] ...>
> > >>
> > >>> I have merged my last patches on master for rtt.
> > >>>
> > >>> These are the major changes:
> > >>>
> > >>> - All-round fixes for compiling with clang. This didn't break gcc
> > >>> builds, but
> > >>> It would be nice if the Win32 guys could check if it didn't break
> > >>> theirs - 'extern template' declarations for the RTT types in a
> > >>> Types.hpp header. I
> > >>> checked with Visual studio documentation, this should be supported.
> > >>> - Merged all win32 work I could get. The fix for CorbaConversion is
> > >>> still lacking.
> > >>>
> > >>> If anyone could assist me with setting up a hudson job for building
> > >>> automatically on win32, I'd be happy to include it in my workflow
> > >>> such that
> > >>> breakage could be sooner detected.
> > >>>
> > >>> Please test this version as the 2.3 release won't be much different
> > >>> than this.
> > >>> I pushed updates for rtt, ocl and log4cpp, all on master.
> > >>
> > >> The win32 build is broken with some linking errors. I will try to fix
> > >> that this afternoon.
> > >
> > > Can you post the missing symbols and when linking which libraries or
> > > applications ?
> >
> > A quick feedback.
> >
> > I'm also investigating this issue. There are severals problem, the
> > biggest one is due to some changes regarding the DataSources.
> >
> > The problem arises at least with the shared libraries marshalling and
> > transport-corba when linking with orocos-rtt library. I think, it's due
> > to the explicit instantiation of the various datasources in Types*.inc
> > and their declarations as extern types in Types.h and RTTTypes.h. The
> > missing symbols are only .*DataSource ones For example:
> >
> > "public: virtual bool __cdecl RTT::internal::DataSource<class
> > RTT::ConnPolicy>::evaluate(void)const "
> > (?evaluate@?$DataSource@VConnPolicy@RTT@@@internal@RTT@@UEBA_NXZ)
> > "__cdecl RTT::internal::ValueDataSource<class
> > RTT::ConnPolicy>::ValueDataSource<class RTT::ConnPolicy>(class
> > RTT::ConnPolicy)"
> >
> > adding an ifndef WIN32 in Types*.inc, Types.h and RTTTypes.h makes the
> > project build, but I don't know if I keep the intended behaviour. ie,
> > the DataSource are not instantiated int the rtt core lib.
>
> The purpose of these constructs is to reduce the symbol count and
> instantiated templates in each plugin, transport or component library.
> They are strictly not neccessary and opt-in for each build outside RTT.
> You opt-in by including the 'rtt/types/Types.hpp' header. Otherwise, it

That should have been: 'rtt/typekit/Types.hpp'

> remains as in 2.2. The RTT scripting and corba plugins have included this
> header as a means of 'test- driving' it. If we can't get it to work soon,
> just remove (or #ifdef) the Types.hpp include in these plugins. I'm
> refering to these includes:
>
> &#10;&gt; ./marsh/CPFDemarshaller.cpp:66:#include &quot;../typekit/Types.hpp&quot;&#10;&gt; ./marsh/TinyDemarshaller.cpp:59:#include &quot;../typekit/Types.hpp&quot;&#10;&gt; ./marsh/CPFMarshaller.cpp:41:#include &quot;../typekit/Types.hpp&quot;&#10;&gt; ./transports/mqueue/MQLib.cpp:46:#include &quot;../../typekit/Types.hpp&quot;&#10;&gt; ./transports/corba/CorbaLib.cpp:53:#include &quot;../../typekit/Types.hpp&quot;&#10;&gt;
>
> > Since there are other missing symbols, the tests don't link completelty
> > with this workaround.
>
> I'll first test & push a fix that links the marsh and transports to the
> typekit and you can see then if this works for you. If it doesn't, we'll
> remove these includes.

The proposed fix is pushed to master on gitorious. It shoul work much better
now.

Peter

Last updates on rtt/master

>>
>> &#10;&gt;&gt; ./marsh/CPFDemarshaller.cpp:66:#include &quot;../typekit/Types.hpp&quot;&#10;&gt;&gt; ./marsh/TinyDemarshaller.cpp:59:#include &quot;../typekit/Types.hpp&quot;&#10;&gt;&gt; ./marsh/CPFMarshaller.cpp:41:#include &quot;../typekit/Types.hpp&quot;&#10;&gt;&gt; ./transports/mqueue/MQLib.cpp:46:#include &quot;../../typekit/Types.hpp&quot;&#10;&gt;&gt; ./transports/corba/CorbaLib.cpp:53:#include &quot;../../typekit/Types.hpp&quot;&#10;&gt;&gt;
>>
>>> Since there are other missing symbols, the tests don't link completelty
>>> with this workaround.
>>
>> I'll first test& push a fix that links the marsh and transports to the
>> typekit and you can see then if this works for you. If it doesn't, we'll
>> remove these includes.
>
> The proposed fix is pushed to master on gitorious. It shoul work much better
> now.

the marshalling shared library still fail to build due to the #include
"../typekit/Types.hpp" beacause of 2 Property class missing symbols in
TinyDemarshaller.cpp:

public: virtual void __cdecl RTT::Property<class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > >::identify(class RTT::base::PropertyBagVisitor *)

public: virtual void __cdecl RTT::Property<class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > >::identify(class RTT::base::PropertyIntrospection *)

To solve the problem : in Types.inc, uncomment in Types.inc

&#10;RTT_EXPORT_TEMPLATE_TYPE(std::string)&#10;

Is it the correct fix ?

I still have some unresolved symbols, but only in the marshalling_test
and datasource_test. I'll check them.

Last updates on rtt/master

2011/2/10 Mathieu Gautier <mathieu [dot] gautier [..] ...>

> >>
> >> &#10;&gt; &gt;&gt; ./marsh/CPFDemarshaller.cpp:66:#include &quot;../typekit/Types.hpp&quot;&#10;&gt; &gt;&gt; ./marsh/TinyDemarshaller.cpp:59:#include &quot;../typekit/Types.hpp&quot;&#10;&gt; &gt;&gt; ./marsh/CPFMarshaller.cpp:41:#include &quot;../typekit/Types.hpp&quot;&#10;&gt; &gt;&gt; ./transports/mqueue/MQLib.cpp:46:#include &quot;../../typekit/Types.hpp&quot;&#10;&gt; &gt;&gt; ./transports/corba/CorbaLib.cpp:53:#include &quot;../../typekit/Types.hpp&quot;&#10;&gt; &gt;&gt;
> >>
> >>> Since there are other missing symbols, the tests don't link completelty
> >>> with this workaround.
> >>
> >> I'll first test& push a fix that links the marsh and transports to the
> >> typekit and you can see then if this works for you. If it doesn't, we'll
> >> remove these includes.
> >
> > The proposed fix is pushed to master on gitorious. It shoul work much
> better
> > now.
>
> the marshalling shared library still fail to build due to the #include
> "../typekit/Types.hpp" beacause of 2 Property class missing symbols in
> TinyDemarshaller.cpp:
>
> public: virtual void __cdecl RTT::Property<class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> > >::identify(class RTT::base::PropertyBagVisitor *)
>
> public: virtual void __cdecl RTT::Property<class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> > >::identify(class RTT::base::PropertyIntrospection
> *)
>
> To solve the problem : in Types.inc, uncomment in Types.inc
>
> &#10;&gt; RTT_EXPORT_TEMPLATE_TYPE(std::string)&#10;&gt;
>
> Is it the correct fix ?
>
> I still have some unresolved symbols, but only in the marshalling_test
> and datasource_test. I'll check them.
>
>
Are you building on linux or win32?

Philippe

Last updates on rtt/master

> I still have some unresolved symbols, but only in the marshalling_test
> and datasource_test. I'll check them.

test_discovery_strut_test also fail to build.

>
>
> Are you building on linux or win32?

only win32

Last updates on rtt/master

Le 10/02/2011 16:17, Mathieu Gautier a écrit :
>> I still have some unresolved symbols, but only in the marshalling_test
>> and datasource_test. I'll check them.

Fixed. There are three attached patches. The first one uncomment the
explicit declaration of Property<string> in Types.inc

The other two fix missing symbols and link issues in the tests.

Last updates on rtt/master

On Thursday 10 February 2011 17:03:48 Mathieu Gautier wrote:
> Le 10/02/2011 16:17, Mathieu Gautier a écrit :
> >> I still have some unresolved symbols, but only in the
> >> marshalling_test and datasource_test. I'll check them.
>
> Fixed. There are three attached patches. The first one uncomment the
> explicit declaration of Property<string> in Types.inc
>
> The other two fix missing symbols and link issues in the tests.

Thanks. We can't have patch #1 for GCC, as it causes trouble because the
ValueDataSource<string> is already instantiated in DataSources.hpp (using a
specialisation of the constructor and set() ). Note: this instantiation is
done in the orocos-rtt library, not in the rtt-typekit ! So linking with
orocos-rtt should be sufficient for fixing marshalling.

Philippe says also that it could break the building of the rtt-typekit
itself... did you test this from a clean build ?

The patch in attachment is a temptative fix to respect this kb article:
http://support.microsoft.com/kb/168958/en-us

It doesn't make a difference on Linux, but it might solve something on Windows.

Peter

Last updates on rtt/master

> Philippe says also that it could break the building of the rtt-typekit
> itself... did you test this from a clean build ?

I just did it, and rtt-typekit linked correctly.

> The patch in attachment is a temptative fix to respect this kb article:
> http://support.microsoft.com/kb/168958/en-us

I won't be able to test it until tomorrow, if your patch is working for
Philippe, I think it's ok.

Last updates on rtt/master

2011/2/10 Mathieu Gautier <mathieu [dot] gautier [..] ...>

> > Philippe says also that it could break the building of the rtt-typekit
> > itself... did you test this from a clean build ?
>
> I just did it, and rtt-typekit linked correctly.
>
> > The patch in attachment is a temptative fix to respect this kb article:
> > http://support.microsoft.com/kb/168958/en-us
>
> I won't be able to test it until tomorrow, if your patch is working for
> Philippe, I think it's ok.
>
>
I did some tests and everything builds fine with Mathieu's patches 0002 and
0003 plus a modified version of Peter's patch for the export macros (see
attachement). I also added a patch to remove the MSVC warnings about extern
templates.

For OCL, there's a missing patch on master which needs to be applied:

https://github.com/phamelin/orocos-ocl/commit/474d92a9d2be8aee75b6d09e3f...

RTT/OCL-win32 known bugs:

* RTT should NOT be build in Debug mode to work with OCL, since OCL doesn't
look for plugins DLL with "d" suffix.
* A make install has to be done prior to running RTT tests, otherwise the
tests don't find all DLLs.
* OCL::Logging and OCL::Lua aren't tested yet.

I'm a bit out of time to look at these for the next weeks. It would be very
helpful if someone could fix the "make test" on windows to make sure that it
works out-of-the-box without make install. Then, it will be easier for Peter
to put that in hudson.

Philippe

Last updates on rtt/master

On Thursday 10 February 2011 20:38:47 Philippe Hamelin wrote:
> 2011/2/10 Mathieu Gautier <mathieu [dot] gautier [..] ...>
>
> > > Philippe says also that it could break the building of the rtt-typekit
> > > itself... did you test this from a clean build ?
> >
> > I just did it, and rtt-typekit linked correctly.
> >
> > > The patch in attachment is a temptative fix to respect this kb article:
> > > http://support.microsoft.com/kb/168958/en-us
> >
> > I won't be able to test it until tomorrow, if your patch is working for
> > Philippe, I think it's ok.
>
> I did some tests and everything builds fine with Mathieu's patches 0002 and
> 0003 plus a modified version of Peter's patch for the export macros (see
> attachement). I also added a patch to remove the MSVC warnings about extern
> templates.
>
> For OCL, there's a missing patch on master which needs to be applied:
>
> https://github.com/phamelin/orocos-ocl/commit/474d92a9d2be8aee75b6d09e3f96f
> 078e6b13a90

I now applied all patches as you suggested.

>
> RTT/OCL-win32 known bugs:
>
> * RTT should NOT be build in Debug mode to work with OCL, since OCL doesn't
> look for plugins DLL with "d" suffix.

We need to fix this FindRTTPlugin.cmake macro then...

> * A make install has to be done prior to running RTT tests, otherwise the
> tests don't find all DLLs.

See my other mail about what we already do. We need to figure out why it's not
working.

> * OCL::Logging and OCL::Lua aren't tested yet.
>
> I'm a bit out of time to look at these for the next weeks. It would be very
> helpful if someone could fix the "make test" on windows to make sure that
> it works out-of-the-box without make install. Then, it will be easier for
> Peter to put that in hudson.

I have an initial windows build working on hudson. It's catching build errors
so I guess that's good :-]

Peter

Last updates on rtt/master

Le 11/02/2011 00:09, Peter Soetens a écrit :
> On Thursday 10 February 2011 20:38:47 Philippe Hamelin wrote:
>> 2011/2/10 Mathieu Gautier<mathieu [dot] gautier [..] ...>
>>
>>>> Philippe says also that it could break the building of the rtt-typekit
>>>> itself... did you test this from a clean build ?
>>>
>>> I just did it, and rtt-typekit linked correctly.
>>>
>>>> The patch in attachment is a temptative fix to respect this kb article:
>>>> http://support.microsoft.com/kb/168958/en-us
>>>
>>> I won't be able to test it until tomorrow, if your patch is working for
>>> Philippe, I think it's ok.
>>
>> I did some tests and everything builds fine with Mathieu's patches 0002 and
>> 0003 plus a modified version of Peter's patch for the export macros (see
>> attachement). I also added a patch to remove the MSVC warnings about extern
>> templates.
>>
>> For OCL, there's a missing patch on master which needs to be applied:
>>
>> https://github.com/phamelin/orocos-ocl/commit/474d92a9d2be8aee75b6d09e3f96f
>> 078e6b13a90
>
> I now applied all patches as you suggested.
>

The last master version builds fine.

--
Mathieu

--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

Last updates on rtt/master

2011/2/10 Philippe Hamelin <philippe [dot] hamelin [..] ...>

> 2011/2/10 Mathieu Gautier <mathieu [dot] gautier [..] ...>
>
>> > Philippe says also that it could break the building of the rtt-typekit
>>
>> > itself... did you test this from a clean build ?
>>
>> I just did it, and rtt-typekit linked correctly.
>>
>> > The patch in attachment is a temptative fix to respect this kb article:
>> > http://support.microsoft.com/kb/168958/en-us
>>
>> I won't be able to test it until tomorrow, if your patch is working for
>> Philippe, I think it's ok.
>>
>>
> I did some tests and everything builds fine with Mathieu's patches 0002 and
> 0003 plus a modified version of Peter's patch for the export macros (see
> attachement). I also added a patch to remove the MSVC warnings about extern
> templates.
>
> For OCL, there's a missing patch on master which needs to be applied:
>
>
> https://github.com/phamelin/orocos-ocl/commit/474d92a9d2be8aee75b6d09e3f...
>
> RTT/OCL-win32 known bugs:
>
> * RTT should NOT be build in Debug mode to work with OCL, since OCL doesn't
> look for plugins DLL with "d" suffix.
> * A make install has to be done prior to running RTT tests, otherwise the
> tests don't find all DLLs.
> * OCL::Logging and OCL::Lua aren't tested yet.
>
> I'm a bit out of time to look at these for the next weeks. It would be very
> helpful if someone could fix the "make test" on windows to make sure that it
> works out-of-the-box without make install. Then, it will be easier for Peter
> to put that in hudson.
>
>
>
I found one more bug. The make install of OCL doesn't put the components at
the right place. They are installed in :

C:\Program Files\orocos\lib\orocos\win32\ocl

I think it should be:

C:\Program Files\orocos\lib\orocos\ocl

Am I right?

Philippe

Last updates on rtt/master

On Thursday 10 February 2011 20:53:20 Philippe Hamelin wrote:
> 2011/2/10 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>
> > 2011/2/10 Mathieu Gautier <mathieu [dot] gautier [..] ...>
> >
> >> > Philippe says also that it could break the building of the rtt-typekit
> >> >
> >> > itself... did you test this from a clean build ?
> >>
> >> I just did it, and rtt-typekit linked correctly.
> >>
> >> > The patch in attachment is a temptative fix to respect this kb
> >> > article: http://support.microsoft.com/kb/168958/en-us
> >>
> >> I won't be able to test it until tomorrow, if your patch is working for
> >> Philippe, I think it's ok.
> >
> > I did some tests and everything builds fine with Mathieu's patches 0002
> > and 0003 plus a modified version of Peter's patch for the export macros
> > (see attachement). I also added a patch to remove the MSVC warnings
> > about extern templates.
> >
> > For OCL, there's a missing patch on master which needs to be applied:
> >
> >
> > https://github.com/phamelin/orocos-ocl/commit/474d92a9d2be8aee75b6d09e3f9
> > 6f078e6b13a90
> >
> > RTT/OCL-win32 known bugs:
> >
> > * RTT should NOT be build in Debug mode to work with OCL, since OCL
> > doesn't look for plugins DLL with "d" suffix.
> > * A make install has to be done prior to running RTT tests, otherwise the
> > tests don't find all DLLs.
> > * OCL::Logging and OCL::Lua aren't tested yet.
> >
> > I'm a bit out of time to look at these for the next weeks. It would be
> > very helpful if someone could fix the "make test" on windows to make
> > sure that it works out-of-the-box without make install. Then, it will be
> > easier for Peter to put that in hudson.
>
> I found one more bug. The make install of OCL doesn't put the components at
> the right place. They are installed in :
>
> C:\Program Files\orocos\lib\orocos\win32\ocl
>
> I think it should be:
>
> C:\Program Files\orocos\lib\orocos\ocl
>
> Am I right?

No. This is intended behavior and has its roots in how it's installing on
Linux. The Deployer will find components in both orocos/ocl and
orocos/win32/ocl[*] but it will only look in the latter directory on the win32
platform. This is to allow side-by-side installs like we have on
gnulinux/xenomai/lxrt systems. This was discussed on the mailinglist and
people voiced it would be better to have the same scheme on all OS's instead
of different accross OS's

The generated .pc files also point to this orocos/win32/ocl directory.

Peter

[*] if you set your component path to orocos/ and import the "ocl" package.

Last updates on rtt/master

2011/2/10 Mathieu Gautier <mathieu [dot] gautier [..] ...>

> Le 10/02/2011 16:17, Mathieu Gautier a écrit :
>
> I still have some unresolved symbols, but only in the marshalling_test
>>> and datasource_test. I'll check them.
>>>
>>
> Fixed. There are three attached patches. The first one uncomment the
> explicit declaration of Property<string> in Types.inc
>
> The other two fix missing symbols and link issues in the tests.
>
>
The first patch (0001) solve the linking error with marshalling, but broke
rtt-typekit here:

RealTimeTypekitTypes.obj : error LNK2005: "protected: virtual void *
__thiscall RTT::internal::DataSource<class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > >::`vector deleting
destructor'(unsigned int)" (??_E?$DataSource@V?$basic_string@DU
?$char_traits@D@std@@V?$allocator@D@2@@std@@@internal@RTT@@MAEPAXI@Z) déjà
défini(e) dans RealTimeTypekitConstructors.obj

Do you have the same problem?

Philippe

Last updates on rtt/master

>
> RealTimeTypekitTypes.obj : error LNK2005: "protected: virtual void *
> __thiscall RTT::internal::DataSource<class std::basic_string<char,struct
> std::char_traits<char>,class std::allocator<char> > >::`vector deleting
> destructor'(unsigned int)"
> (??_E?$DataSource@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@internal@RTT@@MAEPAXI@Z)
> déjà défini(e) dans RealTimeTypekitConstructors.obj
>
> Do you have the same problem?

No, it builds fine. I'm using vs2008 on a x64/Release to build Peter's
master with my 3 patches.

Last updates on rtt/master

2011/2/10 Mathieu Gautier <mathieu [dot] gautier [..] ...>

>
>> RealTimeTypekitTypes.obj : error LNK2005: "protected: virtual void *
>> __thiscall RTT::internal::DataSource<class std::basic_string<char,struct
>> std::char_traits<char>,class std::allocator<char> > >::`vector deleting
>> destructor'(unsigned int)"
>> (??_E?$DataSource@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D
>> @2@@std@@@internal@RTT@@MAEPAXI@Z)
>> déjà défini(e) dans RealTimeTypekitConstructors.obj
>>
>> Do you have the same problem?
>>
>
> No, it builds fine. I'm using vs2008 on a x64/Release to build Peter's
> master with my 3 patches.
>
>
There is a specialisation of ValueDataSource<string> in DataSources.hpp:

&#10;    /**&#10;     * Specialisation for std::string to keep capacity when set( ... ) is&#10;called.&#10;     */&#10;    template&lt;&gt;&#10;    RTT_API void ValueDataSource&lt;std::string&gt;::set(&#10; AssignableDataSource&lt;std::string&gt;::param_t t );&#10;

so it should generate duplicate symbols. Did you do a clean rebuild?

Philippe

Last updates on rtt/master

2011/2/10 Mathieu Gautier <mathieu [dot] gautier [..] ...>

> Le 10/02/2011 16:17, Mathieu Gautier a écrit :
>
> I still have some unresolved symbols, but only in the marshalling_test
>>> and datasource_test. I'll check them.
>>>
>>
> Fixed. There are three attached patches. The first one uncomment the
> explicit declaration of Property<string> in Types.inc
>
> The other two fix missing symbols and link issues in the tests.
>
>
The fixes 0002 and 0003 have already been submitted to Peter. It's on my
github account:
*
*
https://github.com/phamelin/orocos-rtt/commit/ad307700b77a317ff712937037...

Maybe Peter just missed these ones?

Philippe

Last updates on rtt/master

On Feb 9, 2011, at 03:50 , Peter Soetens wrote:

> I have merged my last patches on master for rtt.
>
> These are the major changes:
>
> - All-round fixes for compiling with clang. This didn't break gcc builds, but
> It would be nice if the Win32 guys could check if it didn't break theirs

Fails to build under clang v1.0.2 on macosx. See Hudson.

And it takes an incredibly long time to build ... way longer than gcc ...
S

Last updates on rtt/master

On Wed, Feb 9, 2011 at 3:09 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Feb 9, 2011, at 03:50 , Peter Soetens wrote:
>
>> I have merged my last patches on master for rtt.
>>
>> These are the major changes:
>>
>> - All-round fixes for compiling with clang. This didn't break gcc builds, but
>> It would be nice if the Win32 guys could check if it didn't break theirs
>
> Fails to build under clang v1.0.2  on macosx. See Hudson.
>
> And it takes an incredibly long time to build ... way longer than gcc ...

Don't be too hasty to draw conclusions :-)
You need clang 2.9 (master from their git), *and* their
CMAKE_BUILD_TYPE set to Release *and* compile clang with 'clang built
with gcc'. Then you build RTT and OCL with that clang. It takes 48
seconds to build RTT on my slightly overclocked system :-)

Peter
--
Orocos-Dev mailing list
Orocos-Dev [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

Last updates on rtt/master

On Feb 9, 2011, at 11:04 , Peter Soetens wrote:

> On Wed, Feb 9, 2011 at 3:09 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>> On Feb 9, 2011, at 03:50 , Peter Soetens wrote:
>>
>>> I have merged my last patches on master for rtt.
>>>
>>> These are the major changes:
>>>
>>> - All-round fixes for compiling with clang. This didn't break gcc builds, but
>>> It would be nice if the Win32 guys could check if it didn't break theirs
>>
>> Fails to build under clang v1.0.2 on macosx. See Hudson.
>>
>> And it takes an incredibly long time to build ... way longer than gcc ...
>
> Don't be too hasty to draw conclusions :-)
> You need clang 2.9 (master from their git), *and* their
> CMAKE_BUILD_TYPE set to Release *and* compile clang with 'clang built
> with gcc'. Then you build RTT and OCL with that clang. It takes 48
> seconds to build RTT on my slightly overclocked system :-)

Ok ... LOL ... didn't realise that I'd need that much configuration to build a reasonably performing compiler!

I'll try this when I get a chance.
S

Last updates on rtt/master

A Dimecres, 9 de febrer de 2011, Peter Soetens va escriure:
> I have merged my last patches on master for rtt.
>
> These are the major changes:
>
> - All-round fixes for compiling with clang. This didn't break gcc builds,
> but It would be nice if the Win32 guys could check if it didn't break
> theirs - 'extern template' declarations for the RTT types in a Types.hpp
> header. I checked with Visual studio documentation, this should be
> supported. - Merged all win32 work I could get. The fix for
> CorbaConversion is still lacking.
>
> If anyone could assist me with setting up a hudson job for building
> automatically on win32, I'd be happy to include it in my workflow such that
> breakage could be sooner detected.
>
> Please test this version as the 2.3 release won't be much different than
> this. I pushed updates for rtt, ocl and log4cpp, all on master.
>

just a small comment. I have not be able to compile toolchain 2.2.1 and master
with tao. With omniorb, I can, but i got this error:

[ 52%] Built target rtt-typekit-gnulinux_plugin
[ 52%] Generating ConfigurationInterfaceS.cpp, ConfigurationInterfaceC.cpp,
ConfigurationInterfaceS.h, ConfigurationInterfaceS.inl,
ConfigurationInterfaceC.h, ConfigurationInterfaceC.inl
/bin/sh: -Wb,export_macro=RTT_CORBA_API: not found
make[2]: *** [rtt/transports/corba/ConfigurationInterfaceS.cpp] Error 127
make[1]: *** [rtt/transports/corba/CMakeFiles/orocos-rtt-corba-
gnulinux_dynamic.dir/all] Error 2
make: *** [all] Error 2

are you aware of this?

Leo

Last updates on rtt/master

2011/2/9 Peter Soetens <peter [..] ...>

> I have merged my last patches on master for rtt.
>
> These are the major changes:
>
> - All-round fixes for compiling with clang. This didn't break gcc builds,
> but
> It would be nice if the Win32 guys could check if it didn't break theirs
> - 'extern template' declarations for the RTT types in a Types.hpp header. I
> checked with Visual studio documentation, this should be supported.
> - Merged all win32 work I could get. The fix for CorbaConversion is still
> lacking.
>
> If anyone could assist me with setting up a hudson job for building
> automatically on win32, I'd be happy to include it in my workflow such that
> breakage could be sooner detected.
>
>
Would you like to run unit tests or just build? Actually, the unit tests
doesn't work off-the-shelf. Our actual workaround was to do:

make all install test

However, I think we should fix that in a near future to avoid the "install"
before running tests.

> Please test this version as the 2.3 release won't be much different than
> this.
> I pushed updates for rtt, ocl and log4cpp, all on master.
>
>
I will give a try today.

Philippe

Last updates on rtt/master

On Wednesday 09 February 2011 14:52:09 Philippe Hamelin wrote:
> 2011/2/9 Peter Soetens <peter [..] ...>
>
> > I have merged my last patches on master for rtt.
> >
> > These are the major changes:
> >
> > - All-round fixes for compiling with clang. This didn't break gcc builds,
> > but
> > It would be nice if the Win32 guys could check if it didn't break theirs
> > - 'extern template' declarations for the RTT types in a Types.hpp header.
> > I checked with Visual studio documentation, this should be supported. -
> > Merged all win32 work I could get. The fix for CorbaConversion is still
> > lacking.
> >
> > If anyone could assist me with setting up a hudson job for building
> > automatically on win32, I'd be happy to include it in my workflow such
> > that breakage could be sooner detected.
>
> Would you like to run unit tests or just build? Actually, the unit tests
> doesn't work off-the-shelf. Our actual workaround was to do:
>
> make all install test
>
> However, I think we should fix that in a near future to avoid the "install"
> before running tests.

We don't require this on Linux. On that platform, the build contains a 'cmake -E' instruction that copies the typekit to the build/rtt/types
directory. We then set the RTT_COMPONENT_PATH to this build/rtt directory, but *relatively*, so we must enter the build/tests directory and
then it will look for typekits in "../rtt". See tests/test-runner.cpp:

&#10;    // sets environment if not set by user.                                                                                                                                                                                                  &#10;    setenv(&quot;RTT_COMPONENT_PATH&quot;,&quot;../rtt&quot;, 0);&#10;

The cmake code that does the copy is in config/rtt_macros.cmake and looks like this:

&#10;  if (PROJ_BINARY_DIR)&#10;    add_custom_command(TARGET ${name}-${OROCOS_TARGET}_plugin POST_BUILD&#10;          COMMAND ${CMAKE_COMMAND} -E make_directory ${PROJ_BINARY_DIR}/rtt/types&#10;          COMMAND ${CMAKE_COMMAND} -E copy ${TYPEKITLIB_DIR} ${PROJ_BINARY_DIR}/rtt/types&#10;          COMMENT &quot;Copying ${TYPEKITLIB_DIR} to ${PROJ_BINARY_DIR}/rtt/types &quot;)&#10;  if (WIN32)&#10;    get_target_property(DEBUG_TYPEKITLIB_DIR ${name}-${OROCOS_TARGET}_plugin DEBUG_LOCATION)&#10;    add_custom_command(TARGET ${name}-${OROCOS_TARGET}_plugin POST_BUILD&#10;      COMMAND ${CMAKE_COMMAND} -E copy ${DEBUG_TYPEKITLIB_DIR} ${PROJ_BINARY_DIR}/rtt/types&#10;      COMMENT &quot;Copying ${DEBUG_TYPEKITLIB_DIR} to ${PROJ_BINARY_DIR}/rtt/types &quot;)&#10;  endif()&#10;  endif(PROJ_BINARY_DIR)&#10;

So it already contains a provision for Win32 but we have to figure out why it doesn't do what it should. On Linux, for example, this prints to
the console:

"Copying /home/kaltan/src/git/orocos-toolchain/rtt/build/rtt/transports/mqueue/librtt-transport-mqueue-gnulinux.so to
/home/kaltan/src/git/orocos-toolchain/rtt/build/rtt/types"

Peter

Last updates on rtt/master

2011/2/10 Peter Soetens <peter [..] ...>

> On Wednesday 09 February 2011 14:52:09 Philippe Hamelin wrote:
> > 2011/2/9 Peter Soetens <peter [..] ...>
> >
> > > I have merged my last patches on master for rtt.
> > >
> > > These are the major changes:
> > >
> > > - All-round fixes for compiling with clang. This didn't break gcc
> builds,
> > > but
> > > It would be nice if the Win32 guys could check if it didn't break
> theirs
> > > - 'extern template' declarations for the RTT types in a Types.hpp
> header.
> > > I checked with Visual studio documentation, this should be supported. -
> > > Merged all win32 work I could get. The fix for CorbaConversion is still
> > > lacking.
> > >
> > > If anyone could assist me with setting up a hudson job for building
> > > automatically on win32, I'd be happy to include it in my workflow such
> > > that breakage could be sooner detected.
> >
> > Would you like to run unit tests or just build? Actually, the unit tests
> > doesn't work off-the-shelf. Our actual workaround was to do:
> >
> > make all install test
> >
> > However, I think we should fix that in a near future to avoid the
> "install"
> > before running tests.
>
> We don't require this on Linux. On that platform, the build contains a
> 'cmake -E' instruction that copies the typekit to the build/rtt/types
> directory. We then set the RTT_COMPONENT_PATH to this build/rtt directory,
> but *relatively*, so we must enter the build/tests directory and
> then it will look for typekits in "../rtt". See tests/test-runner.cpp:
>
> &#10;&gt;    // sets environment if not set by user.&#10;&gt;    setenv(&quot;RTT_COMPONENT_PATH&quot;,&quot;../rtt&quot;, 0);&#10;&gt;
>
> The cmake code that does the copy is in config/rtt_macros.cmake and looks
> like this:
>
> &#10;&gt;  if (PROJ_BINARY_DIR)&#10;&gt;    add_custom_command(TARGET ${name}-${OROCOS_TARGET}_plugin POST_BUILD&#10;&gt;          COMMAND ${CMAKE_COMMAND} -E make_directory&#10;&gt; ${PROJ_BINARY_DIR}/rtt/types&#10;&gt;          COMMAND ${CMAKE_COMMAND} -E copy ${TYPEKITLIB_DIR}&#10;&gt; ${PROJ_BINARY_DIR}/rtt/types&#10;&gt;          COMMENT &quot;Copying ${TYPEKITLIB_DIR} to ${PROJ_BINARY_DIR}/rtt/types&#10;&gt; &quot;)&#10;&gt;  if (WIN32)&#10;&gt;    get_target_property(DEBUG_TYPEKITLIB_DIR ${name}-${OROCOS_TARGET}_plugin&#10;&gt; DEBUG_LOCATION)&#10;&gt;    add_custom_command(TARGET ${name}-${OROCOS_TARGET}_plugin POST_BUILD&#10;&gt;      COMMAND ${CMAKE_COMMAND} -E copy ${DEBUG_TYPEKITLIB_DIR}&#10;&gt; ${PROJ_BINARY_DIR}/rtt/types&#10;&gt;      COMMENT &quot;Copying ${DEBUG_TYPEKITLIB_DIR} to&#10;&gt; ${PROJ_BINARY_DIR}/rtt/types &quot;)&#10;&gt;  endif()&#10;&gt;  endif(PROJ_BINARY_DIR)&#10;&gt;
>
> So it already contains a provision for Win32 but we have to figure out why
> it doesn't do what it should. On Linux, for example, this prints to
> the console:
>
> "Copying
> /home/kaltan/src/git/orocos-toolchain/rtt/build/rtt/transports/mqueue/librtt-transport-mqueue-gnulinux.so
> to
> /home/kaltan/src/git/orocos-toolchain/rtt/build/rtt/types"
>
>
I think there's a problem while file copying using CMake 2.8.1 [1], but the
first problem is that the orocos-rtt DLL isn't found. It should be in the
path or in the working directory to make it work. Do you think we should
also modify the current PATH in test-runner?

[1] http://www.vtk.org/Bug/view.php?id=10790
<http://www.vtk.org/Bug/view.php?id=10790>
Philippe