osx 'make test' failing, but hello-* examples kinda work?

Howdy all,

I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.

So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
- I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
- I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
- I already had XCode 3.2.5 installed.
- I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
- I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
- I set some environment variables for finding dynamic libraries, lua bindings, etc.
- I downloaded and started working through the rtt-exercises-2.3.2 package.

That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.

Here are links to various interesting things that may help debug. Let me know if I can provide any other information:

my system info - http://pastebin.com/Wf8XdBcQ
RTT make test failure - http://pastebin.com/uQeJkywc
RTT CMakeCache - http://pastebin.com/M7ZppEhu
rttlua error - http://pastebin.com/dcPmBpCA

Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.

--
Dustin Gooding
NASA/JSC Robotics

osx 'make test' failing, but hello-* examples kinda work?

On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:

> Howdy all,
>
> I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.
>
> So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
> - I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
> - I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
> - I already had XCode 3.2.5 installed.
> - I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
> - I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
> - I set some environment variables for finding dynamic libraries, lua bindings, etc.
> - I downloaded and started working through the rtt-exercises-2.3.2 package.
>
> That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.
>
> Here are links to various interesting things that may help debug. Let me know if I can provide any other information:
>
> my system info - http://pastebin.com/Wf8XdBcQ
> RTT make test failure - http://pastebin.com/uQeJkywc
> RTT CMakeCache - http://pastebin.com/M7ZppEhu
> rttlua error - http://pastebin.com/dcPmBpCA
>
> Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.

Hey Chris

Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.

Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).

When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.

So something like (from memory)

cd /path/to/build/rtt
cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
make -jN
source setup-orocos /path/to/install
make check

And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)

Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)

HTH
S

osx 'make test' failing, but hello-* examples kinda work?

On Jun 10, 2011, at 3:16 PM, S Roderick wrote:

On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:

Howdy all,

I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.

So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
- I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
- I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
- I already had XCode 3.2.5 installed.
- I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
- I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
- I set some environment variables for finding dynamic libraries, lua bindings, etc.
- I downloaded and started working through the rtt-exercises-2.3.2 package.

That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.

Here are links to various interesting things that may help debug. Let me know if I can provide any other information:

my system info - http://pastebin.com/Wf8XdBcQ
RTT make test failure - http://pastebin.com/uQeJkywc
RTT CMakeCache - http://pastebin.com/M7ZppEhu
rttlua error - http://pastebin.com/dcPmBpCA

Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.

Hey Chris

Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.

Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).

When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.

So something like (from memory)

cd /path/to/build/rtt
cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
make -jN
source setup-orocos /path/to/install
make check

And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)

Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)

HTH
S

<setup-orocos>

Thanks for the feedback S.

I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.

I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?

-dustin

osx 'make test' failing, but hello-* examples kinda work?

On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:

> On Jun 10, 2011, at 3:16 PM, S Roderick wrote:
>
>> On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:
>>
>>> Howdy all,
>>>
>>> I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.
>>>
>>> So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
>>> - I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
>>> - I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
>>> - I already had XCode 3.2.5 installed.
>>> - I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
>>> - I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
>>> - I set some environment variables for finding dynamic libraries, lua bindings, etc.
>>> - I downloaded and started working through the rtt-exercises-2.3.2 package.
>>>
>>> That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.
>>>
>>> Here are links to various interesting things that may help debug. Let me know if I can provide any other information:
>>>
>>> my system info - http://pastebin.com/Wf8XdBcQ
>>> RTT make test failure - http://pastebin.com/uQeJkywc
>>> RTT CMakeCache - http://pastebin.com/M7ZppEhu
>>> rttlua error - http://pastebin.com/dcPmBpCA
>>>
>>> Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.
>>
>> Hey Chris
>>
>> Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.
>>
>> Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).
>>
>> When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.
>>
>> So something like (from memory)
>>
>> cd /path/to/build/rtt
>> cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
>> make -jN
>> source setup-orocos /path/to/install
>> make check
>>
>> And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)
>>
>> Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)
>>
>> HTH
>> S
>>
>> <setup-orocos>
>
> Thanks for the feedback S.
>
> I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.
>
> I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?
>
> -dustin

gdb
backtrace = bt
?

osx 'make test' failing, but hello-* examples kinda work?

On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:

On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 3:16 PM, S Roderick wrote:

On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:

Howdy all,

I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.

So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
- I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
- I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
- I already had XCode 3.2.5 installed.
- I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
- I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
- I set some environment variables for finding dynamic libraries, lua bindings, etc.
- I downloaded and started working through the rtt-exercises-2.3.2 package.

That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.

Here are links to various interesting things that may help debug. Let me know if I can provide any other information:

my system info - http://pastebin.com/Wf8XdBcQ
RTT make test failure - http://pastebin.com/uQeJkywc
RTT CMakeCache - http://pastebin.com/M7ZppEhu
rttlua error - http://pastebin.com/dcPmBpCA

Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.

Hey Chris

Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.

Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).

When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.

So something like (from memory)

cd /path/to/build/rtt
cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
make -jN
source setup-orocos /path/to/install
make check

And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)

Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)

HTH
S

<setup-orocos>

Thanks for the feedback S.

I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.

I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?

-dustin

gdb
backtrace = bt
?

I recompiled everything as Debug (was Release), but GDB and Backtrace aren't immediately helpful, because the SegFault errors are actually just handled exceptions (I assume). Nothing is actually segfaulting, so BT doesn't show anything. http://pastebin.com/1kXQWMtm

Building and installing RTT on my Linux box using essentially the same method creates RTT and it passes all tests. This is just happening on my Mac, which is frustrating.

Any further help is appreciated.

-dustin

osx 'make test' failing, but hello-* examples kinda work?

On Jun 13, 2011, at 11:21 , Gooding, Dustin R. (JSC-ER411) wrote:

> On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:
>
>> On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:
>>
>>> On Jun 10, 2011, at 3:16 PM, S Roderick wrote:
>>>
>>>> On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:
>>>>
>>>>> Howdy all,
>>>>>
>>>>> I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.
>>>>>
>>>>> So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
>>>>> - I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
>>>>> - I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
>>>>> - I already had XCode 3.2.5 installed.
>>>>> - I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
>>>>> - I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
>>>>> - I set some environment variables for finding dynamic libraries, lua bindings, etc.
>>>>> - I downloaded and started working through the rtt-exercises-2.3.2 package.
>>>>>
>>>>> That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.
>>>>>
>>>>> Here are links to various interesting things that may help debug. Let me know if I can provide any other information:
>>>>>
>>>>> my system info - http://pastebin.com/Wf8XdBcQ
>>>>> RTT make test failure - http://pastebin.com/uQeJkywc
>>>>> RTT CMakeCache - http://pastebin.com/M7ZppEhu
>>>>> rttlua error - http://pastebin.com/dcPmBpCA
>>>>>
>>>>> Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.
>>>>
>>>> Hey Chris
>>>>
>>>> Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.
>>>>
>>>> Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).
>>>>
>>>> When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.
>>>>
>>>> So something like (from memory)
>>>>
>>>> cd /path/to/build/rtt
>>>> cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
>>>> make -jN
>>>> source setup-orocos /path/to/install
>>>> make check
>>>>
>>>> And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)
>>>>
>>>> Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)
>>>>
>>>> HTH
>>>> S
>>>>
>>>> <setup-orocos>
>>>
>>> Thanks for the feedback S.
>>>
>>> I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.
>>>
>>> I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?
>>>
>>> -dustin
>>
>> gdb
>> backtrace = bt
>> ?
>>
>
>
> I recompiled everything as Debug (was Release), but GDB and Backtrace aren't immediately helpful, because the SegFault errors are actually just handled exceptions (I assume). Nothing is actually segfaulting, so BT doesn't show anything. http://pastebin.com/1kXQWMtm
>
> Building and installing RTT on my Linux box using essentially the same method creates RTT and it passes all tests. This is just happening on my Mac, which is frustrating.
>
> Any further help is appreciated.
>
> -dustin

Please send output of the following

cd /path/to/build/rtt
env | sort
gdb ./tests/core-test
run
backtrace

What branch are you using, again? For toolchain (with some corrections that haven't yet made it to upstream) I get this on Snow Leopard with boost v1.46.1 from MacPorts

&#10;Total Test time (real) =  50.38 sec&#10;&#10;The following tests FAILED:&#10;       22 - types_test (Failed)&#10;   25 - value_test (Failed)&#10;   29 - marshalling_test (Failed)&#10;     30 - property_loader_test (Failed)&#10;         31 - property_marsh_test (Failed)&#10;  32 - property_test (Failed)&#10;        33 - property_composition_test (Failed)&#10;    36 - type_discovery_container_test (Failed)&#10;        38 - typekit_test (Failed)&#10;          7 - corba-ipc-test (Failed)&#10;Errors while running CTest&#10;

osx 'make test' failing, but hello-* examples kinda work?

On Jun 13, 2011, at 11:14 AM, Stephen Roderick wrote:

On Jun 13, 2011, at 11:21 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:

On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 3:16 PM, S Roderick wrote:

On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:

Howdy all,

I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.

So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
- I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
- I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
- I already had XCode 3.2.5 installed.
- I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
- I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
- I set some environment variables for finding dynamic libraries, lua bindings, etc.
- I downloaded and started working through the rtt-exercises-2.3.2 package.

That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.

Here are links to various interesting things that may help debug. Let me know if I can provide any other information:

my system info - http://pastebin.com/Wf8XdBcQ
RTT make test failure - http://pastebin.com/uQeJkywc
RTT CMakeCache - http://pastebin.com/M7ZppEhu
rttlua error - http://pastebin.com/dcPmBpCA

Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.

Hey Chris

Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.

Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).

When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.

So something like (from memory)

cd /path/to/build/rtt
cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
make -jN
source setup-orocos /path/to/install
make check

And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)

Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)

HTH
S

<setup-orocos>

Thanks for the feedback S.

I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.

I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?

-dustin

gdb
backtrace = bt
?

I recompiled everything as Debug (was Release), but GDB and Backtrace aren't immediately helpful, because the SegFault errors are actually just handled exceptions (I assume). Nothing is actually segfaulting, so BT doesn't show anything. http://pastebin.com/1kXQWMtm

Building and installing RTT on my Linux box using essentially the same method creates RTT and it passes all tests. This is just happening on my Mac, which is frustrating.

Any further help is appreciated.

-dustin

Please send output of the following

cd /path/to/build/rtt
env | sort
gdb ./tests/core-test
run
backtrace

What branch are you using, again? For toolchain (with some corrections that haven't yet made it to upstream) I get this on Snow Leopard with boost v1.46.1 from MacPorts

&#10;Total Test time (real) =  50.38 sec&#10;&#10;The following tests FAILED:&#10;22 - types_test (Failed)&#10;25 - value_test (Failed)&#10;29 - marshalling_test (Failed)&#10;30 - property_loader_test (Failed)&#10;31 - property_marsh_test (Failed)&#10;32 - property_test (Failed)&#10;33 - property_composition_test (Failed)&#10;36 - type_discovery_container_test (Failed)&#10;38 - typekit_test (Failed)&#10; 7 - corba-ipc-test (Failed)&#10;Errors while running CTest&#10;

&#10;Program received signal EXC_BAD_ACCESS, Could not access memory.&#10;Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000&#10;

Eeek...

Requested output is here: http://pastebin.com/HHx54jh6

I'm not using a branch. I downloaded the orocos-toolchain 2.4.0 release in .tar.gz format. I'm on 10.6 as well, and I'm using Boost v1.46.1 from HomeBrew. If I should be using a toolchain branch, which branch is recommended?

-dustin

osx 'make test' failing, but hello-* examples kinda work?

On Jun 13, 2011, at 13:37 , Gooding, Dustin R. (JSC-ER411) wrote:

> On Jun 13, 2011, at 11:14 AM, Stephen Roderick wrote:
>
>> On Jun 13, 2011, at 11:21 , Gooding, Dustin R. (JSC-ER411) wrote:
>>
>>> On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:
>>>
>>>> On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:
>>>>
>>>>> On Jun 10, 2011, at 3:16 PM, S Roderick wrote:
>>>>>
>>>>>> On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:
>>>>>>
>>>>>>> Howdy all,
>>>>>>>
>>>>>>> I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.
>>>>>>>
>>>>>>> So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
>>>>>>> - I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
>>>>>>> - I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
>>>>>>> - I already had XCode 3.2.5 installed.
>>>>>>> - I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
>>>>>>> - I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
>>>>>>> - I set some environment variables for finding dynamic libraries, lua bindings, etc.
>>>>>>> - I downloaded and started working through the rtt-exercises-2.3.2 package.
>>>>>>>
>>>>>>> That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.
>>>>>>>
>>>>>>> Here are links to various interesting things that may help debug. Let me know if I can provide any other information:
>>>>>>>
>>>>>>> my system info - http://pastebin.com/Wf8XdBcQ
>>>>>>> RTT make test failure - http://pastebin.com/uQeJkywc
>>>>>>> RTT CMakeCache - http://pastebin.com/M7ZppEhu
>>>>>>> rttlua error - http://pastebin.com/dcPmBpCA
>>>>>>>
>>>>>>> Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.
>>>>>>
>>>>>> Hey Chris
>>>>>>
>>>>>> Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.
>>>>>>
>>>>>> Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).
>>>>>>
>>>>>> When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.
>>>>>>
>>>>>> So something like (from memory)
>>>>>>
>>>>>> cd /path/to/build/rtt
>>>>>> cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
>>>>>> make -jN
>>>>>> source setup-orocos /path/to/install
>>>>>> make check
>>>>>>
>>>>>> And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)
>>>>>>
>>>>>> Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)
>>>>>>
>>>>>> HTH
>>>>>> S
>>>>>>
>>>>>> <setup-orocos>
>>>>>
>>>>> Thanks for the feedback S.
>>>>>
>>>>> I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.
>>>>>
>>>>> I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?
>>>>>
>>>>> -dustin
>>>>
>>>> gdb
>>>> backtrace = bt
>>>> ?
>>>>
>>>
>>>
>>> I recompiled everything as Debug (was Release), but GDB and Backtrace aren't immediately helpful, because the SegFault errors are actually just handled exceptions (I assume). Nothing is actually segfaulting, so BT doesn't show anything. http://pastebin.com/1kXQWMtm
>>>
>>> Building and installing RTT on my Linux box using essentially the same method creates RTT and it passes all tests. This is just happening on my Mac, which is frustrating.
>>>
>>> Any further help is appreciated.
>>>
>>> -dustin
>>
>> Please send output of the following
>>
>> cd /path/to/build/rtt
>> env | sort
>> gdb ./tests/core-test
>> run
>> backtrace
>>
>>
>> What branch are you using, again? For toolchain (with some corrections that haven't yet made it to upstream) I get this on Snow Leopard with boost v1.46.1 from MacPorts
>>
>> &#10;&gt;&gt; Total Test time (real) =  50.38 sec&#10;&gt;&gt; &#10;&gt;&gt; The following tests FAILED:&#10;&gt;&gt;    22 - types_test (Failed)&#10;&gt;&gt;   25 - value_test (Failed)&#10;&gt;&gt;   29 - marshalling_test (Failed)&#10;&gt;&gt;     30 - property_loader_test (Failed)&#10;&gt;&gt;         31 - property_marsh_test (Failed)&#10;&gt;&gt;          32 - property_test (Failed)&#10;&gt;&gt;        33 - property_composition_test (Failed)&#10;&gt;&gt;    36 - type_discovery_container_test (Failed)&#10;&gt;&gt;        38 - typekit_test (Failed)&#10;&gt;&gt;          7 - corba-ipc-test (Failed)&#10;&gt;&gt; Errors while running CTest&#10;&gt;&gt;
>>
>
> &#10;&gt; Program received signal EXC_BAD_ACCESS, Could not access memory.&#10;&gt; Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000&#10;&gt;
>
> Eeek...
>
> Requested output is here: http://pastebin.com/HHx54jh6
>
> I'm not using a branch. I downloaded the orocos-toolchain 2.4.0 release in .tar.gz format. I'm on 10.6 as well, and I'm using Boost v1.46.1 from HomeBrew. If I should be using a toolchain branch, which branch is recommended?
>
> -dustin

Try the latest toolchain-2.4 branch from the git repository at https://gitorious.org/orocos-toolchain/rtt

We've had trouble in the past with boost::test ... and that backtrace is all boost::test to my eyes. There doesn't appear to be any user code in there ...

Also. do a "make install" before you run the tests. Just in case ...
S

osx 'make test' failing, but hello-* examples kinda work?

On Jun 13, 2011, at 5:12 PM, Stephen Roderick wrote:

On Jun 13, 2011, at 13:37 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 13, 2011, at 11:14 AM, Stephen Roderick wrote:

On Jun 13, 2011, at 11:21 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:

On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 3:16 PM, S Roderick wrote:

On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:

Howdy all,

I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.

So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
- I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
- I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
- I already had XCode 3.2.5 installed.
- I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
- I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
- I set some environment variables for finding dynamic libraries, lua bindings, etc.
- I downloaded and started working through the rtt-exercises-2.3.2 package.

That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.

Here are links to various interesting things that may help debug. Let me know if I can provide any other information:

my system info - http://pastebin.com/Wf8XdBcQ
RTT make test failure - http://pastebin.com/uQeJkywc
RTT CMakeCache - http://pastebin.com/M7ZppEhu
rttlua error - http://pastebin.com/dcPmBpCA

Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.

Hey Chris

Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.

Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).

When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.

So something like (from memory)

cd /path/to/build/rtt
cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
make -jN
source setup-orocos /path/to/install
make check

And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)

Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)

HTH
S

<setup-orocos>

Thanks for the feedback S.

I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.

I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?

-dustin

gdb
backtrace = bt
?

I recompiled everything as Debug (was Release), but GDB and Backtrace aren't immediately helpful, because the SegFault errors are actually just handled exceptions (I assume). Nothing is actually segfaulting, so BT doesn't show anything. http://pastebin.com/1kXQWMtm

Building and installing RTT on my Linux box using essentially the same method creates RTT and it passes all tests. This is just happening on my Mac, which is frustrating.

Any further help is appreciated.

-dustin

Please send output of the following

cd /path/to/build/rtt
env | sort
gdb ./tests/core-test
run
backtrace

What branch are you using, again? For toolchain (with some corrections that haven't yet made it to upstream) I get this on Snow Leopard with boost v1.46.1 from MacPorts

&#10;Total Test time (real) =  50.38 sec&#10;&#10;The following tests FAILED:&#10;22 - types_test (Failed)&#10;25 - value_test (Failed)&#10;29 - marshalling_test (Failed)&#10;30 - property_loader_test (Failed)&#10;31 - property_marsh_test (Failed)&#10;32 - property_test (Failed)&#10;33 - property_composition_test (Failed)&#10;36 - type_discovery_container_test (Failed)&#10;38 - typekit_test (Failed)&#10; 7 - corba-ipc-test (Failed)&#10;Errors while running CTest&#10;

&#10;Program received signal EXC_BAD_ACCESS, Could not access memory.&#10;Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000&#10;

Eeek...

Requested output is here: http://pastebin.com/HHx54jh6

I'm not using a branch. I downloaded the orocos-toolchain 2.4.0 release in .tar.gz format. I'm on 10.6 as well, and I'm using Boost v1.46.1 from HomeBrew. If I should be using a toolchain branch, which branch is recommended?

-dustin

Try the latest toolchain-2.4 branch from the git repository at https://gitorious.org/orocos-toolchain/rtt

We've had trouble in the past with boost::test ... and that backtrace is all boost::test to my eyes. There doesn't appear to be any user code in there ...

Also. do a "make install" before you run the tests. Just in case ...
S

Done. Unfortunately getting the same kind of results. Full log from git clone to make check: http://pastebin.com/uGcd6JRJ

-dustin

osx 'make test' failing, but hello-* examples kinda work?

On Jun 13, 2011, at 23:36 , Gooding, Dustin R. (JSC-ER411) wrote:

> On Jun 13, 2011, at 5:12 PM, Stephen Roderick wrote:
>
>> On Jun 13, 2011, at 13:37 , Gooding, Dustin R. (JSC-ER411) wrote:
>>
>>> On Jun 13, 2011, at 11:14 AM, Stephen Roderick wrote:
>>>
>>>> On Jun 13, 2011, at 11:21 , Gooding, Dustin R. (JSC-ER411) wrote:
>>>>
>>>>> On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:
>>>>>
>>>>>> On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:
>>>>>>
>>>>>>> On Jun 10, 2011, at 3:16 PM, S Roderick wrote:
>>>>>>>
>>>>>>>> On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:
>>>>>>>>
>>>>>>>>> Howdy all,
>>>>>>>>>
>>>>>>>>> I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.
>>>>>>>>>
>>>>>>>>> So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
>>>>>>>>> - I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
>>>>>>>>> - I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
>>>>>>>>> - I already had XCode 3.2.5 installed.
>>>>>>>>> - I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
>>>>>>>>> - I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
>>>>>>>>> - I set some environment variables for finding dynamic libraries, lua bindings, etc.
>>>>>>>>> - I downloaded and started working through the rtt-exercises-2.3.2 package.
>>>>>>>>>
>>>>>>>>> That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.
>>>>>>>>>
>>>>>>>>> Here are links to various interesting things that may help debug. Let me know if I can provide any other information:
>>>>>>>>>
>>>>>>>>> my system info - http://pastebin.com/Wf8XdBcQ
>>>>>>>>> RTT make test failure - http://pastebin.com/uQeJkywc
>>>>>>>>> RTT CMakeCache - http://pastebin.com/M7ZppEhu
>>>>>>>>> rttlua error - http://pastebin.com/dcPmBpCA
>>>>>>>>>
>>>>>>>>> Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.
>>>>>>>>
>>>>>>>> Hey Chris
>>>>>>>>
>>>>>>>> Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.
>>>>>>>>
>>>>>>>> Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).
>>>>>>>>
>>>>>>>> When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.
>>>>>>>>
>>>>>>>> So something like (from memory)
>>>>>>>>
>>>>>>>> cd /path/to/build/rtt
>>>>>>>> cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
>>>>>>>> make -jN
>>>>>>>> source setup-orocos /path/to/install
>>>>>>>> make check
>>>>>>>>
>>>>>>>> And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)
>>>>>>>>
>>>>>>>> Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)
>>>>>>>>
>>>>>>>> HTH
>>>>>>>> S
>>>>>>>>
>>>>>>>> <setup-orocos>
>>>>>>>
>>>>>>> Thanks for the feedback S.
>>>>>>>
>>>>>>> I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.
>>>>>>>
>>>>>>> I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?
>>>>>>>
>>>>>>> -dustin
>>>>>>
>>>>>> gdb
>>>>>> backtrace = bt
>>>>>> ?
>>>>>>
>>>>>
>>>>>
>>>>> I recompiled everything as Debug (was Release), but GDB and Backtrace aren't immediately helpful, because the SegFault errors are actually just handled exceptions (I assume). Nothing is actually segfaulting, so BT doesn't show anything. http://pastebin.com/1kXQWMtm
>>>>>
>>>>> Building and installing RTT on my Linux box using essentially the same method creates RTT and it passes all tests. This is just happening on my Mac, which is frustrating.
>>>>>
>>>>> Any further help is appreciated.
>>>>>
>>>>> -dustin
>>>>
>>>> Please send output of the following
>>>>
>>>> cd /path/to/build/rtt
>>>> env | sort
>>>> gdb ./tests/core-test
>>>> run
>>>> backtrace
>>>>
>>>>
>>>> What branch are you using, again? For toolchain (with some corrections that haven't yet made it to upstream) I get this on Snow Leopard with boost v1.46.1 from MacPorts
>>>>
>>>> &#10;&gt;&gt;&gt;&gt; Total Test time (real) =  50.38 sec&#10;&gt;&gt;&gt;&gt; &#10;&gt;&gt;&gt;&gt; The following tests FAILED:&#10;&gt;&gt;&gt;&gt;    22 - types_test (Failed)&#10;&gt;&gt;&gt;&gt;   25 - value_test (Failed)&#10;&gt;&gt;&gt;&gt;   29 - marshalling_test (Failed)&#10;&gt;&gt;&gt;&gt;     30 - property_loader_test (Failed)&#10;&gt;&gt;&gt;&gt;         31 - property_marsh_test (Failed)&#10;&gt;&gt;&gt;&gt;          32 - property_test (Failed)&#10;&gt;&gt;&gt;&gt;        33 - property_composition_test (Failed)&#10;&gt;&gt;&gt;&gt;    36 - type_discovery_container_test (Failed)&#10;&gt;&gt;&gt;&gt;        38 - typekit_test (Failed)&#10;&gt;&gt;&gt;&gt;          7 - corba-ipc-test (Failed)&#10;&gt;&gt;&gt;&gt; Errors while running CTest&#10;&gt;&gt;&gt;&gt;
>>>>
>>>
>>> &#10;&gt;&gt;&gt; Program received signal EXC_BAD_ACCESS, Could not access memory.&#10;&gt;&gt;&gt; Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000&#10;&gt;&gt;&gt;
>>>
>>> Eeek...
>>>
>>> Requested output is here: http://pastebin.com/HHx54jh6
>>>
>>> I'm not using a branch. I downloaded the orocos-toolchain 2.4.0 release in .tar.gz format. I'm on 10.6 as well, and I'm using Boost v1.46.1 from HomeBrew. If I should be using a toolchain branch, which branch is recommended?
>>>
>>> -dustin
>>
>> Try the latest toolchain-2.4 branch from the git repository at https://gitorious.org/orocos-toolchain/rtt
>>
>> We've had trouble in the past with boost::test ... and that backtrace is all boost::test to my eyes. There doesn't appear to be any user code in there ...
>>
>> Also. do a "make install" before you run the tests. Just in case ...
>> S
>
> Done. Unfortunately getting the same kind of results. Full log from git clone to make check: http://pastebin.com/uGcd6JRJ

Ok, that's weird. Sorry you are having so much trouble, Dustin. Can you post the following please

otool -L tests/core_test
ORO_LOGLEVEL=6 ./tests/core_test

We'll figure this out ...

Also, can you try putting all the Orocos-related library paths into DYLD_LIBRARY_PATH and just put Homebrew into DYLD_FALLBACK_LIBRARY_PATH. Not sure it will help, but that way it matches my setup.

BTW, how do you find it working with Homebrew? How does it compare to MacPorts?
S

osx 'make test' failing, but hello-* examples kinda work?

On Jun 14, 2011, at 5:27 AM, Stephen Roderick wrote:

On Jun 13, 2011, at 23:36 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 13, 2011, at 5:12 PM, Stephen Roderick wrote:

On Jun 13, 2011, at 13:37 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 13, 2011, at 11:14 AM, Stephen Roderick wrote:

On Jun 13, 2011, at 11:21 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:

On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 3:16 PM, S Roderick wrote:

On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:

Howdy all,

I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.

So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
- I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
- I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
- I already had XCode 3.2.5 installed.
- I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
- I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
- I set some environment variables for finding dynamic libraries, lua bindings, etc.
- I downloaded and started working through the rtt-exercises-2.3.2 package.

That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.

Here are links to various interesting things that may help debug. Let me know if I can provide any other information:

my system info - http://pastebin.com/Wf8XdBcQ
RTT make test failure - http://pastebin.com/uQeJkywc
RTT CMakeCache - http://pastebin.com/M7ZppEhu
rttlua error - http://pastebin.com/dcPmBpCA

Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.

Hey Chris

Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.

Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).

When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.

So something like (from memory)

cd /path/to/build/rtt
cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
make -jN
source setup-orocos /path/to/install
make check

And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)

Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)

HTH
S

<setup-orocos>

Thanks for the feedback S.

I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.

I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?

-dustin

gdb
backtrace = bt
?

I recompiled everything as Debug (was Release), but GDB and Backtrace aren't immediately helpful, because the SegFault errors are actually just handled exceptions (I assume). Nothing is actually segfaulting, so BT doesn't show anything. http://pastebin.com/1kXQWMtm

Building and installing RTT on my Linux box using essentially the same method creates RTT and it passes all tests. This is just happening on my Mac, which is frustrating.

Any further help is appreciated.

-dustin

Please send output of the following

cd /path/to/build/rtt
env | sort
gdb ./tests/core-test
run
backtrace

What branch are you using, again? For toolchain (with some corrections that haven't yet made it to upstream) I get this on Snow Leopard with boost v1.46.1 from MacPorts

&#10;Total Test time (real) =  50.38 sec&#10;&#10;The following tests FAILED:&#10;22 - types_test (Failed)&#10;25 - value_test (Failed)&#10;29 - marshalling_test (Failed)&#10;30 - property_loader_test (Failed)&#10;31 - property_marsh_test (Failed)&#10;32 - property_test (Failed)&#10;33 - property_composition_test (Failed)&#10;36 - type_discovery_container_test (Failed)&#10;38 - typekit_test (Failed)&#10; 7 - corba-ipc-test (Failed)&#10;Errors while running CTest&#10;

&#10;Program received signal EXC_BAD_ACCESS, Could not access memory.&#10;Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000&#10;

Eeek...

Requested output is here: http://pastebin.com/HHx54jh6

I'm not using a branch. I downloaded the orocos-toolchain 2.4.0 release in .tar.gz format. I'm on 10.6 as well, and I'm using Boost v1.46.1 from HomeBrew. If I should be using a toolchain branch, which branch is recommended?

-dustin

Try the latest toolchain-2.4 branch from the git repository at https://gitorious.org/orocos-toolchain/rtt

We've had trouble in the past with boost::test ... and that backtrace is all boost::test to my eyes. There doesn't appear to be any user code in there ...

Also. do a "make install" before you run the tests. Just in case ...
S

Done. Unfortunately getting the same kind of results. Full log from git clone to make check: http://pastebin.com/uGcd6JRJ

Ok, that's weird. Sorry you are having so much trouble, Dustin. Can you post the following please

otool -L tests/core_test
ORO_LOGLEVEL=6 ./tests/core_test

We'll figure this out ...

Also, can you try putting all the Orocos-related library paths into DYLD_LIBRARY_PATH and just put Homebrew into DYLD_FALLBACK_LIBRARY_PATH. Not sure it will help, but that way it matches my setup.

BTW, how do you find it working with Homebrew? How does it compare to MacPorts?
S

You mentioned trouble with Boost::Test in the past. Have you considered switching to a different unit testing framework? I realize that would be a decent amount of work, but it may be worth it in the long run, depending on the kind of trouble you're having. We've been kicking the tires of Google Test and so far we really like it. It's cross-platform, it's simple to use, it integrates well with CMake and CTest... and, selfishly, it for-sure works on Mac and is available in both Homebrew and MacPorts. ;)

-dustin

osx 'make test' failing, but hello-* examples kinda work?

On Tue, Jun 14, 2011 at 04:31:05PM +0200, Gooding, Dustin R. (JSC-ER411) wrote:

> rttlua error - http://pastebin.com/dcPmBpCA

I can confirm this one on gnulinux, the problem also shows in the
deployer (that fails more gracefully) . The reason is that the narrow
method fails to downcast to an int type. No idea why. Will look into
it.

Thanks for reporting!

Markus

PS: Could you somehow fix the quoting of your mail client? This thread
is almost impossible to read.

osx 'make test' failing, but hello-* examples kinda work?

On Jul 4, 2011, at 5:34 AM, Markus Klotzbuecher wrote:

> On Tue, Jun 14, 2011 at 04:31:05PM +0200, Gooding, Dustin R. (JSC-ER411) wrote:
>
>> rttlua error - http://pastebin.com/dcPmBpCA
>
> I can confirm this one on gnulinux, the problem also shows in the
> deployer (that fails more gracefully) . The reason is that the narrow
> method fails to downcast to an int type. No idea why. Will look into
> it.
>
> Thanks for reporting!
>
> Markus
>
> PS: Could you somehow fix the quoting of your mail client? This thread
> is almost impossible to read.
>
>
>

Sorry Markus. I'm just using normal Mail.app on my Mac. I don't think I have any weird settings regarding forwarding. In Composing>Responding, I have "Quote the text of the original message", "Increase quote level" and "Include selected text, if any, otherwise include all text" checked. I'll gladly change settings to make future threads more readable. (FWIW, When I look at the threads in my mail client, I see the blocks of quoted text indented, so it looked OK from my end the whole time. Sorry again.)

--
dustin

osx 'make test' failing, but hello-* examples kinda work?

On Jul 6, 2011, at 08:59 , Gooding, Dustin R. (JSC-ER411) wrote:

> On Jul 4, 2011, at 5:34 AM, Markus Klotzbuecher wrote:
>
>> On Tue, Jun 14, 2011 at 04:31:05PM +0200, Gooding, Dustin R. (JSC-ER411) wrote:
>>
>>> rttlua error - http://pastebin.com/dcPmBpCA
>>
>> I can confirm this one on gnulinux, the problem also shows in the
>> deployer (that fails more gracefully) . The reason is that the narrow
>> method fails to downcast to an int type. No idea why. Will look into
>> it.
>>
>> Thanks for reporting!
>>
>> Markus
>>
>> PS: Could you somehow fix the quoting of your mail client? This thread
>> is almost impossible to read.
>>
>>
>>
>
>
> Sorry Markus. I'm just using normal Mail.app on my Mac. I don't think I have any weird settings regarding forwarding. In Composing>Responding, I have "Quote the text of the original message", "Increase quote level" and "Include selected text, if any, otherwise include all text" checked. I'll gladly change settings to make future threads more readable. (FWIW, When I look at the threads in my mail client, I see the blocks of quoted text indented, so it looked OK from my end the whole time. Sorry again.)

It's not Mail.app.

The first email that looks bad for me is actually Peter quoting Dustin, on June 15 ... up to then, all is well.
S

osx 'make test' failing, but hello-* examples kinda work?

On Wed, Jul 06, 2011 at 03:30:44PM +0200, Stephen Roderick wrote:
> On Jul 6, 2011, at 08:59 , Gooding, Dustin R. (JSC-ER411) wrote:
>
> > On Jul 4, 2011, at 5:34 AM, Markus Klotzbuecher wrote:
> >
> >> On Tue, Jun 14, 2011 at 04:31:05PM +0200, Gooding, Dustin R. (JSC-ER411) wrote:
> >>
> >>> rttlua error - http://pastebin.com/dcPmBpCA
> >>
> >> I can confirm this one on gnulinux, the problem also shows in the
> >> deployer (that fails more gracefully) . The reason is that the narrow
> >> method fails to downcast to an int type. No idea why. Will look into
> >> it.
> >>
> >> Thanks for reporting!
> >>
> >> Markus
> >>
> >> PS: Could you somehow fix the quoting of your mail client? This thread
> >> is almost impossible to read.
> >>
> >>
> >>
> >
> >
> > Sorry Markus. I'm just using normal Mail.app on my Mac. I don't think I have any weird settings regarding forwarding. In Composing>Responding, I have "Quote the text of the original message", "Increase quote level" and "Include selected text, if any, otherwise include all text" checked. I'll gladly change settings to make future threads more readable. (FWIW, When I look at the threads in my mail client, I see the blocks of quoted text indented, so it looked OK from my end the whole time. Sorry again.)
>
> It's not Mail.app.
>
> The first email that looks bad for me is actually Peter quoting
> Dustin, on June 15 ... up to then, all is well.

It looks to me like you two were accumulating indentation, that Peter
then "flatted" again. If you indent by ">" this is not possible. There
are also some HTML mails in there which generally make it uglier for
people mailing from the console.

But these are just suggestions, I'm not trying to tell you guys how to
use email :-)

Markus

osx 'make test' failing, but hello-* examples kinda work?

Hi Dustin,

On Mon, Jul 04, 2011 at 12:34:33PM +0200, Markus Klotzbuecher wrote:
> On Tue, Jun 14, 2011 at 04:31:05PM +0200, Gooding, Dustin R. (JSC-ER411) wrote:
>
> > rttlua error - http://pastebin.com/dcPmBpCA
>
> I can confirm this one on gnulinux, the problem also shows in the
> deployer (that fails more gracefully) . The reason is that the narrow
> method fails to downcast to an int type. No idea why. Will look into
> it.

Are you on a 32 or 64 bit system? You compiled yourself and are not
using the debian packages, correct?

Thanks
Markus

osx 'make test' failing, but hello-* examples kinda work?

On Jul 4, 2011, at 9:18 AM, Markus Klotzbuecher wrote:

> Hi Dustin,
>
> On Mon, Jul 04, 2011 at 12:34:33PM +0200, Markus Klotzbuecher wrote:
>> On Tue, Jun 14, 2011 at 04:31:05PM +0200, Gooding, Dustin R. (JSC-ER411) wrote:
>>
>>> rttlua error - http://pastebin.com/dcPmBpCA
>>
>> I can confirm this one on gnulinux, the problem also shows in the
>> deployer (that fails more gracefully) . The reason is that the narrow
>> method fails to downcast to an int type. No idea why. Will look into
>> it.
>
> Are you on a 32 or 64 bit system? You compiled yourself and are not
> using the debian packages, correct?
>
> Thanks
> Markus

I'm on a 64-bit machine (latest MBP with an i7). I compiled Orocos using CMake. Supporting dependencies were installed using Homebrew, which compiles from source.

--
dustin

osx 'make test' failing, but hello-* examples kinda work?

On Wed, Jul 06, 2011 at 03:06:12PM +0200, Gooding, Dustin R. (JSC-ER411) wrote:
> On Jul 4, 2011, at 9:18 AM, Markus Klotzbuecher wrote:
>
> > Hi Dustin,
> >
> > On Mon, Jul 04, 2011 at 12:34:33PM +0200, Markus Klotzbuecher wrote:
> >> On Tue, Jun 14, 2011 at 04:31:05PM +0200, Gooding, Dustin R. (JSC-ER411) wrote:
> >>
> >>> rttlua error - http://pastebin.com/dcPmBpCA
> >>
> >> I can confirm this one on gnulinux, the problem also shows in the
> >> deployer (that fails more gracefully) . The reason is that the narrow
> >> method fails to downcast to an int type. No idea why. Will look into
> >> it.
> >
> > Are you on a 32 or 64 bit system? You compiled yourself and are not
> > using the debian packages, correct?
> >
> > Thanks
> > Markus
>
> I'm on a 64-bit machine (latest MBP with an i7). I compiled Orocos
> using CMake. Supporting dependencies were installed using Homebrew,
> which compiles from source.

Thanks Dustin. We can reproduce this and are looking into it.

Marku

osx 'make test' failing, but hello-* examples kinda work?

On Tue, Jun 14, 2011 at 4:31 PM, Gooding, Dustin R. (JSC-ER411)
<dustin [dot] r [dot] gooding [..] ...> wrote:
> On Jun 14, 2011, at 5:27 AM, Stephen Roderick wrote:
>
> On Jun 13, 2011, at 23:36 , Gooding, Dustin R. (JSC-ER411) wrote:
>
> On Jun 13, 2011, at 5:12 PM, Stephen Roderick wrote:
>
> On Jun 13, 2011, at 13:37 , Gooding, Dustin R. (JSC-ER411) wrote:
>
> On Jun 13, 2011, at 11:14 AM, Stephen Roderick wrote:
>
> On Jun 13, 2011, at 11:21 , Gooding, Dustin R. (JSC-ER411) wrote:
>
> On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:
>
> On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:
>
> On Jun 10, 2011, at 3:16 PM, S Roderick wrote:
>
> On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:
>
> Howdy all,
> I'm investigating Orocos but I'm having some trouble getting it to behave
> properly.   I'm on a current MacBook Pro running the latest versions of most
> everything.  First I downloaded the orocos-toolchain-2.4.0 package and tried
> using the autoproj install method.  This failed to produce usable results.
>  Next, I attempted to just use CMake to build RTT and OCL and had decent
> luck.  In fact, I was even able to start working through the hello-*
> examples without much difficulty.  I did notice some odd things, like "true"
> and "false" not printing out when I would try to get a component's state
> information.  When I got to hello-6-scripting, though, while reading the
> scripting documentation, I also started looking into the rtt-lua interface
> and found my first error.  Before I get into that, I decided to go back and
> enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests
> passed.  Well, with a resounding "SEGFAULT", 34 of 36 tests failed.   Before
> I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's
> CMake tests are supposed to pass and if they are, how to fix my install so
> that they do.  I'll be happy to provide whatever information is needed to
> help solve this.  I also understand that OS X support for RTT 2.4.0 is there
> but some things (plugin loading) are not fully tested?  So... to that end,
> where I can, I'll be glad to be an OS X Guinea pig, too.
> So here's what I've done (roughly
> following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-installation.html):
> - I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to
> /opt/orocos-toolchain-2.4.0
> - I used Homebrew (http://mxcl.github.com/homebrew/) to install various
> dependencies (like readline, lua5, etc).
> - I already had XCode 3.2.5 installed.
> - I went into the rtt directory, make a build directory, used ccmake to
> configure the build, then ran make (working through dependency issues with
> Homebrew).
> - I ran make install.  This put the various rtt things into /usr/local/
> (include/orocos, lib/orocos, etc).
> - I set some environment variables for finding dynamic libraries, lua
> bindings, etc.
> - I downloaded and started working through the rtt-exercises-2.3.2 package.
> That's when I started seeing weird things and went back in and re-ran CMake
> with testing enabled.
> Here are links to various interesting things that may help debug.  Let me
> know if I can provide any other information:
> my system info - http://pastebin.com/Wf8XdBcQ
> RTT make test failure - http://pastebin.com/uQeJkywc
> RTT CMakeCache - http://pastebin.com/M7ZppEhu
> rttlua error - http://pastebin.com/dcPmBpCA
> Thanks Orocos guys.  So far it looks like a pretty great package (turning a
> blind eye to the current weirdness).  Keep up the good work.
>
> Hey Chris
> Mac OS X support is pretty good actually, and we've been using it with v1
> for 3+ years and it's as solid as Linux.
> Having said that, check the ML and forum. We've been working recent failing
> unit tests on the Mac for v2. I think we have it down to about 6 or 8
> failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the
> issues are likely boost-related).
> When running the unit test on the Mac you have to make sure you set a bunch
> of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached
> script on both Mac and Linux,  and feed it the absolute path to my install
> dir. You might have to modify it a little if you're not using MacPorts.
> So something like (from memory)
> cd /path/to/build/rtt
> cmake  -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
> make -jN
> source setup-orocos /path/to/install
> make check
> And don't run "make test", run "make check". It does some additional setup
> and teardown (we really need to disable make test somehow ...)
> Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus'
> awesomeness yet ... :-)
> HTH
> S
> <setup-orocos>
>
> Thanks for the feedback S.
> I made some changes to my ~/.bash_profile (that you can see
> here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly.  I
> modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in
> what your setup-orocos script would have calculated for me.
> I also tried using 'make check' instead, but still no luck.  See the results
> here: http://pastebin.com/hSBkmiKN  This time, though, all tests fail with a
> SegFault.  Ideas?
> -dustin
>
> gdb
> backtrace = bt
> ?
>
> I recompiled everything as Debug (was Release), but GDB and Backtrace aren't
> immediately helpful, because the SegFault errors are actually just handled
> exceptions (I assume).  Nothing is actually segfaulting, so BT doesn't show
> anything.  http://pastebin.com/1kXQWMtm
> Building and installing RTT on my Linux box using essentially the same
> method creates RTT and it passes all tests.  This is just happening on my
> Mac, which is frustrating.
> Any further help is appreciated.
> -dustin
>
> Please send output of the following
> cd /path/to/build/rtt
> env | sort
> gdb ./tests/core-test
>   run
>   backtrace
>
> What branch are you using, again? For toolchain (with some corrections that
> haven't yet made it to upstream) I get this on Snow Leopard with boost
> v1.46.1 from MacPorts
> &#10;&gt; Total Test time (real) =  50.38 sec&#10;&gt; The following tests FAILED:&#10;&gt; 22 - types_test (Failed)&#10;&gt; 25 - value_test (Failed)&#10;&gt; 29 - marshalling_test (Failed)&#10;&gt; 30 - property_loader_test (Failed)&#10;&gt; 31 - property_marsh_test (Failed)&#10;&gt; 32 - property_test (Failed)&#10;&gt; 33 - property_composition_test (Failed)&#10;&gt; 36 - type_discovery_container_test (Failed)&#10;&gt; 38 - typekit_test (Failed)&#10;&gt;  7 - corba-ipc-test (Failed)&#10;&gt; Errors while running CTest&#10;&gt;
>
>
> &#10;&gt; Program received signal EXC_BAD_ACCESS, Could not access memory.&#10;&gt; Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000&#10;&gt;
>
> Eeek...
> Requested output is here: http://pastebin.com/HHx54jh6
> I'm not using a branch.  I downloaded the orocos-toolchain 2.4.0 release in
> .tar.gz format.   I'm on 10.6 as well, and I'm using Boost v1.46.1 from
> HomeBrew.    If I should be using a toolchain branch, which branch is
> recommended?
> -dustin
>
> Try the latest toolchain-2.4 branch from the git repository at
> https://gitorious.org/orocos-toolchain/rtt
> We've had trouble in the past with boost::test ... and that backtrace is all
> boost::test to my eyes. There doesn't appear to be any user code in there
> ...
> Also. do a "make install" before you run the tests. Just in case ...
> S
>
> Done.  Unfortunately getting the same kind of results.  Full log from git
> clone to make check:   http://pastebin.com/uGcd6JRJ
>
> Ok, that's weird. Sorry you are having so much trouble, Dustin. Can you post
> the following please
> otool -L tests/core_test
> ORO_LOGLEVEL=6 ./tests/core_test
> We'll figure this out ...
> Also, can you try putting all the Orocos-related library paths into
> DYLD_LIBRARY_PATH and just put Homebrew  into DYLD_FALLBACK_LIBRARY_PATH.
> Not sure it will help, but that way it matches my setup.
> BTW, how do you find it working with Homebrew? How does it compare to
> MacPorts?
> S
>
> You mentioned trouble with Boost::Test in the past.  Have you considered
> switching to a different unit testing framework?  I realize that would be a
> decent amount of work, but it may be worth it in the long run, depending on
> the kind of trouble you're having.   We've been kicking the tires of Google
> Test and so far we really like it.  It's cross-platform, it's simple to use,
> it integrates well with CMake and CTest...  and, selfishly, it for-sure
> works on Mac and is available in both Homebrew and MacPorts.  ;)
> -dustin

We 'just' switched to boost.test because libcppunit was not doing it
for us anymore and boost.test was supported by hudson/jenkins, our
build farm. In 1.x, we're using boost.test since 1.10 on too, so that
is not the issue.

Could you apply the patch in attachment and recompile your tests ? We
did a hack in 2.x on boost.test which we should have disabled by
default... maybe this one is troublesome on your target/boost combo.

We're working on other macos-x patches too, so the most up-to-date
fixes are on the toolchain-2.4 git branch.

Peter

osx 'make test' failing, but hello-* examples kinda work?

On Jun 15, 2011, at 11:25 AM, Peter Soetens wrote:

> On Tue, Jun 14, 2011 at 4:31 PM, Gooding, Dustin R. (JSC-ER411)
> <dustin [dot] r [dot] gooding [..] ...> wrote:
>> On Jun 14, 2011, at 5:27 AM, Stephen Roderick wrote:
>>
>> On Jun 13, 2011, at 23:36 , Gooding, Dustin R. (JSC-ER411) wrote:
>>
>> On Jun 13, 2011, at 5:12 PM, Stephen Roderick wrote:
>>
>> On Jun 13, 2011, at 13:37 , Gooding, Dustin R. (JSC-ER411) wrote:
>>
>> On Jun 13, 2011, at 11:14 AM, Stephen Roderick wrote:
>>
>> On Jun 13, 2011, at 11:21 , Gooding, Dustin R. (JSC-ER411) wrote:
>>
>> On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:
>>
>> On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:
>>
>> On Jun 10, 2011, at 3:16 PM, S Roderick wrote:
>>
>> On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:
>>
>> Howdy all,
>> I'm investigating Orocos but I'm having some trouble getting it to behave
>> properly. I'm on a current MacBook Pro running the latest versions of most
>> everything. First I downloaded the orocos-toolchain-2.4.0 package and tried
>> using the autoproj install method. This failed to produce usable results.
>> Next, I attempted to just use CMake to build RTT and OCL and had decent
>> luck. In fact, I was even able to start working through the hello-*
>> examples without much difficulty. I did notice some odd things, like "true"
>> and "false" not printing out when I would try to get a component's state
>> information. When I got to hello-6-scripting, though, while reading the
>> scripting documentation, I also started looking into the rtt-lua interface
>> and found my first error. Before I get into that, I decided to go back and
>> enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests
>> passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before
>> I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's
>> CMake tests are supposed to pass and if they are, how to fix my install so
>> that they do. I'll be happy to provide whatever information is needed to
>> help solve this. I also understand that OS X support for RTT 2.4.0 is there
>> but some things (plugin loading) are not fully tested? So... to that end,
>> where I can, I'll be glad to be an OS X Guinea pig, too.
>> So here's what I've done (roughly
>> following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
>> - I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to
>> /opt/orocos-toolchain-2.4.0
>> - I used Homebrew (http://mxcl.github.com/homebrew/) to install various
>> dependencies (like readline, lua5, etc).
>> - I already had XCode 3.2.5 installed.
>> - I went into the rtt directory, make a build directory, used ccmake to
>> configure the build, then ran make (working through dependency issues with
>> Homebrew).
>> - I ran make install. This put the various rtt things into /usr/local/
>> (include/orocos, lib/orocos, etc).
>> - I set some environment variables for finding dynamic libraries, lua
>> bindings, etc.
>> - I downloaded and started working through the rtt-exercises-2.3.2 package.
>> That's when I started seeing weird things and went back in and re-ran CMake
>> with testing enabled.
>> Here are links to various interesting things that may help debug. Let me
>> know if I can provide any other information:
>> my system info - http://pastebin.com/Wf8XdBcQ
>> RTT make test failure - http://pastebin.com/uQeJkywc
>> RTT CMakeCache - http://pastebin.com/M7ZppEhu
>> rttlua error - http://pastebin.com/dcPmBpCA
>> Thanks Orocos guys. So far it looks like a pretty great package (turning a
>> blind eye to the current weirdness). Keep up the good work.
>>
>> Hey Chris
>> Mac OS X support is pretty good actually, and we've been using it with v1
>> for 3+ years and it's as solid as Linux.
>> Having said that, check the ML and forum. We've been working recent failing
>> unit tests on the Mac for v2. I think we have it down to about 6 or 8
>> failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the
>> issues are likely boost-related).
>> When running the unit test on the Mac you have to make sure you set a bunch
>> of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached
>> script on both Mac and Linux, and feed it the absolute path to my install
>> dir. You might have to modify it a little if you're not using MacPorts.
>> So something like (from memory)
>> cd /path/to/build/rtt
>> cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
>> make -jN
>> source setup-orocos /path/to/install
>> make check
>> And don't run "make test", run "make check". It does some additional setup
>> and teardown (we really need to disable make test somehow ...)
>> Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus'
>> awesomeness yet ... :-)
>> HTH
>> S
>> <setup-orocos>
>>
>> Thanks for the feedback S.
>> I made some changes to my ~/.bash_profile (that you can see
>> here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I
>> modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in
>> what your setup-orocos script would have calculated for me.
>> I also tried using 'make check' instead, but still no luck. See the results
>> here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a
>> SegFault. Ideas?
>> -dustin
>>
>> gdb
>> backtrace = bt
>> ?
>>
>> I recompiled everything as Debug (was Release), but GDB and Backtrace aren't
>> immediately helpful, because the SegFault errors are actually just handled
>> exceptions (I assume). Nothing is actually segfaulting, so BT doesn't show
>> anything. http://pastebin.com/1kXQWMtm
>> Building and installing RTT on my Linux box using essentially the same
>> method creates RTT and it passes all tests. This is just happening on my
>> Mac, which is frustrating.
>> Any further help is appreciated.
>> -dustin
>>
>> Please send output of the following
>> cd /path/to/build/rtt
>> env | sort
>> gdb ./tests/core-test
>> run
>> backtrace
>>
>> What branch are you using, again? For toolchain (with some corrections that
>> haven't yet made it to upstream) I get this on Snow Leopard with boost
>> v1.46.1 from MacPorts
>> &#10;&gt;&gt; Total Test time (real) =  50.38 sec&#10;&gt;&gt; The following tests FAILED:&#10;&gt;&gt; 22 - types_test (Failed)&#10;&gt;&gt; 25 - value_test (Failed)&#10;&gt;&gt; 29 - marshalling_test (Failed)&#10;&gt;&gt; 30 - property_loader_test (Failed)&#10;&gt;&gt; 31 - property_marsh_test (Failed)&#10;&gt;&gt; 32 - property_test (Failed)&#10;&gt;&gt; 33 - property_composition_test (Failed)&#10;&gt;&gt; 36 - type_discovery_container_test (Failed)&#10;&gt;&gt; 38 - typekit_test (Failed)&#10;&gt;&gt;  7 - corba-ipc-test (Failed)&#10;&gt;&gt; Errors while running CTest&#10;&gt;&gt;
>>
>>
>> &#10;&gt;&gt; Program received signal EXC_BAD_ACCESS, Could not access memory.&#10;&gt;&gt; Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000&#10;&gt;&gt;
>>
>> Eeek...
>> Requested output is here: http://pastebin.com/HHx54jh6
>> I'm not using a branch. I downloaded the orocos-toolchain 2.4.0 release in
>> .tar.gz format. I'm on 10.6 as well, and I'm using Boost v1.46.1 from
>> HomeBrew. If I should be using a toolchain branch, which branch is
>> recommended?
>> -dustin
>>
>> Try the latest toolchain-2.4 branch from the git repository at
>> https://gitorious.org/orocos-toolchain/rtt
>> We've had trouble in the past with boost::test ... and that backtrace is all
>> boost::test to my eyes. There doesn't appear to be any user code in there
>> ...
>> Also. do a "make install" before you run the tests. Just in case ...
>> S
>>
>> Done. Unfortunately getting the same kind of results. Full log from git
>> clone to make check: http://pastebin.com/uGcd6JRJ
>>
>> Ok, that's weird. Sorry you are having so much trouble, Dustin. Can you post
>> the following please
>> otool -L tests/core_test
>> ORO_LOGLEVEL=6 ./tests/core_test
>> We'll figure this out ...
>> Also, can you try putting all the Orocos-related library paths into
>> DYLD_LIBRARY_PATH and just put Homebrew into DYLD_FALLBACK_LIBRARY_PATH.
>> Not sure it will help, but that way it matches my setup.
>> BTW, how do you find it working with Homebrew? How does it compare to
>> MacPorts?
>> S
>>
>> You mentioned trouble with Boost::Test in the past. Have you considered
>> switching to a different unit testing framework? I realize that would be a
>> decent amount of work, but it may be worth it in the long run, depending on
>> the kind of trouble you're having. We've been kicking the tires of Google
>> Test and so far we really like it. It's cross-platform, it's simple to use,
>> it integrates well with CMake and CTest... and, selfishly, it for-sure
>> works on Mac and is available in both Homebrew and MacPorts. ;)
>> -dustin
>
> We 'just' switched to boost.test because libcppunit was not doing it
> for us anymore and boost.test was supported by hudson/jenkins, our
> build farm. In 1.x, we're using boost.test since 1.10 on too, so that
> is not the issue.
>
> Could you apply the patch in attachment and recompile your tests ? We
> did a hack in 2.x on boost.test which we should have disabled by
> default... maybe this one is troublesome on your target/boost combo.
>
> We're working on other macos-x patches too, so the most up-to-date
> fixes are on the toolchain-2.4 git branch.
>
> Peter
> <0001-tests-only-include-test-suite-hack-when-specifically.patch>

I pulled the latest from the toolchain-2.4 branch, applied the patch you attached, and... still getting SegFaults everywhere.

-dustin

osx 'make test' failing, but hello-* examples kinda work?

On Thursday 16 June 2011 04:42:09 Gooding, Dustin R. (JSC-ER411) wrote:
...
> > Could you apply the patch in attachment and recompile your tests ? We
> > did a hack in 2.x on boost.test which we should have disabled by
> > default... maybe this one is troublesome on your target/boost combo.
> >
> > We're working on other macos-x patches too, so the most up-to-date
> > fixes are on the toolchain-2.4 git branch.
> >
> > Peter
> > <0001-tests-only-include-test-suite-hack-when-specifically.patch>
>
> I pulled the latest from the toolchain-2.4 branch, applied the patch you
> attached, and... still getting SegFaults everywhere.
>
> -dustin

What you could do at least is to keep using the latest toolchain-2.4 with the
examples and report any anomalies you're seeing in 'real life'. I don't have
an os-x virtual machine (nor any Apple devices), so I can't include os-x in
the build farm... I'm mostly relying on Stephen and Ruben to keep an eye on
os-x

Peter

osx 'make test' failing, but hello-* examples kinda work?

On Jun 16, 2011, at 05:34 , Peter Soetens wrote:

> On Thursday 16 June 2011 04:42:09 Gooding, Dustin R. (JSC-ER411) wrote:
> ...
>>> Could you apply the patch in attachment and recompile your tests ? We
>>> did a hack in 2.x on boost.test which we should have disabled by
>>> default... maybe this one is troublesome on your target/boost combo.
>>>
>>> We're working on other macos-x patches too, so the most up-to-date
>>> fixes are on the toolchain-2.4 git branch.
>>>
>>> Peter
>>> <0001-tests-only-include-test-suite-hack-when-specifically.patch>
>>
>> I pulled the latest from the toolchain-2.4 branch, applied the patch you
>> attached, and... still getting SegFaults everywhere.
>>
>> -dustin
>
> What you could do at least is to keep using the latest toolchain-2.4 with the
> examples and report any anomalies you're seeing in 'real life'. I don't have
> an os-x virtual machine (nor any Apple devices), so I can't include os-x in
> the build farm... I'm mostly relying on Stephen and Ruben to keep an eye on
> os-x
>
> Peter

I intend to add the osx builds into the new build system this weekend.
S

osx 'make test' failing, but hello-* examples kinda work?

On Jun 14, 2011, at 5:27 AM, Stephen Roderick wrote:

On Jun 13, 2011, at 23:36 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 13, 2011, at 5:12 PM, Stephen Roderick wrote:

On Jun 13, 2011, at 13:37 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 13, 2011, at 11:14 AM, Stephen Roderick wrote:

On Jun 13, 2011, at 11:21 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 9:54 PM, Stephen Roderick wrote:

On Jun 10, 2011, at 21:24 , Gooding, Dustin R. (JSC-ER411) wrote:

On Jun 10, 2011, at 3:16 PM, S Roderick wrote:

On Jun 10, 2011, at 15:43 , Gooding, Dustin R. (JSC-ER411) wrote:

Howdy all,

I'm investigating Orocos but I'm having some trouble getting it to behave properly. I'm on a current MacBook Pro running the latest versions of most everything. First I downloaded the orocos-toolchain-2.4.0 package and tried using the autoproj install method. This failed to produce usable results. Next, I attempted to just use CMake to build RTT and OCL and had decent luck. In fact, I was even able to start working through the hello-* examples without much difficulty. I did notice some odd things, like "true" and "false" not printing out when I would try to get a component's state information. When I got to hello-6-scripting, though, while reading the scripting documentation, I also started looking into the rtt-lua interface and found my first error. Before I get into that, I decided to go back and enable the BUILD_TESTING option in RTT's CMake and confirm that RTT's tests passed. Well, with a resounding "SEGFAULT", 34 of 36 tests failed. Before I dig into fixing the Lua binding to RTT, I'd like to confirm that RTT's CMake tests are supposed to pass and if they are, how to fix my install so that they do. I'll be happy to provide whatever information is needed to help solve this. I also understand that OS X support for RTT 2.4.0 is there but some things (plugin loading) are not fully tested? So... to that end, where I can, I'll be glad to be an OS X Guinea pig, too.

So here's what I've done (roughly following http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-insta...):
- I downloaded the orocos-toolchain-2.4.0.tar.gz package and extracted it to /opt/orocos-toolchain-2.4.0
- I used Homebrew (http://mxcl.github.com/homebrew/) to install various dependencies (like readline, lua5, etc).
- I already had XCode 3.2.5 installed.
- I went into the rtt directory, make a build directory, used ccmake to configure the build, then ran make (working through dependency issues with Homebrew).
- I ran make install. This put the various rtt things into /usr/local/ (include/orocos, lib/orocos, etc).
- I set some environment variables for finding dynamic libraries, lua bindings, etc.
- I downloaded and started working through the rtt-exercises-2.3.2 package.

That's when I started seeing weird things and went back in and re-ran CMake with testing enabled.

Here are links to various interesting things that may help debug. Let me know if I can provide any other information:

my system info - http://pastebin.com/Wf8XdBcQ
RTT make test failure - http://pastebin.com/uQeJkywc
RTT CMakeCache - http://pastebin.com/M7ZppEhu
rttlua error - http://pastebin.com/dcPmBpCA

Thanks Orocos guys. So far it looks like a pretty great package (turning a blind eye to the current weirdness). Keep up the good work.

Hey Chris

Mac OS X support is pretty good actually, and we've been using it with v1 for 3+ years and it's as solid as Linux.

Having said that, check the ML and forum. We've been working recent failing unit tests on the Mac for v2. I think we have it down to about 6 or 8 failing total ... that's v2.4 w/ Snow Leopard and MacPorts (some of the issues are likely boost-related).

When running the unit test on the Mac you have to make sure you set a bunch of env var's: RTT_COMPONENT_PATH, DYLD_LIBRARY_PATH, etc. I use the attached script on both Mac and Linux, and feed it the absolute path to my install dir. You might have to modify it a little if you're not using MacPorts.

So something like (from memory)

cd /path/to/build/rtt
cmake -DCMAKE_INSTALL_PREFIX /path/to/install /path/to/code/rtt
make -jN
source setup-orocos /path/to/install
make check

And don't run "make test", run "make check". It does some additional setup and teardown (we really need to disable make test somehow ...)

Can't help you with Lua, I'm afraid. Haven't gotten around to trying Markus' awesomeness yet ... :-)

HTH
S

<setup-orocos>

Thanks for the feedback S.

I made some changes to my ~/.bash_profile (that you can see here: http://pastebin.com/1G9RzaEk) but didn't use your script exactly. I modified my DYLD* and RTT_COMPONENT_PATH variables by just hardcoding in what your setup-orocos script would have calculated for me.

I also tried using 'make check' instead, but still no luck. See the results here: http://pastebin.com/hSBkmiKN This time, though, all tests fail with a SegFault. Ideas?

-dustin

gdb
backtrace = bt
?

I recompiled everything as Debug (was Release), but GDB and Backtrace aren't immediately helpful, because the SegFault errors are actually just handled exceptions (I assume). Nothing is actually segfaulting, so BT doesn't show anything. http://pastebin.com/1kXQWMtm

Building and installing RTT on my Linux box using essentially the same method creates RTT and it passes all tests. This is just happening on my Mac, which is frustrating.

Any further help is appreciated.

-dustin

Please send output of the following

cd /path/to/build/rtt
env | sort
gdb ./tests/core-test
run
backtrace

What branch are you using, again? For toolchain (with some corrections that haven't yet made it to upstream) I get this on Snow Leopard with boost v1.46.1 from MacPorts

&#10;Total Test time (real) =  50.38 sec&#10;&#10;The following tests FAILED:&#10;22 - types_test (Failed)&#10;25 - value_test (Failed)&#10;29 - marshalling_test (Failed)&#10;30 - property_loader_test (Failed)&#10;31 - property_marsh_test (Failed)&#10;32 - property_test (Failed)&#10;33 - property_composition_test (Failed)&#10;36 - type_discovery_container_test (Failed)&#10;38 - typekit_test (Failed)&#10; 7 - corba-ipc-test (Failed)&#10;Errors while running CTest&#10;

&#10;Program received signal EXC_BAD_ACCESS, Could not access memory.&#10;Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000&#10;

Eeek...

Requested output is here: http://pastebin.com/HHx54jh6

I'm not using a branch. I downloaded the orocos-toolchain 2.4.0 release in .tar.gz format. I'm on 10.6 as well, and I'm using Boost v1.46.1 from HomeBrew. If I should be using a toolchain branch, which branch is recommended?

-dustin

Try the latest toolchain-2.4 branch from the git repository at https://gitorious.org/orocos-toolchain/rtt

We've had trouble in the past with boost::test ... and that backtrace is all boost::test to my eyes. There doesn't appear to be any user code in there ...

Also. do a "make install" before you run the tests. Just in case ...
S

Done. Unfortunately getting the same kind of results. Full log from git clone to make check: http://pastebin.com/uGcd6JRJ

Ok, that's weird. Sorry you are having so much trouble, Dustin. Can you post the following please

otool -L tests/core_test
ORO_LOGLEVEL=6 ./tests/core_test

We'll figure this out ...

Also, can you try putting all the Orocos-related library paths into DYLD_LIBRARY_PATH and just put Homebrew into DYLD_FALLBACK_LIBRARY_PATH. Not sure it will help, but that way it matches my setup.

BTW, how do you find it working with Homebrew? How does it compare to MacPorts?
S

otool and loglevel=6 results here: http://pastebin.com/JVyyZjdT (And the segfault at the end of the pastebin is the same "could not access memory" error as before, based on an unposted gdb run.)

I replaced my DYLD_FALLBACK_LIBRARY_PATH with the more widely used DYLD_LIBRARY_PATH and re-ran otool as well as make check and I'm getting the same results. I don't think that's the issue.

I'm beginning to wonder if the problem is just Boost::Test related? I found a post on Boost's mailing list documenting an oddly similar thing happening to someone else (http://groups.google.com/group/boost-list/browse_thread/thread/bfac04732...), but I checked to see if his resolution was possible for me, and it seems as though the problem isn't actually the same. He was #including the wrong header file, but RTT isn't. Maybe this gives you a hint, though.

Re: MacPorts vs Homebrew. One of the things that really frustrated me about MacPorts was that it insisted on installing its own copies of dependencies that OS X already provided (Python, Ruby, X11, etc). It seemed wasteful and poorly designed. Another thing that bothers me (at least at work) was that it used rsync to update its tree, and rsync isn't allowed at work. (I know it's possible to change that, I just never got around to it.) On those fronts, Homebrew is far better. It utilizes OS X-given dependencies where possible, and it simlinks its installs into /usr/local/ so that there's no need to change your environment variables to start using Homebrew'ed apps. And, it uses Git for tree updates. The one bad thing about Homebrew, compared to MacPorts, is that its package tree is pretty sparse at the moment. But, I'm going to give it time, since it's still pretty new. I'm indifferent to Homebrew's Ruby-based recipes, since I'm not fluent in Ruby... but apparently making new recipes is pretty easy for those packages it's missing. One troubling thing is that Homebrew and MacPorts don't completely coexist peacefully. In fact, the Homebrew folks won't support you unless MacPorts and Fink are gone. All in all, though, I'm pretty pleased with Homebrew. It's clean and easy to use, it integrates well with OS X dependencies and default paths, and it's easy to include new apps. Also, it's beer-themed, which is entertaining.

Now... all that being said... if Homebrew's install of Boost doesn't work and MacPorts' does..... I might need to rethink my choices....

-dustin