• The directory /opt/www/bruyninckxh2/web/tmp/drutex-134a6066ab83ceefacf58e300940d432-1 has been created.
  • The directory /opt/www/bruyninckxh2/web/tmp/drutex-134a6066ab83ceefacf58e300940d432-2 has been created.
  • The directory /opt/www/bruyninckxh2/web/tmp/drutex-134a6066ab83ceefacf58e300940d432-3 has been created.
  • The directory /opt/www/bruyninckxh2/web/tmp/drutex-134a6066ab83ceefacf58e300940d432-4 has been created.
  • The directory /opt/www/bruyninckxh2/web/tmp/drutex-134a6066ab83ceefacf58e300940d432-5 has been created.
  • The directory /opt/www/bruyninckxh2/web/tmp/drutex-134a6066ab83ceefacf58e300940d432-6 has been created.
  • The directory /opt/www/bruyninckxh2/web/tmp/drutex-134a6066ab83ceefacf58e300940d432-7 has been created.

[Bug 533] New: Mac OS X port

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 :-)

[Bug 533] Mac OS X port

On Jul 17, 2008, at 08:40 , Klaas Gadeyne wrote:

>>>> 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?

I tried the CMAKE_INCLUDE_PATH, and it didn't work for me. :-(
S

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #24 from S Roderick <kiwi [dot] net [..] ...> 2008-07-17 13:34:58 ---
(In reply to comment #21)
> (In reply to comment #19)
> [...]
> > Also, are unable to run helloworld or any of the tests as areunable to find the
> > RTT dynamic libraries. Might need some "-rpath" magic ... are looking into it.
>
> Where did you install those? Did you forget to set some variables perhaps?
> (see comment #7)

Setting DYLD_LIBRARY_PATH fixed it. helloworld now runs.

> > Also, the OCL dynamic libraries needed for the these executables all have
> > absolute paths into the build dir. Might need some relinking magic here too to
> > prevent future problems ...
>
> -ERRDONTUNDERSTAND here :-( Can you elaborate on this one?

In the output from otool below, you can see that the dynamic libraries are set
to be taken from the build dir, and not pulled in from the dir they were
actually installed in. I notice that the Linux version does the same also. When
rtt is installed it does a relinking during the install. I wonder if that takes
care of this kind of issue? (Peter?)

{{{
build $ otool -L helloworld/helloworld
helloworld/helloworld:

/opt/wclocal/nrl/orocos/macosx/ocl/build/taskbrowser/liborocos-taskbrowser-macosx.1.4.dylib
(compatibility version 0.0.0, current version 0.0.0)

/opt/wclocal/nrl/orocos/macosx/ocl/build/ocl/liborocos-ocl-common-macosx.1.4.dylib
(compatibility version 0.0.0, current version 0.0.0)
liborocos-rtt-macosx.1.4.dylib (compatibility version 0.0.0, current
version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.1.1)
/opt/local/lib/libncurses.5.dylib (compatibility version 5.0.0, current
version 5.0.0)
/opt/local/lib/libreadline.5.2.dylib (compatibility version 5.0.0,
current version 5.2.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
1.0.0)
}}}

[Bug 533] Mac OS X port

On Thursday 17 July 2008 13:34:58 S Roderick wrote:
>
> In the output from otool below, you can see that the dynamic libraries are
> set to be taken from the build dir, and not pulled in from the dir they
> were actually installed in. I notice that the Linux version does the same
> also. When rtt is installed it does a relinking during the install. I
> wonder if that takes care of this kind of issue? (Peter?)

AFAIKT, cmake on Linux first links the libraries with RPATH settings pointing
to your build dir, such that you can test the programs without installing
them or playing with LD_LIBRARY_PATH. When they are installed, the library is
relinked without RPATH and the standard lib paths apply. Cmake does this
automatically. I would assume the same applies for Mac OS X.

Peter

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #23 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-07-16 21:08:31 ---
(In reply to comment #20)
> Created an attachment (id=332)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=332) [details]
> Fixes problems with cmake 2.4.6 and macports under 10.5.4
>
> Spoke to soon ... on my system at home, ocl/taskbrowser fails to build. It is
> due to the cmake logic that finds readline conflicting with similar logic built
> into the gcc toolchain. Basically, cmake finds the system default readline in
> /usr/lib whereas gcc finds the Macports version in /opt/local/lib, which are
> incompatible. Not sure why my work machine doesn't hit this - I have a newer
> version of cmake at home, and may have different version of Macports' readline
> (will check tomorrow).
>
> Also, fixed new policy directive in cmake 2.4.6
>
> Also, fixed need for boost_program_options library and not just the associated
> header files.

Thx, applied, tested and committed. I also merged with trunk and "all" seems
to be fine. Not yet tested if this won't break stuff on gnulinux though...

> 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?

Klaas

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #22 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-07-16 21:05:28 ---
(In reply to comment #19)
> Reporting does not build, with the
> following (haven't had a chance to look at it yet)
>
> {{{
> /opt/code/nrl/orocos/macosx2/ocl/reporting/socket.cpp: In member function
> ‘void::sockbuf::put_buffer()’:
> /opt/code/nrl/orocos/macosx2/ocl/reporting/socket.cpp:103: error:
> ‘MSG_NOSIGNAL’ was not declared in this scope
> /opt/code/nrl/orocos/macosx2/ocl/reporting/socket.cpp: In member function
> ‘void OCL::TCP::Socket::close()’:
> /opt/code/nrl/orocos/macosx2/ocl/reporting/socket.cpp:267: error:
> ‘MSG_NOSIGNAL’ was not declared in this scope
> }}}

I haven't looked at the reporting subdirectory for now, maybe some of its code
is very linux specific...

Klaas

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #21 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-07-15 16:40:24 ---
(In reply to comment #19)
[...]
> Also, are unable to run helloworld or any of the tests as areunable to find the
> RTT dynamic libraries. Might need some "-rpath" magic ... are looking into it.

Where did you install those? Did you forget to set some variables perhaps?
(see comment #7)

> Also, the OCL dynamic libraries needed for the these executables all have
> absolute paths into the build dir. Might need some relinking magic here too to
> prevent future problems ...

-ERRDONTUNDERSTAND here :-( Can you elaborate on this one?

Thx,

Klaas

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #20 from S Roderick <kiwi [dot] net [..] ...> 2008-07-09 23:51:18 ---
Created an attachment (id=332)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=332)
Fixes problems with cmake 2.4.6 and macports under 10.5.4

Spoke to soon ... on my system at home, ocl/taskbrowser fails to build. It is
due to the cmake logic that finds readline conflicting with similar logic built
into the gcc toolchain. Basically, cmake finds the system default readline in
/usr/lib whereas gcc finds the Macports version in /opt/local/lib, which are
incompatible. Not sure why my work machine doesn't hit this - I have a newer
version of cmake at home, and may have different version of Macports' readline
(will check tomorrow).

Also, fixed new policy directive in cmake 2.4.6

Also, fixed need for boost_program_options library and not just the associated
header files.

Side issue - we need to use a consistent method of adding package-related paths
to statements like FIND_PATH and FIND_LIBRARY.

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #19 from S Roderick <kiwi [dot] net [..] ...> 2008-07-09 19:00:19 ---
(In reply to comment #18)
> Hi Stephen et al,
>
> can you try the ocl branch and see if you get stuff running using a similar
> approach as with RTT?
> Note that I have not tried to compile hardware stuff, but TB, deployer, timer
> etc seem to work fine here.

Confirm that ocl-common, timer, deployment, taskbrowser, deployer, helloworld
and tests all build on 10.5.4 with Macports. Reporting does not build, with the
following (haven't had a chance to look at it yet)

{{{
/opt/code/nrl/orocos/macosx2/ocl/reporting/socket.cpp: In member function
‘void::sockbuf::put_buffer()’:
/opt/code/nrl/orocos/macosx2/ocl/reporting/socket.cpp:103: error:
‘MSG_NOSIGNAL’ was not declared in this scope
/opt/code/nrl/orocos/macosx2/ocl/reporting/socket.cpp: In member function
‘void OCL::TCP::Socket::close()’:
/opt/code/nrl/orocos/macosx2/ocl/reporting/socket.cpp:267: error:
‘MSG_NOSIGNAL’ was not declared in this scope
}}}

Also, are unable to run helloworld or any of the tests as areunable to find the
RTT dynamic libraries. Might need some "-rpath" magic ... are looking into it.
Also, the OCL dynamic libraries needed for the these executables all have
absolute paths into the build dir. Might need some relinking magic here too to
prevent future problems ...

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #18 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-06-17 18:50:10 ---
Hi Stephen et al,

can you try the ocl branch and see if you get stuff running using a similar
approach as with RTT?
Note that I have not tried to compile hardware stuff, but TB, deployer, timer
etc seem to work fine here.

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #17 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-06-03 15:28:41 ---
(In reply to comment #16)
> (In reply to comment #15)
> > Can somebody verify this works on an imac with macports and not os x 10.4 :-)
>
> 10.5.3, Macintel, Macports 1.600

You have parallels, I have to do it with virtuedesktops, lucky you :-)

> > svn co http://svn.mech.kuleuven.be/repos/orocos/branches/rtt/macosx/
> > export CMAKE_INCLUDE_PATH=/opt/local/include
> > export CMAKE_LIBRARY_PATH=/opt/local/lib
>
> cd macosx
>
> > mkdir build-macosx && cd build-macosx
> > ccmake ..
>
> Had to set BOOST_INSTALL to /opt/local/include. It did not pick them up from
> the export's above.

exactly. Noticed that too yesterday evening. I consider this to be a bug in
rtt-trunk. Will have a look at it ITA.

> > -> Set build type to mac os x
>
> set build type to "macosx"
>
> > make && make check
>
> Confirm make and tests succeed without sudo. WAHOO!! :-)
>
> What next?

- Some of the code if still #ifdef'd (grep for OROPKG_OS_MACOSX)
- Documentation should be added to the installation manual (basically the
export stuff above)
- I'll start working on ocl, so you can really do something useful with this
:-)

regards,

Klaas

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #16 from S Roderick <kiwi [dot] net [..] ...> 2008-06-03 14:20:31 ---
(In reply to comment #15)
> Can somebody verify this works on an imac with macports and not os x 10.4 :-)

10.5.3, Macintel, Macports 1.600

> svn co http://svn.mech.kuleuven.be/repos/orocos/branches/rtt/macosx/
> export CMAKE_INCLUDE_PATH=/opt/local/include
> export CMAKE_LIBRARY_PATH=/opt/local/lib

cd macosx

> mkdir build-macosx && cd build-macosx
> ccmake ..

Had to set BOOST_INSTALL to /opt/local/include. It did not pick them up from
the export's above.

> -> Set build type to mac os x

set build type to "macosx"

> make && make check

Confirm make and tests succeed without sudo. WAHOO!! :-)

What next?
S

[Bug 533] Mac OS X port

On Tuesday 03 June 2008 14:20:31 S Roderick wrote:
>
> Confirm make and tests succeed without sudo. WAHOO!! :-)
>
> What next?

I can't think of any reason why this shouldn't be merged on trunk. Trunk needs
this small patch btw:
* default enable tests = ON
* guard the tests with ENABLE_TESTS

Peter

$ svn di config tests/CMakeLists.txt
Index: config/global_setup.cmake
===================================================================
--- config/global_setup.cmake (revision 29354)
+++ config/global_setup.cmake (working copy)
@@ -59,7 +59,7 @@
#
# An option for tests, to make it easy to turn off all tests
#
-OPTION( ENABLE_TESTS \"Turn me off to disable compilation of all tests\" OFF )
+OPTION( ENABLE_TESTS \"Turn me off to disable compilation of all tests\" ON )
IF( ENABLE_TESTS )
IF (NOT CMAKE_CROSS_COMPILE )
FIND_LIBRARY(CPPUNIT NAMES cppunit PATHS /usr/local/lib /usr/lib )
Index: tests/CMakeLists.txt
===================================================================
--- tests/CMakeLists.txt (revision 29354)
+++ tests/CMakeLists.txt (working copy)
@@ -1,4 +1,4 @@
-
+IF (ENABLE_TESTS)
# See ADD_TEST() below.
ENABLE_TESTING()
SET(COMPILE_FLAGS \"${CMAKE_CXX_FLAGS_ADD}
${RTT_CFLAGS} -DOROCOS_TARGET=${OROCOS_TARGET}")
@@ -83,8 +83,9 @@
SET(ORO_EXTRA_TESTS "corba-test")
ENDIF(ENABLE_CORBA)

-ADD_CUSTOM_TARGET(check ctest -V
- DEPENDS core-test task-test event-test taskcontext-test parser-test
program-test state-test dev-test ${ORO_EXTRA_TESTS}
- WORKING_DIRECTORY ${PROJ_BINARY_DIR}/tests)
+ ADD_CUSTOM_TARGET(check ctest -V
+ DEPENDS core-test task-test event-test taskcontext-test parser-test
program-test state-test dev-test ${ORO_EXTRA_TESTS}
+ WORKING_DIRECTORY ${PROJ_BINARY_DIR}/tests)

-ADD_DEPENDENCIES(check prep-cpf)
+ ADD_DEPENDENCIES(check prep-cpf)
+ENDIF(ENABLE_TESTS)
\ No newline at end of file

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #15 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-05-30 23:52:53 ---
Can somebody verify this works on an imac with macports and not os x 10.4 :-)

svn co http://svn.mech.kuleuven.be/repos/orocos/branches/rtt/macosx/
export CMAKE_INCLUDE_PATH=/opt/local/include
export CMAKE_LIBRARY_PATH=/opt/local/lib
mkdir build-macosx && cd build-macosx
ccmake ..
-> Set build type to mac os x
make && make check

You should have a clean build and all tests should succeed, without using sudo.

[Bug 533] Mac OS X port

On Friday 30 May 2008 23:52:53 Klaas Gadeyne wrote:
> For more infomation about this bug, visit
>
>
>
>
> --- Comment #15 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-05-30
> 23:52:53 --- Can somebody verify this works on an imac with macports and
> not os x 10.4 :-)

Just a thought on the rtos_sem_value() issue. If we ignore the various sem
implementations for a moment... What we want to do is this:

* If the semaphore is not raised, raise it.
* If it could be raised, return true, otherwise, false.

The first solution for this is to use a binary semaphore, such that it can be
raised only once. The first time this succeeds, the signal functions returns
0 and we return true. If you try to raise it again, the signal function
returns -1, and we return false.

That's of course not possible with POSIX semaphores. We could try to implement
a binary semaphore using the counting semaphores (BinarySemphore.hpp) but I
have no idea if this is feasible. The current rtos_sem_value() use (at that
place) is subject to race conditions by the way...

For me rtos_sem_value() is not a requirement, it's the idea behind it.

Peter

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #14 from S Roderick <kiwi [dot] net [..] ...> 2008-05-28 02:56:15 ---
(In reply to comment #6)
I get different results. Two tests failing if run as sudo, one test fails if
run as normal user (same as we've seen before).

The code was at r29293, though updating to r29316 (as with your apparent
working copy) did not change anything (was only Corba updates).

I will continue to look at it, and take a look at the nasty hacks you had for
OCL ... ;-0

Results from "sudo make check"
{{{
2/ 8 Testing task-test
Test command: /opt/code/nrl/orocos/macport/rtt/build/tests/task-test
............F..

/opt/code/nrl/orocos/macport/rtt/tests/taskthread_test.cpp:376: Assertion
Test name: ActivitiesThreadTest::testScheduler
equality assertion failed
- Expected: 0
- Actual : 31

Failures !!!
Run: 14 Failure total: 1 Failures: 1 Errors: 0
-- Process completed
***Failed
3/ 8 Testing event-test
Test command: /opt/code/nrl/orocos/macport/rtt/build/tests/event-test
....................
OK (20)

-- Process completed
Passed
4/ 8 Testing taskcontext-test
Test command: /opt/code/nrl/orocos/macport/rtt/build/tests/taskcontext-test
0.005 [CRITICAL][PeriodicThread::start] The SimulationThread thread seems to be
blocked ( ret was 49 .)
1.988 [CRITICAL][PeriodicThread::start] The SimulationThread thread seems to be
blocked ( ret was 49 .)
..........................

OK (26)
-- Process completed
Passed
}}}

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #13 from Peter Soetens

<peter [dot] soetens [..] ...> 2008-05-27 09:27:18 ---
(In reply to comment #12)
>
> I want to try the approach (and maybe some others) from comment #8 for both RTT
> and OCL, so that's why I thought of creating
> Furthermore, that allows me to comment out some stuff (like the rtos_sem_value
> issue) in other directories than os/macosx too temporarily, until I've got that
> sorted out.
>
> Is
> orocos/branches/rtt/macosx and orocos/branches/ocl/macosx ok for you?
>

OK.

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #12 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-05-27 08:40:41 ---
(In reply to comment #11)
> (In reply to comment #10)
> > Created an attachment (id=303)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=303) [details] [details]
> > OCL darwin/fink patch. Really ugly. Don't use :-)
> >
> > This is my current patch. Additionnally with this patch I have to move
> > libreadline in /usr so it used the one in /sw (unresolved symbols). This is
> > really *not* the good solution.
> >
> > Now, I suggest I create a (public) RTT and OCL darwin branch, and start merging
> > the patches in there. Any thoughts/objections?
> >
> > For RTT, we'll need a separate directory anyway (not as it is now---a patch
> > onto the linux one).
> >
>
> Normally, support for another OS can be done on trunk, in a new subdir of os/
> . Technically speaking, you could 'branch' the os/gnulinux dir into the
> os/macosx dir for the time being. This causes less work for you.
>
> For OCL it's more complicated as you're playing with the cmake system, but a
> branch seems the only clean way if you want to share your patches more easily.
> orocos/branches/ocl/macosx ?

I want to try the approach (and maybe some others) from comment #8 for both RTT
and OCL, so that's why I thought of creating
Furthermore, that allows me to comment out some stuff (like the rtos_sem_value
issue) in other directories than os/macosx too temporarily, until I've got that
sorted out.

Is
orocos/branches/rtt/macosx and orocos/branches/ocl/macosx ok for you?

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #11 from Peter Soetens

<peter [dot] soetens [..] ...> 2008-05-26 22:19:52 ---
(In reply to comment #10)
> Created an attachment (id=303)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=303) [details]
> OCL darwin/fink patch. Really ugly. Don't use :-)
>
> This is my current patch. Additionnally with this patch I have to move
> libreadline in /usr so it used the one in /sw (unresolved symbols). This is
> really *not* the good solution.
>
> Now, I suggest I create a (public) RTT and OCL darwin branch, and start merging
> the patches in there. Any thoughts/objections?
>
> For RTT, we'll need a separate directory anyway (not as it is now---a patch
> onto the linux one).
>

Normally, support for another OS can be done on trunk, in a new subdir of os/
. Technically speaking, you could 'branch' the os/gnulinux dir into the
os/macosx dir for the time being. This causes less work for you.

For OCL it's more complicated as you're playing with the cmake system, but a
branch seems the only clean way if you want to share your patches more easily.
orocos/branches/ocl/macosx ?

Peter

[Bug 533] Mac OS X port

For more infomation about this bug, visit

Klaas Gadeyne <klaas [dot] gadeyne [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|orocos- |klaas [dot] gadeyne [..] ...
|dev [..] ... |

--- Comment #10 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-05-26 21:16:55 ---
Created an attachment (id=303)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=303)
OCL darwin/fink patch. Really ugly. Don't use :-)

This is my current patch. Additionnally with this patch I have to move
libreadline in /usr so it used the one in /sw (unresolved symbols). This is
really *not* the good solution.

Now, I suggest I create a (public) RTT and OCL darwin branch, and start merging
the patches in there. Any thoughts/objections?

For RTT, we'll need a separate directory anyway (not as it is now---a patch
onto the linux one).

[Bug 533] Mac OS X port

For more infomation about this bug, visit

S Roderick <kiwi [dot] net [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
CC| |kiwi [dot] net [..] ...

--- Comment #9 from S Roderick <kiwi [dot] net [..] ...> 2008-05-26 15:59:55 ---
(In reply to comment #8)
> Instead of hacking the cmake logic, this seems to be a nicer alternative
>
>

What problems were you having that forced a need for this? Can you post the
cmake hacks you did also, so that someone else can try this?

Thanks
S

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #8 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-05-26 10:17:38 ---
Instead of hacking the cmake logic, this seems to be a nicer alternative


Environment Variables

If you have headers and libraries installed in non-standard locations that
cmake cannot find (e.g., fink on Mac OSX installs to /sw), then set the
following as environment variables. Despite the similar naming convention,
these will not work as arguments on the cmake command line:

* CMAKE_INCLUDE_PATH, eg. export CMAKE_INCLUDE_PATH=/sw/include
* CMAKE_LIBRARY_PATH, eg. export CMAKE_LIBRARY_PATH=/sw/lib

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #7 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-05-25 11:48:09 ---
(In reply to comment #6)

And after many dirty hacks to the OCL build system (God, I hate cmake)

[klaas@Leentje ~/SVN/ocl-trunk/build-macosx/helloworld]$
$ export DYLD_LIBRARY_PATH=/sw/lib/:/Users/klaas/install/orocos/lib/
[klaas@Leentje ~/SVN/ocl-trunk/build-macosx/helloworld]$
$ otool -L ./helloworld
./helloworld:
liborocos-rtt-gnulinux.1.4.dylib (compatibility version 0.0.0, current
version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 88.3.10)

/Users/klaas/SVN/ocl-trunk/build-macosx/taskbrowser/liborocos-taskbrowser-gnulinux.1.4.dylib
(compatibility version 0.0.0, current version 0.0.0)
/sw/lib/ncurses/libncurses.5.dylib (compatibility version 5.0.0,
current version 5.0.0)
/sw/lib/libreadline.5.dylib (compatibility version 5.0.0, current
version 5.0.0)

/Users/klaas/SVN/ocl-trunk/build-macosx/ocl/liborocos-ocl-common-gnulinux.1.4.dylib
(compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
1.0.0)
[klaas@Leentje ~/SVN/ocl-trunk/build-macosx/helloworld]$
$ ./helloworld
Switched to : Hello

This console reader allows you to browse and manipulate TaskContexts.
You can type in a command, event, method, expression or change variables.
(type 'help' for instructions)
TAB completion and HISTORY is available ('bash' like)

In Task Hello[R]. (Status of last Command : none )
(type 'ls' for context info) :ls

Listing TaskContext Hello :

Configuration Properties:
string the_property = Hello World (the_property Description)

Execution Interface:
Attributes :
string the_attribute = Hello World
string the_constant = Hello World

Methods : activate cleanup configure error getErrorCount getPeriod
getWarningCount inFatalError inRunTimeError inRunTimeWarning isActive
isConfigured isRunning resetError start stop the_method trigger update warning
Commands : the_command
Events : the_event

Data Flow Ports:
RW(U) string the_data_port = World
RW(U) string the_buffer_port =

Task Objects:
this ( The interface of this TaskContext. )
scripting ( Access to the Scripting interface. Use this object in order
to load or query programs or state machines. )
engine ( Access to the Execution Engine. Use this object in order to
address programs or state machines which may or may not be loaded. )
marshalling ( Read and write Properties to a file. )
the_data_port ( (No description set for this Port) )
the_buffer_port ( (No description set for this Port) )

Peers : (none)

In Task Hello[R]. (Status of last Command : none )
(type 'ls' for context info) :the_property="Hello Mac OS X world"
Got :the_property="Hello Mac OS X world"
= true

Someone to test, cleanup and add documentation? :-)

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #6 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-05-24 12:56:02 ---
(In reply to comment #5)
> > Some notes:
> > - sem_value() is not supported in the native API, however, it seems it is used
> > only once in RTT, in SingleThread::Start(). I didn't have a close look (Hey,
> > it's sunday!) and just commented this out. Shame on me.
> > - Not too much notes (did I mention it's sunday?)
> >
> > However, we're getting closer. From 6 tests failed out of 8, I'm now getting

Even beter, most of the failures seems to be due to the fact that the tests are
not run as su, and hence scheduler levels/priorities are changes (I fail to
enable logging for the time being though). Running make check with sudo ->
Only one failure left

2/ 8 Testing task-test
Test command: /Users/klaas/SVN/rtt-trunk/buildmacosx/tests/task-test
............F..

taskthread_test.cpp:376:Assertion
Test name: ActivitiesThreadTest::testScheduler
equality assertion failed
- Expected: 0
- Actual : 31

Failures !!!
Run: 14 Failure total: 1 Failures: 1 Errors: 0
-- Process completed
***Failed

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #5 from S Roderick <kiwi [dot] net [..] ...> 2008-05-19 14:47:10 ---
> Some notes:
> - sem_value() is not supported in the native API, however, it seems it is used
> only once in RTT, in SingleThread::Start(). I didn't have a close look (Hey,
> it's sunday!) and just commented this out. Shame on me.
> - Not too much notes (did I mention it's sunday?)
>
> However, we're getting closer. From 6 tests failed out of 8, I'm now getting

Confirm that I'm seeing the same behaviour. I did not comment out sem_value(),
but just made it return -1 (ie failed).

I'll try and take a look when I get a chance.
S

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #4 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-05-18 12:53:22 ---
Created an attachment (id=294)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=294)
Mac OS X port, using native semaphore API

See
http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/synchronization/chapter_15_section_2.html

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #3 from Klaas Gadeyne <klaas [dot] gadeyne [..] ...> 2008-05-18 12:49:17 ---
(In reply to comment #1)
> Created an attachment (id=266)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=266) [details]
> modified mac patch (leopard plus macports)
>
> Updated patch attached.
>
> Made it (mostly) agnostic as to Fink or Macports - this needs more work (see
> top of config/check_depend.cmake).

Indeed, this broke my fink stuff (slightly)
>
> Builds rtt with Macports on Leopard 10.5.2 on Intel iMac, bar one of the test
> cases, generictask_test_3. I'm not sure if this is a compiler bug, or just the
> result of a more strict compiler (Leopard is "i686-apple-darwin9-gcc-4.0.1
> (GCC) 4.0.1 (Apple Inc. build 5465)". I have included a notational workaround
> within this file, but it is ugly to say the least. This type of problem seen
> before, see
>
> http://gcc.gnu.org/ml/gcc-bugs/2005-03/msg01211.html
> http://www.megasolutions.net/cplus/Copy-construction-with-inaccessible-base-class-copy-c-tor-20108.aspx
>
> Still needs a complete rewrite of semaphore implementation.

Posix compliant sem_timedwait seems a real pain in the *ss on mac os x. I
tried another implementation but had same bad test results as you did.
Then I found out that the mac os x "native" api also has semaphores. Hence the
new patch.

Some notes:
- sem_value() is not supported in the native API, however, it seems it is used
only once in RTT, in SingleThread::Start(). I didn't have a close look (Hey,
it's sunday!) and just commented this out. Shame on me.
- Not too much notes (did I mention it's sunday?)

However, we're getting closer. From 6 tests failed out of 8, I'm now getting

Start processing tests
Test project /Users/klaas/SVN/rtt-trunk/buildmacosx/tests
Constructing a list of tests
Done constructing a list of tests
Changing directory into /Users/klaas/SVN/rtt-trunk/buildmacosx/tests
1/ 8 Testing core-test
Test command: /Users/klaas/SVN/rtt-trunk/buildmacosx/tests/core-test
.......................

OK (23)
-- Process completed
Passed
2/ 8 Testing task-test
Test command: /Users/klaas/SVN/rtt-trunk/buildmacosx/tests/task-test
........F.F.F..F.F.

taskthread_test.cpp:423:Assertion
Test name: ActivitiesThreadTest::testThreadConfig
assertion failed
- Expression: tt == TimerThread::Instance(bprio,0.0123)

taskthread_test.cpp:181:Assertion
Test name: ActivitiesThreadTest::testPeriodic
equality assertion failed
- Expected: 0
- Actual : 31

taskthread_test.cpp:237:Assertion
Test name: ActivitiesThreadTest::testNonPeriodic
equality assertion failed
- Expected: 0
- Actual : 31

taskthread_test.cpp:376:Assertion
Test name: ActivitiesThreadTest::testScheduler
equality assertion failed
- Expected: 0
- Actual : 31

taskthread_test.cpp:481:Assertion
Test name: ActivitiesThreadTest::testExceptionRecovery
assertion failed
- Expression: !t_task_np->isRunning()

Failures !!!
Run: 14 Failure total: 5 Failures: 5 Errors: 0
-- Process completed
***Failed
3/ 8 Testing event-test
Test command: /Users/klaas/SVN/rtt-trunk/buildmacosx/tests/event-test
....................

OK (20)
-- Process completed
Passed
4/ 8 Testing taskcontext-test
Test command: /Users/klaas/SVN/rtt-trunk/buildmacosx/tests/taskcontext-test
..........................

OK (26)
-- Process completed
Passed
5/ 8 Testing parser-test
Test command: /Users/klaas/SVN/rtt-trunk/buildmacosx/tests/parser-test
................

OK (16)
-- Process completed
Passed
6/ 8 Testing program-test
Test command: /Users/klaas/SVN/rtt-trunk/buildmacosx/tests/program-test
...................

OK (19)
-- Process completed
Passed
7/ 8 Testing state-test
Test command: /Users/klaas/SVN/rtt-trunk/buildmacosx/tests/state-test
.......

OK (7)
-- Process completed
Passed
8/ 8 Testing dev-test
Test command: /Users/klaas/SVN/rtt-trunk/buildmacosx/tests/dev-test
..

OK (2)
-- Process completed
Passed

88% tests passed, 1 tests failed out of 8

The following tests FAILED:
2 - task-test (Failed)

I just put this here for future reference. I don't feel like debugging them
right now. Have fun :-)

[Bug 533] Mac OS X port

For more infomation about this bug, visit

Peter Soetens

<peter [dot] soetens [..] ...> changed:

What |Removed |Added
--------------------------------------------------------------------------
CC| |peter [dot] soetens [..] ...

--- Comment #2 from Peter Soetens

<peter [dot] soetens [..] ...> 2008-04-23 21:53:19 ---
(In reply to comment #1)
> Created an attachment (id=266)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=266) [details]
> modified mac patch (leopard plus macports)
>
> Updated patch attached.
>
> Made it (mostly) agnostic as to Fink or Macports - this needs more work (see
> top of config/check_depend.cmake).
>
> Builds rtt with Macports on Leopard 10.5.2 on Intel iMac, bar one of the test
> cases, generictask_test_3. I'm not sure if this is a compiler bug, or just the
> result of a more strict compiler (Leopard is "i686-apple-darwin9-gcc-4.0.1
> (GCC) 4.0.1 (Apple Inc. build 5465)". I have included a notational workaround
> within this file, but it is ugly to say the least. This type of problem seen
> before, see
>
> http://gcc.gnu.org/ml/gcc-bugs/2005-03/msg01211.html
> http://www.megasolutions.net/cplus/Copy-construction-with-inaccessible-base-class-copy-c-tor-20108.aspx
>
> Still needs a complete rewrite of semaphore implementation.
>

Nice work. Did it pass all the unit tests ?

Peter

[Bug 533] Mac OS X port

For more infomation about this bug, visit

--- Comment #1 from S Roderick <kiwi [dot] net [..] ...> 2008-04-22 17:55:19 ---
Created an attachment (id=266)
--> (https://www.fmtc.be/bugzilla/orocos/attachment.cgi?id=266)
modified mac patch (leopard plus macports)

Updated patch attached.

Made it (mostly) agnostic as to Fink or Macports - this needs more work (see
top of config/check_depend.cmake).

Builds rtt with Macports on Leopard 10.5.2 on Intel iMac, bar one of the test
cases, generictask_test_3. I'm not sure if this is a compiler bug, or just the
result of a more strict compiler (Leopard is "i686-apple-darwin9-gcc-4.0.1
(GCC) 4.0.1 (Apple Inc. build 5465)". I have included a notational workaround
within this file, but it is ugly to say the least. This type of problem seen
before, see

http://gcc.gnu.org/ml/gcc-bugs/2005-03/msg01211.html
http://www.megasolutions.net/cplus/Copy-construction-with-inaccessible-base-class-copy-c-tor-20108.aspx

Still needs a complete rewrite of semaphore implementation.