For more infomation about this bug, visit
Summary: Mac OS X port
Product: RTT
Version: rtt-trunk
Platform: All
OS/Version: Other
Status: NEW
Severity: project
Priority: P3
Component: Operating System Abstraction - Portability
AssignedTo: orocos-dev [..] ...
ReportedBy: klaas [dot] gadeyne [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0
Created an attachment (id=265)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=265)
mac os x port, less than alpha version
Since the question has popped up a couple of times, I will open this one to
collect the efforts regarding a Mac OS X port of the RTT.
Mac OS X uses the posix API, however it implements almost nothing of the posix
real-time extensions (1003.1b). Note that the use of these "real-time"
extensions doesn't mean the Mac OS X port will warrant real-time behaviour of
the RTT (not at all!).
Attached is a first "less-than-alpha" patch, which modifies the gnulinux code
in order to compile on mac os x.
That said, it only compiles (you have been warned).
Some notes about the patch.
- Idealiter, I think this project would result in a posix port of the RTT, with
some ifdef statements for non-portable (e.g. as currently in the gnulinux port)
or non-implemented (as will be necessary for mac os x).
- I've tested this on a Tiger (10.4) system (a white macbook, intel cpu) using
the fink system to install dependencies (boost/cppunit).
* I don't know what the state of Leopard is regarding the posix extensions.
* Unfortunately, the cppunit port that comes with fink www.finkproject.org is
still the deprecated 1.10 version, resulting in compiler errors with the gcc on
my macbook (virtual functions, but non-virtual destructors). This is where I
gave up :-) It seems like the macports project www.darwinports.com has a more
recent version though.
- The patch solves some issues (most of them 1003.1b stuff)
* No pthread_recursive_np defined in mac os x 10.4 (they omit the np prefix)
* No clock_gettime defined in mac os x 10.4 (solved by using gettimeofday)
* No sem_timedwait defined -> THE IMPLEMENTATION JUST MAKES IT COMPILE, AND
WON'T WORK.
- It adds some cmake logic to use the fink include path in /sw. Won't be
necessary with macport I guess.
- For now, I didn't even review the patch, I just checked it compiled, ran into
the cppunit error, svn diffed it, and uploaded it here. So although I guess it
must be possible to get it working in a day or so, this is not for the
faint-hearted people amongst you :-)
Christian Louboutin
It is named Christian Louboutin for the reason that man who create Christian Louboutin shoes. At the same time, it's helpful to reduce the risk of injury for the player. If you think your feet should be protected well during the strenuous exercise, the Christian Louboutin Pumps are the right choice for you. There are many Cheap Christian Louboutin Heels from our shop. If you want to learn more informations of those Christian Louboutin Boots, please visite our website http://www.louboutinshopsale.com/. Are you looking for a comfortable shoes? We are ready for you to give you great discount Christian Louboutin Sandals and best service.
[Bug 533] Mac OS X port
For more infomation about this bug, visit
Klaas Gadeyne <klaas [dot] gadeyne [..] ...> changed:
What |Removed |Added
--------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #46 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-09-08 21:20:26 ---
If no one objects, I will delete the branches in a couple of days. In case of
problems with the port, please submit a new bug.
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #45 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-09-08 13:25:37 ---
(In reply to comment #37)
> Created an attachment (id=345)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=345) [details]
> OCL mac os x patch
>
> Dear maintainer, ...
>
> Notes:
> - has undergone same testing as rtt patch
> - Hardware stuff hasn't been tested (and won't work for mac os x without
> additional code in most cases)
> - there might still be some corba issues, but I guess they are not mac os x
> specific, so we can/should fix these later on trunk
>
> Again, Thanks Stephen!
>
$ svn ci -m"Applied patch #345 of bug #533: Mac OS X port.
> Works for me. Thanks for the hard work.
> "
Sending ocl/CMakeLists.txt
Sending ocl/INSTALL
Sending ocl/config/check_depend.cmake
Sending ocl/config/global_setup.cmake
Sending ocl/deployment/DeploymentComponent.cpp
Sending ocl/ocl/CMakeLists.txt
Sending ocl/reporting/CMakeLists.txt
Sending ocl/reporting/socket.cpp
Sending ocl/taskbrowser/CMakeLists.txt
Transmitting file data .........
Committed revision 29595.
Thanks Mac OS-X guys.
Peter
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #44 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-09-08 13:11:20 ---
(In reply to comment #36)
> Created an attachment (id=344)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=344) [details]
> patch to merge on trunk/rtt
>
> Dear RTT maintainer, please review :-)
>
> Patch has been tested on Mac OS X 10.4/10.5 with fink/macports, and it seems it
> doesn't break stuff for gnulinux build (tested on ubuntu/debian)
>
> Some notes about this patch (more info in previous comments):
> - Some tests are not yet performed (probably compiler issues)
> - cp -a doesn't work on mac os x
> - implementing sem_value() seems not straightforward
>
> Thanks Stephen Roderick for patches and testing!
>
$ svn ci -m"Merge patch #355 from bug #533: Mac OS X port.
Seems to work. Well done.
"
Sending rtt/config/CheckIncludeFileCXX.cmake
Sending rtt/config/check_depend.cmake
Sending rtt/config/global_setup.cmake
Sending rtt/configure
Sending rtt/doc/xml/orocos-installation.xml
Sending rtt/src/BufferPolicy.hpp
Sending rtt/src/os/CMakeLists.txt
Sending rtt/src/os/Semaphore.hpp
Sending rtt/src/os/SingleThread.cpp
Sending rtt/src/os/fosi.h
Sending rtt/tests/CMakeLists.txt
Sending rtt/tests/generictask_test_3.cpp
Transmitting file data ............
Committed revision 29594.
I'm very grateful for this work. This improved many aspects of the build system
and also found a 'hole' in the OS layer, learning us we shouldn't rely on
sem_value() (which is a racy function anyway). Thanks for condensing many hours
of work in such a clean patch.
What remains for RTT:
* Find out why some unit tests don't build (if they don't, the apps will
neither)
* Remove sem_value()
* Improve the orocos-rtt-*.pc files such that the private libs go into
Libs.private.
* In my setup, the cflags also contained -I/usr/include. That should be
avoided on gnulinux platforms.
Peter
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #43 from S Roderick <kiwi [dot] net [..] ...> 2008-09-06 21:03:37 ---
Created an attachment (id=349)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=349)
Fix Corba pkgconfig files for non-standard ACE/TAO location
This adds to #346 and patches RTT (on trunk) so that a non-standard location
for the ACE/TAO installation will work. This is particularly needed for Mac OS
X.
Builds fine under Linux, and also Mac OS X (with this patch, #346 and #347, out
on the macosx branch).
Fundamentally just adds values to the corba .pc file, and adds a couple of
extra ORO_ACETAO_xxx values in UseCorba.cmake.
OCL on Mac OS X now compiles with this one ... :-)
[Bug 533] Mac OS X port
On Saturday 06 September 2008 21:03:37 S Roderick wrote:
> For more infomation about this bug, visit
>
>
>
>
> --- Comment #43 from S Roderick <kiwi [dot] net [..] ...> 2008-09-06 21:03:37 ---
> Created an attachment (id=349)
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=349)
> Fix Corba pkgconfig files for non-standard ACE/TAO location
Why this :
--- src/corba/orocos-rtt-corba.pc.in (revision 29593)
+++ src/corba/orocos-rtt-corba.pc.in (working copy)
@@ -7,5 +7,5 @@
Description: Open Robot Control Software: Real-Time Tookit # human-readable
description
Requires: orocos-rtt-@OROCOS_TARGET@
Version: @RTT_VERSION@
-Libs: -L${libdir} -lorocos-rtt-corba-@OROCOS_TARGET@ @RTT_LINKFLAGS@
-Cflags:
+Libs: -L${libdir} -lorocos-rtt-corba-@OROCOS_TARGET@ @RTT_LINKFLAGS@
@RTT_CORBA_LINKFLAGS@
+Cflags: -I${includedir} -DOROCOS_TARGET=@OROCOS_TARGET@ @RTT_CFLAGS@
@RTT_CORBA_CFLAGS@
?
Since orocos-rtt-corba.pc depends on orocos-rtt-@OROCOS_TARGET@,
the "-DOROCOS_TARGET=@OROCOS_TARGET@ @RTT_CFLAGS@" flags should be added
automatically by pkg-config. I guess we can omit these.
So we should get:
orocos-rtt-.pc: directives
* Libs: only contains the -L... and -lorocos-rtt-
* Libs.private: the RTT_LINKFLAGS
* Cflags: -I${includedir} -DOROCOS_TARGET=@OROCOS_TARGET@ @RTT_CFLAGS@
orocos-rtt-corba-.pc: directives
* Libs: only contains the -L... and -lorocos-rtt-corba-
* Libs.private: the RTT_CORBA_LINKFLAGS
* Cflags: RTT_CORBA_CFLAGS
OK ?
The rest looks fine. We're really improving.
Peter
[Bug 533] Mac OS X port
On Sep 8, 2008, at 07:51 , Peter Soetens wrote:
> On Saturday 06 September 2008 21:03:37 S Roderick wrote:.pc: directives.pc:
>> For more infomation about this bug, visit
>>
>>
>>
>>
>> --- Comment #43 from S Roderick <kiwi [dot] net [..] ...> 2008-09-06
>> 21:03:37 ---
>> Created an attachment (id=349)
>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=349)
>> Fix Corba pkgconfig files for non-standard ACE/TAO location
>
> Why this :
>
> --- src/corba/orocos-rtt-corba.pc.in (revision 29593)
> +++ src/corba/orocos-rtt-corba.pc.in (working copy)
> @@ -7,5 +7,5 @@
> Description: Open Robot Control Software: Real-Time Tookit # human-
> readable
> description
> Requires: orocos-rtt-@OROCOS_TARGET@
> Version: @RTT_VERSION@
> -Libs: -L${libdir} -lorocos-rtt-corba-@OROCOS_TARGET@ @RTT_LINKFLAGS@
> -Cflags:
> +Libs: -L${libdir} -lorocos-rtt-corba-@OROCOS_TARGET@ @RTT_LINKFLAGS@
> @RTT_CORBA_LINKFLAGS@
> +Cflags: -I${includedir} -DOROCOS_TARGET=@OROCOS_TARGET@ @RTT_CFLAGS@
> @RTT_CORBA_CFLAGS@
>
> ?
>
> Since orocos-rtt-corba.pc depends on orocos-rtt-@OROCOS_TARGET@,
> the "-DOROCOS_TARGET=@OROCOS_TARGET@ @RTT_CFLAGS@" flags should be
> added
> automatically by pkg-config. I guess we can omit these.
>
> So we should get:
>
> orocos-rtt-
> * Libs: only contains the -L... and -lorocos-rtt-
> * Libs.private: the RTT_LINKFLAGS
> * Cflags: -I${includedir} -DOROCOS_TARGET=@OROCOS_TARGET@
> @RTT_CFLAGS@
>
> orocos-rtt-corba-
> * Libs: only contains the -L... and -lorocos-rtt-corba-
> directives
> * Libs.private: the RTT_CORBA_LINKFLAGS
> * Cflags: RTT_CORBA_CFLAGS
>
> OK ?
How about this then? Hope the patch comes through ok.
Successfully built RTT/KDL/OCL and our application code, in both Linux
and Mac.
Index: src/orocos-rtt.pc.in
===================================================================
--- src/orocos-rtt.pc.in (revision 29593)
+++ src/orocos-rtt.pc.in (working copy)
@@ -6,6 +6,7 @@
Name: Orocos-RTT # human-readable name
Description: Open Robot Control Software: Real-Time Tookit # human-
readable description
Version: @RTT_VERSION@
-Libs: -L${libdir} -lorocos-rtt-@OROCOS_TARGET@ @RTT_LINKFLAGS@
+Libs: -L${libdir} -lorocos-rtt-@OROCOS_TARGET@
#Libs.private: @RTT_LIBS@
+Libs.private: @RTT_LINKFLAGS@
Cflags: -I${includedir} -DOROCOS_TARGET=@OROCOS_TARGET@ @RTT_CFLAGS@
Index: src/corba/orocos-rtt-corba.pc.in
===================================================================
--- src/corba/orocos-rtt-corba.pc.in (revision 29593)
+++ src/corba/orocos-rtt-corba.pc.in (working copy)
@@ -7,5 +7,6 @@
Description: Open Robot Control Software: Real-Time Tookit # human-
readable description
Requires: orocos-rtt-@OROCOS_TARGET@
Version: @RTT_VERSION@
-Libs: -L${libdir} -lorocos-rtt-corba-@OROCOS_TARGET@ @RTT_LINKFLAGS@
-Cflags:
+Libs: -L${libdir} -lorocos-rtt-corba-@OROCOS_TARGET@
+Libs.private: @RTT_CORBA_LINKFLAGS@
+Cflags: @RTT_CORBA_CFLAGS@
[Bug 533] Mac OS X port
On Tuesday 09 September 2008 02:53:09 S Roderick wrote:
>
> How about this then? Hope the patch comes through ok.
It didn't :-)
>
> Successfully built RTT/KDL/OCL and our application code, in both Linux
> and Mac.
I forgot to add the os/macosx dir on trunk though :-]
$ svn ci -m"Merge patch #355 from bug #533: Mac OS X port.
Seems to work. Well done.
[part 2: missing add of os/macosx]
"
Adding rtt/src/os/macosx
Adding rtt/src/os/macosx/CMakeLists.txt
Adding rtt/src/os/macosx/fosi.c
Adding rtt/src/os/macosx/fosi.h
Adding rtt/src/os/macosx/fosi_internal.cpp
Adding rtt/src/os/macosx/gnuthreads.cpp
Adding rtt/src/os/macosx/macosx.h
Transmitting file data ......
Committed revision 29596.
I merged your Bugzilla patch #349 and this mail.
$ svn ci -m"Final patch from S. Roderick for getting RTT/OCL+ACE/TAO work on
Mac OS-X."
Sending rtt/config/UseCorba.cmake
Sending rtt/src/corba/CMakeLists.txt
Sending rtt/src/corba/orocos-rtt-corba.pc.in
Sending rtt/src/orocos-rtt.pc.in
Transmitting file data ....
Committed revision 29597.
Are we finally there ?
Peter
[Bug 533] Mac OS X port
>
> Are we finally there ?
Nothing further to add here.
:-)
[Bug 533] Mac OS X port
On Sep 8, 2008, at 07:51 , Peter Soetens wrote:
> On Saturday 06 September 2008 21:03:37 S Roderick wrote:
>> For more infomation about this bug, visit
>>
>>
>>
>>
>> --- Comment #43 from S Roderick <kiwi [dot] net [..] ...> 2008-09-06
>> 21:03:37 ---
>> Created an attachment (id=349)
>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=349)
>> Fix Corba pkgconfig files for non-standard ACE/TAO location
>
> Why this :
>
> --- src/corba/orocos-rtt-corba.pc.in (revision 29593)
> +++ src/corba/orocos-rtt-corba.pc.in (working copy)
> @@ -7,5 +7,5 @@
> Description: Open Robot Control Software: Real-Time Tookit # human-
> readable
> description
> Requires: orocos-rtt-@OROCOS_TARGET@
> Version: @RTT_VERSION@
> -Libs: -L${libdir} -lorocos-rtt-corba-@OROCOS_TARGET@ @RTT_LINKFLAGS@
> -Cflags:
> +Libs: -L${libdir} -lorocos-rtt-corba-@OROCOS_TARGET@ @RTT_LINKFLAGS@
> @RTT_CORBA_LINKFLAGS@
> +Cflags: -I${includedir} -DOROCOS_TARGET=@OROCOS_TARGET@ @RTT_CFLAGS@
> @RTT_CORBA_CFLAGS@
>
> ?
>
> Since orocos-rtt-corba.pc depends on orocos-rtt-@OROCOS_TARGET@,
> the "-DOROCOS_TARGET=@OROCOS_TARGET@ @RTT_CFLAGS@" flags should be
> added
> automatically by pkg-config. I guess we can omit these.
I almost did this, and went the more conservative route instead.
> So we should get:.pc: directives.pc:
>
> orocos-rtt-
> * Libs: only contains the -L... and -lorocos-rtt-
> * Libs.private: the RTT_LINKFLAGS
> * Cflags: -I${includedir} -DOROCOS_TARGET=@OROCOS_TARGET@
> @RTT_CFLAGS@
>
> orocos-rtt-corba-
> * Libs: only contains the -L... and -lorocos-rtt-corba-
> directives
> * Libs.private: the RTT_CORBA_LINKFLAGS
> * Cflags: RTT_CORBA_CFLAGS
>
> OK ?
I'm not too sure about this. I _think_ the Libs.private won't be
adequate when linking dynamic libraries on the Mac, due to it's desire
to see _all_ associated libraries when linking together a dynamic
library. Why don't I test this first.
> The rest looks fine. We're really improving.
Good! :-)
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #42 from S Roderick <kiwi [dot] net [..] ...> 2008-09-06 15:03:41 ---
(In reply to comment #41)
> (In reply to comment #38)
> > Created an attachment (id=346)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=346) [details] [details]
> > RTT Corba patch
> >
> > Get RTT to compile with corba, for non-standard install location.
> > Adds UseCorba.cmake file to encapsulate logic about varying ACE/TAO installs
> > and platforms.
> > Fixes some namespace resolution issues
> > Fixes assumptions on ACE_DIR/TAO_DIR
> >
>
> It looked ok at first sight. Let's see if other people can live with this patch
> as well...
Any chance that this patch (and #347 for KDL) can be applied on the Mac OS X
branch too? The problems these patches solve are really present out there.
This might make merging later more fun .... :-(
Thx
S
[Bug 533] Mac OS X port
On Sat, 6 Sep 2008, S Roderick wrote:
> For more infomation about this bug, visit
>
>
>
> --- Comment #42 from S Roderick <kiwi [dot] net [..] ...> 2008-09-06 15:03:41 ---
> (In reply to comment #41)
>> (In reply to comment #38)
>>> Created an attachment (id=346)
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=346) [details] [details]
>>> RTT Corba patch
>>>
>>> Get RTT to compile with corba, for non-standard install location.
>>> Adds UseCorba.cmake file to encapsulate logic about varying ACE/TAO installs
>>> and platforms.
>>> Fixes some namespace resolution issues
>>> Fixes assumptions on ACE_DIR/TAO_DIR
>>>
>>
>> It looked ok at first sight. Let's see if other people can live with this patch
>> as well...
>
> Any chance that this patch (and #347 for KDL) can be applied on the Mac OS X
> branch too? The problems these patches solve are really present out there.
I have created 2 patches to be applied 1 or 2 weeks ago. I have the impression that the corba things are not a os x specifc problem so I would really prefer to have the 2 mac os x patches reviewed and if ok, applied to trunk. I don't see the point in maintaining 2 branches just for fun (I'm not a DVCS user ;-)
Klaas
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #41 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-08-28 12:36:45 ---
(In reply to comment #38)
> Created an attachment (id=346)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=346) [details]
> RTT Corba patch
>
> Get RTT to compile with corba, for non-standard install location.
> Adds UseCorba.cmake file to encapsulate logic about varying ACE/TAO installs
> and platforms.
> Fixes some namespace resolution issues
> Fixes assumptions on ACE_DIR/TAO_DIR
>
It looked ok at first sight. Let's see if other people can live with this patch
as well...
$ svn ci -m"Applied patch #346 from Bug 533: Mac OS X port: RTT Corba Patch,
adds UseCorba.cmake"
Sending rtt/CMakeLists.txt
Sending rtt/config/FindCorbaDeps.cmake
Adding rtt/config/UseCorba.cmake
Sending rtt/src/corba/CMakeLists.txt
Sending rtt/src/corba/CorbaPort.hpp
Sending rtt/src/corba/DataFlowI.cpp
Sending rtt/tests/CMakeLists.txt
Transmitting file data .......
Committed revision 29574.
Peter
[Bug 533] Mac OS X port
Forgot to mention that this one (and the KDL one) have both been tested on a Linux system also, so hopefully no gotcha's.
[Bug 533] Mac OS X port
For more infomation about this bug, visit
Ruben Smits <ruben [dot] smits [..] ...> changed:
What |Removed |Added
--------------------------------------------------------------------------
CC| |ruben [dot] smits [..] ...
--- Comment #40 from Ruben Smits <ruben [dot] smits [..] ...> 2008-08-25 13:49:59 ---
(In reply to comment #39)
> Created an attachment (id=347)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=347) [details]
> KDL corba patch
>
> Get KDL to compile with corba, for non-standard install location.
> Add check fro Tao 1.5 and other v1.5 corrections
> Adds UseCorba.cmake file to encapsulate logic about varying ACE/TAO installs
> and platforms.
> Fixes assumptions on ACE_DIR/TAO_DIR
>
committed patch from attachment 347 to kdl
svn ci -m"See Bug #533, applying patch from Attachment 347, fixing Corba
support, thanks to S Roderick"
Sending CMakeLists.txt
Sending config/FindCorbaDeps.cmake
Sending config/TaoIDL.cmake
Adding config/UseCorba.cmake
Sending src/bindings/rtt/corba/CMakeLists.txt
Transmitting file data .....
Committed revision 29554.
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #39 from S Roderick <kiwi [dot] net [..] ...> 2008-08-25 13:21:12 ---
Created an attachment (id=347)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=347)
KDL corba patch
Get KDL to compile with corba, for non-standard install location.
Add check fro Tao 1.5 and other v1.5 corrections
Adds UseCorba.cmake file to encapsulate logic about varying ACE/TAO installs
and platforms.
Fixes assumptions on ACE_DIR/TAO_DIR
[Bug 533] Mac OS X port
For more infomation about this bug, visit
S Roderick <kiwi [dot] net [..] ...> changed:
What |Removed |Added
--------------------------------------------------------------------------
Attachment #340 is|0 |1
obsolete| |
--- Comment #38 from S Roderick <kiwi [dot] net [..] ...> 2008-08-25 13:18:40 ---
Created an attachment (id=346)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=346)
RTT Corba patch
Get RTT to compile with corba, for non-standard install location.
Adds UseCorba.cmake file to encapsulate logic about varying ACE/TAO installs
and platforms.
Fixes some namespace resolution issues
Fixes assumptions on ACE_DIR/TAO_DIR
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #37 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-08-23 20:18:28 ---
Created an attachment (id=345)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=345)
OCL mac os x patch
Dear maintainer, ...
Notes:
- has undergone same testing as rtt patch
- Hardware stuff hasn't been tested (and won't work for mac os x without
additional code in most cases)
- there might still be some corba issues, but I guess they are not mac os x
specific, so we can/should fix these later on trunk
Again, Thanks Stephen!
[Bug 533] Mac OS X port
On Saturday 23 August 2008 20:18:28 Klaas Gadeyne wrote:
> For more infomation about this bug, visit
>
>
>
>
> --- Comment #37 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-08-23
> 20:18:28 --- Created an attachment (id=345)
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=345)
> OCL mac os x patch
>
> Dear maintainer, ...
>
> Notes:
> - has undergone same testing as rtt patch
> - Hardware stuff hasn't been tested (and won't work for mac os x without
> additional code in most cases)
> - there might still be some corba issues, but I guess they are not mac os x
> specific, so we can/should fix these later on trunk
>
> Again, Thanks Stephen!
I looked at the patch, looks ok.
Ruben
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #36 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-08-23 19:53:06 ---
Created an attachment (id=344)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=344)
patch to merge on trunk/rtt
Dear RTT maintainer, please review :-)
Patch has been tested on Mac OS X 10.4/10.5 with fink/macports, and it seems it
doesn't break stuff for gnulinux build (tested on ubuntu/debian)
Some notes about this patch (more info in previous comments):
- Some tests are not yet performed (probably compiler issues)
- cp -a doesn't work on mac os x
- implementing sem_value() seems not straightforward
Thanks Stephen Roderick for patches and testing!
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #35 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-08-20 10:20:07 ---
(In reply to comment #31)
> Created an attachment (id=340)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=340) [details]
> Get Corba to work
Index: config/FindCorbaDeps.cmake
===================================================================
--- config/FindCorbaDeps.cmake (revision 29463)
+++ config/FindCorbaDeps.cmake (working copy)
@@ -63,11 +63,14 @@
FIND_PROGRAM( ORO_TAOIDL_EXECUTABLE tao_idl )
IF( NOT ORO_TAOIDL_EXECUTABLE )
- MESSAGE( FATAL "TAO Headers found but no tao_idl !")
+ MESSAGE( FATAL_ERROR "TAO Headers found but no tao_idl !")
ELSE( NOT ORO_TAOIDL_EXECUTABLE )
MESSAGE( "tao_idl: ${ORO_TAOIDL_EXECUTABLE}")
ENDIF( NOT ORO_TAOIDL_EXECUTABLE )
+ INCLUDE_DIRECTORIES(${ACE_DIR})
+ LINK_DIRECTORIES(${TAO_DIR}/../lib)
+
ENDIF (ACE_CONFIG AND TAO_ORB AND TAO_ORBSVCS )
I dont like these global directives. They should be set in
src/corba/CMakeLists.txt and not at the top level.
and:
Index: src/corba/CMakeLists.txt
===================================================================
--- src/corba/CMakeLists.txt (revision 29463)
+++ src/corba/CMakeLists.txt (working copy)
@@ -5,7 +5,11 @@
IF(ENABLE_CORBA)
MESSAGE( "CORBA Support enabled.")
# Finally:
-
+
+ IF(APPLE)
+ ADD_DEFINITIONS(-D_DARWIN_C_SOURCE)
+ ENDIF(APPLE)
+
# Add includes / lib paths if necessary
IF( NOT ${ACE_DIR} STREQUAL /usr/include )
INCLUDE_DIRECTORIES( ${ACE_DIR} )
@@ -60,6 +64,9 @@
ENDIF( BUILD_STATIC )
ADD_LIBRARY(orocos-rtt-corba_dynamic-${OROCOS_TARGET} SHARED ${CPPS})
+ TARGET_LINK_LIBRARIES(orocos-rtt-corba_dynamic-${OROCOS_TARGET}
+ orocos-rtt-dynamic_${OROCOS_TARGET}
+ TAO_AnyTypeCode)
SET_TARGET_PROPERTIES( orocos-rtt-corba_dynamic-${OROCOS_TARGET} PROPERTIES
DEFINE_SYMBOL "RTT_DLL_EXPORT"
OUTPUT_NAME orocos-rtt-corba-${OROCOS_TARGET}
For which TAO versions does this work ? Wouldn't it be better to assemble the
necessary libs in a variable in FindCorbaDeps.cmake and then use that variable
in the link directive ? In this way we can set TAO version dependent libs.
Same comment for tests/CMakeLists.txt
Peter
[Bug 533] Mac OS X port
>
> I dont like these global directives. They should be set in
> src/corba/CMakeLists.txt and not at the top level.
>
>
>
> For which TAO versions does this work ? Wouldn't it be better to
> assemble the
> necessary libs in a variable in FindCorbaDeps.cmake and then use
> that variable
> in the link directive ? In this way we can set TAO version dependent
> libs.
> Same comment for tests/CMakeLists.txt
I think I'm hitting a similar problem over and over. I've got RTT and
KDL compiling fine with Corba on the Mac, but are having troubles with
OCL. It's the same sort of trouble I had with KDL, just a lot more of
it (and I don't want to keep hacking CMake files when a better overall
solution is available, I think).
I think it stems from a mix of your above two comments, Peter. We're
not carrying around all the information about non-standard-install-
dirs (ACE+TAO in this case). From CMake output for OCL
-- Looking for orocos-rtt-corba-macosx >= 1.3.0 -- found
Detected CORBA build for macosx
-- Looking for orocos-rtt-corba-macosx -- found
Includes in: /opt/code/nrl/mac-local/include;/opt/local/include
Libraries in: /opt/code/nrl/mac-local/lib;/opt/code/local/include/
lib
Libraries: orocos-rtt-corba-macosx;orocos-rtt-
macosx;pthread;TAO;TAO_PortableServer;TAO_CosNaming;ACE
Defines: -DOROCOS_TARGET=macosx
CMake knows about the libraries it needs from the pkgconfig file, but
it isn't carrying the extra link dirs that are required. If we fill
out the associated pkgconfig information completely (defines, include
dirs and link dirs), then I think we might be able to avoid some
(all?) of the problems of modifying individual CMakeLists.txt files in
each dir. Basically, I think Orocos is already set up to handle this.
Either we should add the link-dirs, etc, data to the pkgconfig file,
or we should take out the libraries and put all that information in
some other singular place.
This problem is particularly evident on the Mac, where linking of each
dynamic library requires that all other dynamic libraries referenced
from this library be known at link time.
Thoughts?
Getting there ... definitely we're getting there ...
S
[Bug 533] Mac OS X port
On Aug 20, 2008, at 04:20 , Peter Soetens wrote:
> For more infomation about this bug, visit
>
>
>
> --- Comment #35 from Peter Soetens
<peter [dot] soetens [..] ...> > 2008-08-20 10:20:07 ---
> (In reply to comment #31)
>> Created an attachment (id=340)
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=340)
> [details]
>> Get Corba to work
>
> Index: config/FindCorbaDeps.cmake
> ===================================================================
> --- config/FindCorbaDeps.cmake (revision 29463)
> +++ config/FindCorbaDeps.cmake (working copy)
> @@ -63,11 +63,14 @@
> FIND_PROGRAM( ORO_TAOIDL_EXECUTABLE tao_idl )
>
> IF( NOT ORO_TAOIDL_EXECUTABLE )
> - MESSAGE( FATAL "TAO Headers found but no tao_idl !")
> + MESSAGE( FATAL_ERROR "TAO Headers found but no tao_idl !")
> ELSE( NOT ORO_TAOIDL_EXECUTABLE )
> MESSAGE( "tao_idl: ${ORO_TAOIDL_EXECUTABLE}")
> ENDIF( NOT ORO_TAOIDL_EXECUTABLE )
>
> + INCLUDE_DIRECTORIES(${ACE_DIR})
> + LINK_DIRECTORIES(${TAO_DIR}/../lib)
> +
> ENDIF (ACE_CONFIG AND TAO_ORB AND TAO_ORBSVCS )
>
> I dont like these global directives. They should be set in
> src/corba/CMakeLists.txt and not at the top level.
>
> and:
> Index: src/corba/CMakeLists.txt
> ===================================================================
> --- src/corba/CMakeLists.txt (revision 29463)
> +++ src/corba/CMakeLists.txt (working copy)
> @@ -5,7 +5,11 @@
> IF(ENABLE_CORBA)
> MESSAGE( "CORBA Support enabled.")
> # Finally:
> -
> +
> + IF(APPLE)
> + ADD_DEFINITIONS(-D_DARWIN_C_SOURCE)
> + ENDIF(APPLE)
> +
> # Add includes / lib paths if necessary
> IF( NOT ${ACE_DIR} STREQUAL /usr/include )
> INCLUDE_DIRECTORIES( ${ACE_DIR} )
> @@ -60,6 +64,9 @@
> ENDIF( BUILD_STATIC )
>
> ADD_LIBRARY(orocos-rtt-corba_dynamic-${OROCOS_TARGET} SHARED $
> {CPPS})
> + TARGET_LINK_LIBRARIES(orocos-rtt-corba_dynamic-${OROCOS_TARGET}
> + orocos-rtt-dynamic_${OROCOS_TARGET}
> + TAO_AnyTypeCode)
> SET_TARGET_PROPERTIES( orocos-rtt-corba_dynamic-${OROCOS_TARGET}
> PROPERTIES
> DEFINE_SYMBOL "RTT_DLL_EXPORT"
> OUTPUT_NAME orocos-rtt-corba-${OROCOS_TARGET}
>
> For which TAO versions does this work ? Wouldn't it be better to
> assemble the
> necessary libs in a variable in FindCorbaDeps.cmake and then use
> that variable
> in the link directive ? In this way we can set TAO version dependent
> libs.
> Same comment for tests/CMakeLists.txt
How about following CMake style, and adding a UseCorba.cmake file in
rtt/config? This file would add the necessary definitions, include
dirs, and link dirs as appropriate. FindCorbaDeps would then just need
to record what those additional values need to be. Each subdir/
CMakeLists.txt interested in Corba would just include the UseCorba
file, rather than individually specify the definitions, include dirs,
etc.
Thoughts?
S
ugg shoes
If you are looking for a pair of pretty UGG Boots, you shouldn't miss this chance for purchasing UGG Classic Cardy Boots this season in our shop. Ugg Bailey Button would give people such a deep impression. UGG Classic Short Boots appreciate it not only by the high quality with steady innovations but also by its stylish designs. There is no doubt that it could go well with you casual outfits. There are many kinds of UGG Classic Tall Boots for different ages and tastes online. So pick up your own UGG Sandals now.
[Bug 533] Mac OS X port
On Thursday 21 August 2008 16:36:09 S Roderick wrote:
>
> How about following CMake style, and adding a UseCorba.cmake file in
> rtt/config? This file would add the necessary definitions, include
> dirs, and link dirs as appropriate. FindCorbaDeps would then just need
> to record what those additional values need to be. Each subdir/
> CMakeLists.txt interested in Corba would just include the UseCorba
> file, rather than individually specify the definitions, include dirs,
> etc.
>
> Thoughts?
Good idea. The OCL has probably even more need for such a system than the
quite static RTT build system.
Peter
[Bug 533] Mac OS X port
On Aug 28, 2008, at 05:34 , Peter Soetens wrote:
> On Thursday 21 August 2008 16:36:09 S Roderick wrote:
>>
>> How about following CMake style, and adding a UseCorba.cmake file in
>> rtt/config? This file would add the necessary definitions, include
>> dirs, and link dirs as appropriate. FindCorbaDeps would then just
>> need
>> to record what those additional values need to be. Each subdir/
>> CMakeLists.txt interested in Corba would just include the UseCorba
>> file, rather than individually specify the definitions, include dirs,
>> etc.
>>
>> Thoughts?
>
> Good idea. The OCL has probably even more need for such a system
> than the
> quite static RTT build system.
Yes, OCL is definitely a different beast. I noticed that it pulls some
of the libraries and flags out of the pkgconfig files for RTT (and
prob. for KDL, I imagine). Problem is (and I thought I previously
posted on this, but can't find it ...) that the Corba libraries are in
the pkgconfig data, but not the additional compiler defines that are
actually needed to compile against.
Also, I noticed a bug in the Mac version in that the corba libraries
are in both the orocos-rtt-macosx pkgconfig as well as the orocos-rtt-
corba-macosx. This is not the case with the Linux version. I will look
into it.
So the question is, when dealing with Corba in OCL, does OCL go
looking for it with a pair of FindCorba/UseCorba cmake files, or do we
use data out of RTT's pkgconfig files (which means we'd have to update
RTT to put out everything required)?
Cheers
S
[Bug 533] Mac OS X port
On Thursday 28 August 2008 13:47:39 S Roderick wrote:
> On Aug 28, 2008, at 05:34 , Peter Soetens wrote:
> > On Thursday 21 August 2008 16:36:09 S Roderick wrote:
> >> How about following CMake style, and adding a UseCorba.cmake file in
> >> rtt/config? This file would add the necessary definitions, include
> >> dirs, and link dirs as appropriate. FindCorbaDeps would then just
> >> need
> >> to record what those additional values need to be. Each subdir/
> >> CMakeLists.txt interested in Corba would just include the UseCorba
> >> file, rather than individually specify the definitions, include dirs,
> >> etc.
> >>
> >> Thoughts?
> >
> > Good idea. The OCL has probably even more need for such a system
> > than the
> > quite static RTT build system.
>
> Yes, OCL is definitely a different beast. I noticed that it pulls some
> of the libraries and flags out of the pkgconfig files for RTT (and
> prob. for KDL, I imagine). Problem is (and I thought I previously
> posted on this, but can't find it ...) that the Corba libraries are in
> the pkgconfig data, but not the additional compiler defines that are
> actually needed to compile against.
Then these should be added in the orocos-rtt-corba-.pc file as well
(and used by the OCL cmake logic)... I believe they were not included because
the Linux version did not require them.
Peter
[Bug 533] Mac OS X port
On Aug 28, 2008, at 08:18 , Peter Soetens wrote:
> On Thursday 28 August 2008 13:47:39 S Roderick wrote:.pc file
>> On Aug 28, 2008, at 05:34 , Peter Soetens wrote:
>>> On Thursday 21 August 2008 16:36:09 S Roderick wrote:
>>>> How about following CMake style, and adding a UseCorba.cmake file
>>>> in
>>>> rtt/config? This file would add the necessary definitions, include
>>>> dirs, and link dirs as appropriate. FindCorbaDeps would then just
>>>> need
>>>> to record what those additional values need to be. Each subdir/
>>>> CMakeLists.txt interested in Corba would just include the UseCorba
>>>> file, rather than individually specify the definitions, include
>>>> dirs,
>>>> etc.
>>>>
>>>> Thoughts?
>>>
>>> Good idea. The OCL has probably even more need for such a system
>>> than the
>>> quite static RTT build system.
>>
>> Yes, OCL is definitely a different beast. I noticed that it pulls
>> some
>> of the libraries and flags out of the pkgconfig files for RTT (and
>> prob. for KDL, I imagine). Problem is (and I thought I previously
>> posted on this, but can't find it ...) that the Corba libraries are
>> in
>> the pkgconfig data, but not the additional compiler defines that are
>> actually needed to compile against.
>
> Then these should be added in the orocos-rtt-corba-
> as well
> (and used by the OCL cmake logic)... I believe they were not
> included because
> the Linux version did not require them.
The RTT_CFLAGS, RTT_LINKFLAGS, etc., variables appear to be project-
wide global flags for everything to build against. They also end up in
the pkgconfig files. Problem is, Orocos is currently mixing Corba-
related variables in there (see rtt/src/corba/CMakeLists.txt). This
pollutes the non-corba RTT pkgconfig file on non-Linux installations
(and most likley, on Linux installations with a Corba distribution in
a non-standard location).
Are the corba-related variables only needed by the corba-related
RTTdirectories (src/corba/ and the corba_test in tests/)? If this is
the case, I think the src/corba/CMakeLists.txt file should be modified
to not affect the global RTT_FLAGS, etc. If other directories and
source files do need access to these corba-related variables, then I
think we need to separate them out into RTT_CFLAGS and
RTT_CORBA_CFLAGS (or something similar). A question then is does the
corba RTT pkgconfig file then need both RTT_CFLAGS and
RTT_CORBA_CFLAGS, or just the corba flags?
Thoughts?
S
[Bug 533] Mac OS X port
On Sunday 31 August 2008 16:43:59 S Roderick wrote:.pc file
> On Aug 28, 2008, at 08:18 , Peter Soetens wrote:
> > On Thursday 28 August 2008 13:47:39 S Roderick wrote:
> >> On Aug 28, 2008, at 05:34 , Peter Soetens wrote:
> >>> On Thursday 21 August 2008 16:36:09 S Roderick wrote:
> >>>> How about following CMake style, and adding a UseCorba.cmake file
> >>>> in
> >>>> rtt/config? This file would add the necessary definitions, include
> >>>> dirs, and link dirs as appropriate. FindCorbaDeps would then just
> >>>> need
> >>>> to record what those additional values need to be. Each subdir/
> >>>> CMakeLists.txt interested in Corba would just include the UseCorba
> >>>> file, rather than individually specify the definitions, include
> >>>> dirs,
> >>>> etc.
> >>>>
> >>>> Thoughts?
> >>>
> >>> Good idea. The OCL has probably even more need for such a system
> >>> than the
> >>> quite static RTT build system.
> >>
> >> Yes, OCL is definitely a different beast. I noticed that it pulls
> >> some
> >> of the libraries and flags out of the pkgconfig files for RTT (and
> >> prob. for KDL, I imagine). Problem is (and I thought I previously
> >> posted on this, but can't find it ...) that the Corba libraries are
> >> in
> >> the pkgconfig data, but not the additional compiler defines that are
> >> actually needed to compile against.
> >
> > Then these should be added in the orocos-rtt-corba-
> > as well
> > (and used by the OCL cmake logic)... I believe they were not
> > included because
> > the Linux version did not require them.
>
> The RTT_CFLAGS, RTT_LINKFLAGS, etc., variables appear to be project-
> wide global flags for everything to build against.
No they aren't. They are only meant for the pkgconfig files. Project wide
global flags are set using the CMAKE equivalents. That's because the flags
with which you link/compile your application are different than those we use
to build the library itself.
> They also end up in
> the pkgconfig files. Problem is, Orocos is currently mixing Corba-
> related variables in there (see rtt/src/corba/CMakeLists.txt).
That's a trick: they are temporarily extended (scope is corba subdir) to
generate the orocos-rtt-corba .pc file.
> This
> pollutes the non-corba RTT pkgconfig file on non-Linux installations
> (and most likley, on Linux installations with a Corba distribution in
> a non-standard location).
There are certainly bugs in these flags, when I set it up, it was the first
time I worked with .pc files. Normally the TAO libs must be listed in the
Libs.private, because you only need to know them when linking against the
static orocos-rtt-corba library. So the first bug seems that the
RTT_LINKFLAGS must be set in that section and not in the Libs section...
Pollution only happens if the variable is stored in an ENV{} construct.
>
> Are the corba-related variables only needed by the corba-related
> RTTdirectories (src/corba/ and the corba_test in tests/)? If this is
> the case, I think the src/corba/CMakeLists.txt file should be modified
> to not affect the global RTT_FLAGS, etc. If other directories and
> source files do need access to these corba-related variables, then I
> think we need to separate them out into RTT_CFLAGS and
> RTT_CORBA_CFLAGS (or something similar). A question then is does the
> corba RTT pkgconfig file then need both RTT_CFLAGS and
> RTT_CORBA_CFLAGS, or just the corba flags?
The plain orocos-rtt .pc file is corba independent. The orocos-rtt-corba .pc
file adds the corba flags. It should work already like that, or it's a bug.
Peter
[Bug 533] Mac OS X port
On Thursday 28 August 2008 13:47:39 S Roderick wrote:
>
> So the question is, when dealing with Corba in OCL, does OCL go
> looking for it with a pair of FindCorba/UseCorba cmake files, or do we
> use data out of RTT's pkgconfig files (which means we'd have to update
> RTT to put out everything required)?
The current way is detecting if the orocos-rtt-corba-.pc file is
there, and if so, store the TAO flags found in there in
OROCOS_RTT_CORBA_LIBS. So we use the exact same settings as detected by the
RTT. In which way would you improve this ?
Peter
[Bug 533] Mac OS X port
Peter, Stephen,
On Wed, 20 Aug 2008, Peter Soetens wrote:
> For more infomation about this bug, visit
> --- Comment #35 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-08-20 10:20:07 ---
> (In reply to comment #31)
>> Created an attachment (id=340)
> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=340) [details]
>> Get Corba to work
I have a feeling we're mixing OS X specific and non-specific changesets here. I would prefer to have some stuff (e.g.) merged on trunk first, and then evaluate/apply an OS X specific patch onto the branch. That will make it easier to evaluate the patches (they should be much smaller for a start). Thoughts?
Klaas
[Bug 533] Mac OS X port
> On Wed, 20 Aug 2008, Peter Soetens wrote:
>> For more infomation about this bug, visit
>> --- Comment #35 from Peter Soetens
<peter [dot] soetens [..] ...> >> 2008-08-20 10:20:07 ---
>> (In reply to comment #31)
>>> Created an attachment (id=340)
>> --> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=340)
>> [details]
>>> Get Corba to work
>
> I have a feeling we're mixing OS X specific and non-specific
> changesets here. I would prefer to have some stuff (e.g.
> patch onto the branch. That will make it easier to evaluate the
> patches (they should be much smaller for a start). Thoughts?
Agreed. If you consider that #581 is a valid bug that needs fixing, it
makes sense to apply it to the trunk first. I was personally not
considering it OS X specific, just that it had been noticed while
doing work on that branch.
S
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #34 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-08-20 10:08:50 ---
(In reply to comment #31)
> Created an attachment (id=340)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=340) [details]
> Get Corba to work
[...]
> The attached patch is required. I'm not happy with a couple of bits of it,
> particularly the mod's to `config/FindCorbaDeps.cmake`. Seems a little heavy
> handed. Also the explicit namespace resolution is required (we've seen this
> before with some of our code, not sure why the Mac gcc complains about this),
> but I've no real qualms with this.
It's a bug in the compiler, it's valid C++.
>
> The last mod's, to tests/corba_test.c I think bring up a different issue. The
> explicit casting is required, and I think is due to a bug or an inconsistency
> in the interface. Internally, Corba::ControlTaskProxy::Create() actually
> returns a Corba::ControlTaskProxy*, but the return type is TaskContext*. That
> is not correct, as a ControlTaskProxy is multiply derived from TaskContext and
> ApplicationServer. If you cast it to TaskContext*, you will at some point get
> some "interesting" behaviour. Shouldn't the return type be
> Corba::ControlTaskProxy*?
This was a bug and fixed in r29487. A previous patch had changed the interface
from returning an ControlTaskProxy* to returning a TaskContext*. This was
necessary because the ControlTaskProxy may in fact return the *real*
TaskContext in case the TaskContext is in the same process and thus no proxy is
needed.
The unit test's corba_test.h needed to be changed to TaskContext*. Your patch
for corba_test.cpp is wrong.
Peter
[Bug 533] Mac OS X port
> It's a bug in the compiler, it's valid C++.
Ok, but is that part of the patch acceptable? I presume it won't bother non-buggy compilers? (which I will go and test now)
>> The last mod's, to tests/corba_test.c I think bring up a different >> issue. The >> explicit casting is required, and I think is due to a bug or an >> inconsistency >> in the interface. Internally, Corba::ControlTaskProxy::Create() >> actually >> returns a Corba::ControlTaskProxy*, but the return type is >> TaskContext*. That >> is not correct, as a ControlTaskProxy is multiply derived from >> TaskContext and >> ApplicationServer. If you cast it to TaskContext*, you will at some >> point get >> some "interesting" behaviour. Shouldn't the return type be >> Corba::ControlTaskProxy*? >> This was a bug and fixed in r29487. A previous patch had changed the > interface > from returning an ControlTaskProxy* to returning a TaskContext*. > This was > necessary because the ControlTaskProxy may in fact return the *real* > TaskContext in case the TaskContext is in the same process and thus > no proxy is > needed. > The unit test's corba_test.h needed to be changed to TaskContext*. > Your patch > for corba_test.cpp is wrong.
Ok, will fix this. S
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #33 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-08-19 22:28:32 ---
Replaced all check_include_file macros with find_path statements. Sees to work
fine (although I can't test linux specific hardware stuff). Please test.
[Bug 533] Mac OS X port
> --- Comment #33 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> > 2008-08-19 22:28:32 --- > Replaced all check_include_file macros with find_path statements. > Sees to work > fine (although I can't test linux specific hardware stuff). Please > test.
Confirm that the macosx branch (r29517) compiles - RTT fine on both Mac OS X and Ubuntu Gutsy (ie Orocos gnulinux). - KDL fine on both Mac and Ubuntu, but is having problems installing on Mac as one of the generated files in the corba bindings is missing (I'll look at it another time) - OCL fine on Ubuntu
This tree does include some recent patches that aren't yet committed.
I also did not need to explicitly specify where Boost was to cmake. It found it for itself! :-) S
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #32 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-08-18 21:44:37 ---
(In reply to comment #27)
> Created an attachment (id=333)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=333)
> Fixes socket option differences in reporting
Committed this with 2 small changes:
- Fixed the ifdef __DARWIN__
- Fixed a compile error in your patch, where you called setsockopt(). the
socket variable was not known over there, I guess you meant mainClass->socket.
Can you test and confirm? TIA!
(ps. Hope this comes through, I'm posting this via my mylyn bugzilla
connector)
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #31 from S Roderick <kiwi [dot] net [..] ...> 2008-08-17 21:11:40 ---
Created an attachment (id=340)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=340)
Get Corba to work
This is a PITA ... but the corba-test now passes. :-)
I'll document the whole thing, as it is a tiny bit involved
Downloaded ACE+TAO 5.6.5. Built with standard "configure; make; make install"
and installed to non-standard (/usr/include, etc) location.
The ACE install does not copy some of the files we need from the source dir to
the install dir. Have not yet found a configuration option that controls this.
Manually copy the following files from /path/to/source/ACE_WRAPPERS to
/path/to/ace/install/
ace/Svc_Conf_Token_Table.h
ace/Unbounded_Set_Ex.h
ace/Unbounded_Set_Ex.inl
ace/Unbounded_Set_Ex.cpp
For Mac OS X 10.5.4 plus Macports
export ACE_ROOT=/path/to/ace/install/include
export TAO_ROOT=/path/to/ace/install/include
export CMAKE_INCLUDE_DIR=/opt/local/include
export CMAKE_PROGRAM_PATH=/path/to/ace/install/bin
ccmake -DBOOST_INSTALL=/opt/local/include ..
make
Add /path/to/ace/install/lib to DYLD_LIBRARY_PATH and then
make check
./tests/corba-test
The attached patch is required. I'm not happy with a couple of bits of it,
particularly the mod's to `config/FindCorbaDeps.cmake`. Seems a little heavy
handed. Also the explicit namespace resolution is required (we've seen this
before with some of our code, not sure why the Mac gcc complains about this),
but I've no real qualms with this.
The last mod's, to tests/corba_test.c I think bring up a different issue. The
explicit casting is required, and I think is due to a bug or an inconsistency
in the interface. Internally, Corba::ControlTaskProxy::Create() actually
returns a Corba::ControlTaskProxy*, but the return type is TaskContext*. That
is not correct, as a ControlTaskProxy is multiply derived from TaskContext and
ApplicationServer. If you cast it to TaskContext*, you will at some point get
some "interesting" behaviour. Shouldn't the return type be
Corba::ControlTaskProxy*?
S
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #30 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-08-12 09:54:27 ---
(In reply to comment #26)
> Further patch to get OCL to compile/install. In Mac OS X (10.5 at least) you
> need to link a dynamic library with _all_ dynamic libraries that it uses.
>
> Hope the formatting is good Peter ... :-)
>
> {{{
> Index: config/component_rules.cmake
> ===================================================================
> --- config/component_rules.cmake (revision 29463)
> +++ config/component_rules.cmake (working copy)
> @@ -79,6 +79,9 @@
> foreach(lib ${OROCOS_RTT_LIBS})
> TARGET_LINK_LIBRARIES( ${LIB_NAME} ${lib} )
> endforeach(lib in ${OROCOS_RTT_LIBS})
> + foreach(lib ${KDL_LIBS})
> + TARGET_LINK_LIBRARIES( ${LIB_NAME} ${lib} )
> + endforeach(lib in ${KDL_LIBS})
>
> ELSE (OROCOS_RTT_1.4)
> IF (OROCOS_RTT_1.2)
> }}}
I'm reluctant to apply this patch. If your component uses an 'external' library
(kdl, opencv,...), it should link with it using COMPONENT_ADD_LIBS, such as
COMPONENT_ADD_LIBS( mycomponent ${KDL_LIBS} )
Which OCL component requires this ? In that case, it's CMakeLists.txt file
needs to be fixed instead.
Peter
[Bug 533] Mac OS X port
[Bug 533] Mac OS X port
On Tuesday 12 August 2008 13:58:22 S Roderick wrote:
> {{{
> Index: ../motion_control/naxes/CMakeLists.txt
> ===================================================================
> --- ../motion_control/naxes/CMakeLists.txt (revision 29463)
> +++ ../motion_control/naxes/CMakeLists.txt (working copy)
> @@ -12,4 +12,6 @@
> GLOBAL_ADD_COMPONENT( orocos-naxes ${SRCS} )
> GLOBAL_ADD_INCLUDE( ocl ${HPPS})
>
> + COMPONENT_ADD_LIBS(orocos-naxes ${KDL_LIBS})
> +
> ENDIF ( BUILD_NAXES )
> }}}
Ruben's turf, but since he's on holidays...
$ svn di; svn ci CMakeLists.txt -m"Applied patch from S Roderick
<kiwi [dot] net [..] ...>: Link naxes with kdl libraries."
Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt (revision 29474)
+++ CMakeLists.txt (working copy)
@@ -11,5 +11,6 @@
GLOBAL_ADD_COMPONENT( orocos-naxes ${SRCS} )
GLOBAL_ADD_INCLUDE( ocl ${HPPS})
+ COMPONENT_ADD_LIBS(orocos-naxes ${KDL_LIBS})
ENDIF ( BUILD_NAXES )
Sending CMakeLists.txt
Transmitting file data .
Committed revision 29475.
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #29 from S Roderick <kiwi [dot] net [..] ...> 2008-08-08 14:08:52 ---
Tried the following
{{{
export CMAKE_INCLDUE_PATH=/opt/local/include
export CMAKE_LIBRARY_PATH=/opt/local/sw
ccmake ..
}}}
with RTT. CMake immediately failed to find boost headers.
:-(
[Bug 533] Mac OS X port
On Fri, 8 Aug 2008, S Roderick wrote:
> For more infomation about this bug, visit
>
>
>
> --- Comment #29 from S Roderick <kiwi [dot] net [..] ...> 2008-08-08 14:08:52 ---
> Tried the following
> {{{
> export CMAKE_INCLDUE_PATH=/opt/local/include
> export CMAKE_LIBRARY_PATH=/opt/local/sw
> ccmake ..
> }}}
> with RTT. CMake immediately failed to find boost headers.
Hey Stephen,
for boost, that's no surprise, I haven't adapted it (yet), since you can configure that in the ccmake interface via the variable boost_install!
For sure this should be changed to in the final version.
(Our http:// connections seem to fail, so I'm writing this answer in an email instead)
Can you try again (please :-)?
Klaas
[Bug 533] Mac OS X port
Ok, here's what I know
- we're using two (2) different CMake methods to find files for boost,
readline, etc. In RTT we use the hacked CHECK_INCLUDE_FILE_CXX() while
OCL uses FIND_PATH
- FIND_PATH _will_ use the CMAKE_INCLUDE_PATH if specified in the
environment. Occasionally we have to use the CMake-suggested back to
back checks of FIND_PATH with the additional NO_DEFAULT_PATH to the
first option (e.g. readline on Mac OS X with a different version
installed by a package manager. Could easily happen in Linux also
though less likely)
- for me, OCL tends to find things better than RTT does
- one of my previous patches that you questioned the necessity for is
taken care of using FIND_PATH and CMAKE_INCLUDE_PATH, so we could
clean some things up there
Personally, I would hope that the project could decide on one method
or the other and use it in all places. CMake logic can be fun enough,
without choosing two different ways to do things. :-)
I would suggest standardizing on FIND_PATH as it does take into
account CMAKE_INCLUDE_PATH and also it has the counterpart
FIND_LIBRARY to find library files using the same approach.
Thoughts?
S
On Aug 8, 2008, at 10:15 , Klaas Gadeyne wrote:
> On Fri, 8 Aug 2008, S Roderick wrote:
>> For more infomation about this bug, visit
>>
>>
>>
>> --- Comment #29 from S Roderick <kiwi [dot] net [..] ...> 2008-08-08
>> 14:08:52 ---
>> Tried the following
>> {{{
>> export CMAKE_INCLDUE_PATH=/opt/local/include
>> export CMAKE_LIBRARY_PATH=/opt/local/sw
>> ccmake ..
>> }}}
>> with RTT. CMake immediately failed to find boost headers.
>
> Hey Stephen,
>
> for boost, that's no surprise, I haven't adapted it (yet), since you
> can configure that in the ccmake interface via the variable
> boost_install!
> For sure this should be changed to in the final version.
>
> (Our http:// connections seem to fail, so I'm writing this answer in
> an email instead)
>
> Can you try again (please :-)?
>
> Klaas
>
[Bug 533] Mac OS X port
On Sat, Aug 9, 2008 at 4:06 PM, Stephen Roderick <kiwi [dot] net [..] ...> wrote:
> Ok, here's what I know
>
> - we're using two (2) different CMake methods to find files for boost,
> readline, etc. In RTT we use the hacked CHECK_INCLUDE_FILE_CXX() while OCL
> uses FIND_PATH
> - FIND_PATH _will_ use the CMAKE_INCLUDE_PATH if specified in the
> environment. Occasionally we have to use the CMake-suggested back to back
> checks of FIND_PATH with the additional NO_DEFAULT_PATH to the first option
> (e.g. readline on Mac OS X with a different version installed by a package
> manager. Could easily happen in Linux also though less likely)
> - for me, OCL tends to find things better than RTT does
> - one of my previous patches that you questioned the necessity for is taken
> care of using FIND_PATH and CMAKE_INCLUDE_PATH, so we could clean some
> things up there
>
> Personally, I would hope that the project could decide on one method or the
> other and use it in all places. CMake logic can be fun enough, without
> choosing two different ways to do things. :-)
>
> I would suggest standardizing on FIND_PATH as it does take into account
> CMAKE_INCLUDE_PATH and also it has the counterpart FIND_LIBRARY to find
> library files using the same approach.
>
> Thoughts?
Yep :-)
See the thread on orocos-dev on "cmake CHECK_INCLUDE_FILE_CXX macro"
(our internet connection is still down :-((().
To sum up:
- I completely agree with all of the above.
- *IIRC* (no internet indeed...), the reason why I didn't merge the
patch you are referring to, was that it was overly complex (it
contained fixed paths that should have been submitted via the
CMAKE_INCLUDE_PATH variable instead).
Although the weather was bad this weekend, I spent too much time
watching the olympics, so patches are warmly welcomed :-)
Klaas
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #28 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-08-08 09:54:54 ---
(In reply to comment #27)
> Created an attachment (id=333)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=333) [details]
> Fixes socket option differences in reporting
Thx for the patch. Will have at look at it soon if Belgian weather stays as it
is today :-)
Is there a reason why you use #if __APPLE__ in one place and #if __DARWIN__ in
the other?
ps. Did you have a chance to test this one yet?
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #27 from S Roderick <kiwi [dot] net [..] ...> 2008-08-07 13:42:20 ---
Created an attachment (id=333)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=333)
Fixes socket option differences in reporting
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #26 from S Roderick <kiwi [dot] net [..] ...> 2008-08-06 14:31:39 ---
Further patch to get OCL to compile/install. In Mac OS X (10.5 at least) you
need to link a dynamic library with _all_ dynamic libraries that it uses.
Hope the formatting is good Peter ... :-)
{{{
Index: config/component_rules.cmake
===================================================================
--- config/component_rules.cmake (revision 29463)
+++ config/component_rules.cmake (working copy)
@@ -79,6 +79,9 @@
foreach(lib ${OROCOS_RTT_LIBS})
TARGET_LINK_LIBRARIES( ${LIB_NAME} ${lib} )
endforeach(lib in ${OROCOS_RTT_LIBS})
+ foreach(lib ${KDL_LIBS})
+ TARGET_LINK_LIBRARIES( ${LIB_NAME} ${lib} )
+ endforeach(lib in ${KDL_LIBS})
ELSE (OROCOS_RTT_1.4)
IF (OROCOS_RTT_1.2)
}}}
[Bug 533] Mac OS X port
For more infomation about this bug, visit
--- Comment #25 from S Roderick <kiwi [dot] net [..] ...> 2008-07-17 13:39:00 ---
(In reply to comment #23)
> (In reply to comment #20)
> > Created an attachment (id=332)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=332) [details] [details]
> > Fixes problems with cmake 2.4.6 and macports under 10.5.4
> > Side issue - we need to use a consistent method of adding package-related paths to statements like FIND_PATH and FIND_LIBRARY.
>
> Do you refer to the NO_DEFAULT_PATH statements here?
No. I had to hardwire in the default MacPorts path to the FIND_XXX calls.
Notice that the Fink paths aren't there (wonder how this works for you?). I was
just getting at the fact that probably should centralise this list of
"non-standard paths". Originally we had a cmake variable deciding between Fink
and MacPorts, and then used that to generate the non-standard path of choice.
Either something like that, or maybe as simple as just add global cmake var's
that hold a list of non-standard include and lib dirs to use in FIND_XXX calls.
That way, only one place has to change if we need to add/modify the list.
Thoughts?
S
[Bug 533] Mac OS X port
>>> Side issue - we need to use a consistent method of adding package-related paths to statements like FIND_PATH and FIND_LIBRARY.
>>
>> Do you refer to the NO_DEFAULT_PATH statements here?
>
> No. I had to hardwire in the default MacPorts path to the FIND_XXX calls.
> Notice that the Fink paths aren't there (wonder how this works for you?). I was
> just getting at the fact that probably should centralise this list of
> "non-standard paths". Originally we had a cmake variable deciding between Fink
> and MacPorts, and then used that to generate the non-standard path of choice.
> Either something like that, or maybe as simple as just add global cmake var's
> that hold a list of non-standard include and lib dirs to use in FIND_XXX calls.
> That way, only one place has to change if we need to add/modify the list.
>
> Thoughts?
Yes, see
We shouldn't try to look everywhere. That results into disaster (especially when cross-compiling). It's up to the user to specify those non-standard locations via CMAKE_INCLUDE_PATH etc., and the FIND_XXX calls take into account these. So maybe your patch wasn't even necessary?
Klaas