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

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

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

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

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.

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

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.

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

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

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.

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

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.

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?

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

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

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

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

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

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

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

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

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

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

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.