Before reading the wiki I didn't setup log4cpp categories so my component
doesn't want to configure (logically). But executing was ok, and dynamic
linking was good
ard@ard-host-4:~/workspace/Core/target$ ldd ./bin/sandbox-core.ard | grep
log4
liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb6bb0000)
As stated in the wiki I added these lines in the beginning of the main in
order to makes logging working :
> log4cpp::HierarchyMaintainer::set_category_factory(
> OCL::logging::Category::createOCLCategory);
>
>
But after adding these lines, my exec is broken, dynamic linking goes wrong.
ldd shows 2 relations to log4cpp and I don't know why :
ard@ard-host-4:~/workspace/Core/target$ ldd ./bin/sandbox-core.ard | grep
log4
liblog4cpp.so.4 => not found
liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb6bb0000)
Have you ever had this ?
Using real time Log4cpp out of a deployer
On Oct 28, 2010, at 12:28 , Willy Lambert wrote:
> Before reading the wiki I didn't setup log4cpp categories so my component doesn't want to configure (logically). But executing was ok, and dynamic linking was good
> ard@ard-host-4:~/workspace/Core/target$ ldd ./bin/sandbox-core.ard | grep log4
> liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb6bb0000)
>
>
> As stated in the wiki I added these lines in the beginning of the main in order to makes logging working :
> log4cpp::HierarchyMaintainer::set_category_factory(
> OCL::logging::Category::createOCLCategory);
>
>
> But after adding these lines, my exec is broken, dynamic linking goes wrong. ldd shows 2 relations to log4cpp and I don't know why :
>
> ard@ard-host-4:~/workspace/Core/target$ ldd ./bin/sandbox-core.ard | grep log4
> liblog4cpp.so.4 => not found
> liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb6bb0000)
>
> Have you ever had this ?
No, though I've not tried with v2 (OCL won't compile for me). Is your custom built log4cpp at /usr/local/lib? The one built from the project on gitorious?
Do you have the standard log4cpp installed? Is it possible the build is confused and trying to pick up both the standard and custom libraries?
S
Using real time Log4cpp out of a deployer
My try is on v2.1. I have checkout the custom log4cpp from gitorious (from
the link in the wiki) in the autoproj toolchain (besides ocl and rtt
folders), when into it and run "./configure && make install" . So it is
installed on the default location (/usr/local/lib)
I didn't meant to install the standard log4cpp, but if i've done it by
mistake do you have a way to check this ? where is it installed by default ?
But anyway, I have other orocos projects working well with the custom
log4cpp when I use the standard deployer. It's just my unit tests that need
a personnal executable and manual initialization of Orocos that seems to
cause troubles. It's during this executable link that I have problems AND
ONLY if I add this line
log4cpp::HierarchyMaintainer::
set_category_factory(
OCL::logging::Category::createOCLCategory);
2010/10/29 S Roderick <kiwi [dot] net [..] ...>
> On Oct 28, 2010, at 12:28 , Willy Lambert wrote:
>
> Before reading the wiki I didn't setup log4cpp categories so my component
> doesn't want to configure (logically). But executing was ok, and dynamic
> linking was good
> ard@ard-host-4:~/workspace/Core/target$ ldd ./bin/sandbox-core.ard | grep
> log4
> liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb6bb0000)
>
>
> As stated in the wiki I added these lines in the beginning of the main in
> order to makes logging working :
>
>> log4cpp::HierarchyMaintainer::set_category_factory(
>> OCL::logging::Category::createOCLCategory);
>>
>>
>
> But after adding these lines, my exec is broken, dynamic linking goes
> wrong. ldd shows 2 relations to log4cpp and I don't know why :
>
> ard@ard-host-4:~/workspace/Core/target$ ldd ./bin/sandbox-core.ard | grep
> log4
> liblog4cpp.so.4 => not found
> liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb6bb0000)
>
> Have you ever had this ?
>
>
> No, though I've not tried with v2 (OCL won't compile for me). Is your
> custom built log4cpp at /usr/local/lib? The one built from the project on
> gitorious?
>
> Do you have the standard log4cpp installed? Is it possible the build is
> confused and trying to pick up both the standard and custom libraries?
> S
>
>
Using real time Log4cpp out of a deployer
On Oct 31, 2010, at 11:45 , Willy Lambert wrote:
> My try is on v2.1. I have checkout the custom log4cpp from gitorious (from the link in the wiki) in the autoproj toolchain (besides ocl and rtt folders), when into it and run "./configure && make install" . So it is installed on the default location (/usr/local/lib)
>
> I didn't meant to install the standard log4cpp, but if i've done it by mistake do you have a way to check this ? where is it installed by default ?
Most likely /usr/lib
> But anyway, I have other orocos projects working well with the custom log4cpp when I use the standard deployer. It's just my unit tests that need a personnal executable and manual initialization of Orocos that seems to cause troubles. It's during this executable link that I have problems AND ONLY if I add this line
>
> log4cpp::HierarchyMaintainer::
> set_category_factory(
> OCL::logging::Category::createOCLCategory);
Ok, so your system config sounds reasonable if the standard deployer works. How are you linking your unit test? Are you using the same CMake logic as ocl/bin/CMakeLists.txt? The above line uses functionality that is _only_ in the custom log4cpp, so I am still wondering about the link mixing libraries.
Can you post the output of "VERBOSE=1 make" for your unit test (remove the unit test executable first).
S
PS: You will also need to initialize the default TLSF memory pool if using real-time logging. You are doing that also, right?
Using real time Log4cpp out of a deployer
I don't have anything in /usr/lib for log4cpp.
What I forgot to precise and may have it's importance is that I didn't
choose the
- RTT from http://github.com/snrkiwi/orocos-rtt/tree/next-rtlogging
- OCL from http://github.com/snrkiwi/orocos-ocl/tree/next-logging
branches for Orocos but the standard 2.1 where I changed default CMake
options to match :
rtt
_ OS_RT_MALLOC = ON
_ OS_RT_MALLOC_SBRK = OFF
_ OS_RT_MALLOC_MMAP = OFF
ocl
_ BUILD_LOGGING = ON
Until now, I kept this rtt v2.1 "nature" branches because they are
"standard" and my logging was working.
Enclosed my make result. They are identical with and without the "custom
logging function". It's noticable that I link twice my executable I will
correct this. I mainly link with ocl and rtt components and librairies.
P.S.1 : I do not know anything about TLSF, so if I have to do something that
was not in the wiki, for sure I did not initialized it (because I don't know
how to do it).
PS2 : here is my exec code (utest_ARDTaskContext.ard)
#include "ARDTaskContext.hpp"
> #define BOOST_TEST_DYN_LINK
> #define BOOST_TEST_MODULE uTest_ARDTaskContext
> #include <boost/test/unit_test.hp
> #include <rtt/os/startstop.h>
> #include <rtt/extras/SimulationThread.hp
> #include <rtt/extras/SimulationActivity.hp
>
> #include <log4cpp/HierarchyMaintainer.hh>
>
> using namespace Core;
> using namespace std;
> using namespace RTT;
> using namespace RTT::detail;
> using namespace RTT::extras;
>
> BOOST_AUTO_TEST_CASE( uTest_ARDTaskContext )
> {
> // sets environment if not set by user.
> setenv("RTT_COMPONENT_PATH","../rtt", 0);
>
> //init du logging, à faire AVANT l'os init
> cerr << "Setting OCL factory for real-time logging" << endl;
>
> //log4cpp::HierarchyMaintainer::set_category_factory(OCL::logging::Category::createOCLCategory);
>
> __os_init(0,NULL);
>
>
>
> ARDTaskContext component("component");
> SimulationActivity activity(0.01);
>
>
> //component.setActivity()
>
>
> BOOST_CHECK( component.start() );
>
>
>
>
>
> __os_exit();
>
> log4cpp::HierarchyMaintainer::getDefaultMaintainer().shutdown();
>
> log4cpp::HierarchyMaintainer::getDefaultMaintainer().deleteAllCategories();
>
> }
>
2010/10/31 Stephen Roderick <kiwi [dot] net [..] ...>
> On Oct 31, 2010, at 11:45 , Willy Lambert wrote:
>
> > My try is on v2.1. I have checkout the custom log4cpp from gitorious
> (from the link in the wiki) in the autoproj toolchain (besides ocl and rtt
> folders), when into it and run "./configure && make install" . So it is
> installed on the default location (/usr/local/lib)
> >
> > I didn't meant to install the standard log4cpp, but if i've done it by
> mistake do you have a way to check this ? where is it installed by default ?
>
> Most likely /usr/lib
>
> > But anyway, I have other orocos projects working well with the custom
> log4cpp when I use the standard deployer. It's just my unit tests that need
> a personnal executable and manual initialization of Orocos that seems to
> cause troubles. It's during this executable link that I have problems AND
> ONLY if I add this line
> >
> > log4cpp::HierarchyMaintainer::
> > set_category_factory(
> > OCL::logging::Category::createOCLCategory);
>
> Ok, so your system config sounds reasonable if the standard deployer works.
> How are you linking your unit test? Are you using the same CMake logic as
> ocl/bin/CMakeLists.txt? The above line uses functionality that is _only_ in
> the custom log4cpp, so I am still wondering about the link mixing libraries.
>
> Can you post the output of "VERBOSE=1 make" for your unit test (remove the
> unit test executable first).
>
> S
>
> PS: You will also need to initialize the default TLSF memory pool if using
> real-time logging. You are doing that also, right?
>
Using real time Log4cpp out of a deployer
On Nov 1, 2010, at 13:29 , Willy Lambert wrote:
> I don't have anything in /usr/lib for log4cpp.
>
> What I forgot to precise and may have it's importance is that I didn't choose the
> RTT from http://github.com/snrkiwi/orocos-rtt/tree/next-rtlogging
> OCL from http://github.com/snrkiwi/orocos-ocl/tree/next-logging
> branches for Orocos but the standard 2.1 where I changed default CMake options to match :
> rtt
> _ OS_RT_MALLOC = ON
> _ OS_RT_MALLOC_SBRK = OFF
> _ OS_RT_MALLOC_MMAP = OFF
> ocl
> _ BUILD_LOGGING = ON
>
> Until now, I kept this rtt v2.1 "nature" branches because they are "standard" and my logging was working.
I _think_ that will be ok, but I've never tried this. Not sure if anyone else has actually built/run any real-time logging v2 programs/components?
> Enclosed my make result. They are identical with and without the "custom logging function". It's noticable that I link twice my executable I will correct this. I mainly link with ocl and rtt components and librairies.
Definitely fix the double link, that might causes issues. What does "ldd" give on the "orocos-logging-gnulinux" library?
> P.S.1 : I do not know anything about TLSF, so if I have to do something that was not in the wiki, for sure I did not initialized it (because I don't know how to do it).
See the initialization code in ocl/bin/deployer.cpp
> PS2 : here is my exec code (utest_ARDTaskContext.ard)
>
> #include "ARDTaskContext.hpp"
> #define BOOST_TEST_DYN_LINK
> #define BOOST_TEST_MODULE uTest_ARDTaskContext
> #include <boost/test/unit_test.hp
> #include <rtt/os/startstop.h>
> #include <rtt/extras/SimulationThread.hp
> #include <rtt/extras/SimulationActivity.hp
>
> #include <log4cpp/HierarchyMaintainer.hh>
>
> using namespace Core;
> using namespace std;
> using namespace RTT;
> using namespace RTT::detail;
> using namespace RTT::extras;
>
> BOOST_AUTO_TEST_CASE( uTest_ARDTaskContext )
> {
> // sets environment if not set by user.
> setenv("RTT_COMPONENT_PATH","../rtt", 0);
>
> //init du logging, à faire AVANT l'os init
> cerr << "Setting OCL factory for real-time logging" << endl;
> //log4cpp::HierarchyMaintainer::set_category_factory(OCL::logging::Category::createOCLCategory);
>
> __os_init(0,NULL);
>
>
>
> ARDTaskContext component("component");
> SimulationActivity activity(0.01);
>
>
> //component.setActivity()
>
>
> BOOST_CHECK( component.start() );
>
>
>
>
>
> __os_exit();
>
> log4cpp::HierarchyMaintainer::getDefaultMaintainer().shutdown();
> log4cpp::HierarchyMaintainer::getDefaultMaintainer().deleteAllCategories();
>
> }
That should work.
S
Using real time Log4cpp out of a deployer
2010/11/1 Stephen Roderick <kiwi [dot] net [..] ...>
>
> On Nov 1, 2010, at 13:29 , Willy Lambert wrote:
>
> I don't have anything in /usr/lib for log4cpp.
>
> What I forgot to precise and may have it's importance is that I didn't
> choose the
>
> - RTT from http://github.com/snrkiwi/orocos-rtt/tree/next-rtlogging
> - OCL from http://github.com/snrkiwi/orocos-ocl/tree/next-logging
>
> branches for Orocos but the standard 2.1 where I changed default CMake
> options to match :
> rtt
> _ OS_RT_MALLOC = ON
> _ OS_RT_MALLOC_SBRK = OFF
> _ OS_RT_MALLOC_MMAP = OFF
> ocl
> _ BUILD_LOGGING = ON
>
> Until now, I kept this rtt v2.1 "nature" branches because they are
> "standard" and my logging was working.
>
>
> I _think_ that will be ok, but I've never tried this. Not sure if anyone
> else has actually built/run any real-time logging v2 programs/components?
>
> Enclosed my make result. They are identical with and without the "custom
> logging function". It's noticable that I link twice my executable I will
> correct this. I mainly link with ocl and rtt components and librairies.
>
>
> Definitely fix the double link, that might causes issues. What does "ldd"
> give on the "orocos-logging-gnulinux" library?
>
ard@ard-host-4:/opt/orocos2/install/lib/orocos$ ldd
liborocos-logging-gnulinux.so
linux-gate.so.1 => (0xb77ae000)
liborocos-rtt-gnulinux.so.2.1 =>
/opt/orocos2/install/lib/liborocos-rtt-gnulinux.so.2.1 (0xb75be000)
liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb7580000)
libboost_filesystem.so.1.42.0 => /usr/lib/libboost_filesystem.so.1.42.0
(0xb7559000)
libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0
(0xb7555000)
libboost_serialization.so.1.42.0 =>
/usr/lib/libboost_serialization.so.1.42.0 (0xb74e3000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb74ca000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb74c1000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb74bc000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb73c7000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb73a1000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7383000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb723d000)
libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7225000)
/lib/ld-linux.so.2 (0xb77af000)
ard@ard-host-4:/opt/orocos2/install/lib/orocos$
>
> P.S.1 : I do not know anything about TLSF, so if I have to do something
> that was not in the wiki, for sure I did not initialized it (because I don't
> know how to do it).
>
>
> See the initialization code in ocl/bin/deployer.cpp
>
I'm working around this, I'll tell you the result
>
> PS2 : here is my exec code (utest_ARDTaskContext.ard)
>
> #include "ARDTaskContext.hpp"
>> #define BOOST_TEST_DYN_LINK
>> #define BOOST_TEST_MODULE uTest_ARDTaskContext
>> #include <boost/test/unit_test.hp
>> #include <rtt/os/startstop.h>
>> #include <rtt/extras/SimulationThread.hp
>> #include <rtt/extras/SimulationActivity.hp
>>
>> #include <log4cpp/HierarchyMaintainer.hh>
>>
>> using namespace Core;
>> using namespace std;
>> using namespace RTT;
>> using namespace RTT::detail;
>> using namespace RTT::extras;
>>
>> BOOST_AUTO_TEST_CASE( uTest_ARDTaskContext )
>> {
>> // sets environment if not set by user.
>> setenv("RTT_COMPONENT_PATH","../rtt", 0);
>>
>> //init du logging, à faire AVANT l'os init
>> cerr << "Setting OCL factory for real-time logging" << endl;
>>
>> //log4cpp::HierarchyMaintainer::set_category_factory(OCL::logging::Category::createOCLCategory);
>>
>> __os_init(0,NULL);
>>
>>
>>
>> ARDTaskContext component("component");
>> SimulationActivity activity(0.01);
>>
>>
>> //component.setActivity()
>>
>>
>> BOOST_CHECK( component.start() );
>>
>>
>>
>>
>>
>> __os_exit();
>>
>> log4cpp::HierarchyMaintainer::getDefaultMaintainer().shutdown();
>>
>> log4cpp::HierarchyMaintainer::getDefaultMaintainer().deleteAllCategories();
>>
>> }
>>
>
> That should work.
> S
>
>
Using real time Log4cpp out of a deployer
On Nov 1, 2010, at 14:55 , Willy Lambert wrote:
>
>
> 2010/11/1 Stephen Roderick <kiwi [dot] net [..] ...>
>
> On Nov 1, 2010, at 13:29 , Willy Lambert wrote:
>
>> I don't have anything in /usr/lib for log4cpp.
>>
>> What I forgot to precise and may have it's importance is that I didn't choose the
>> RTT from http://github.com/snrkiwi/orocos-rtt/tree/next-rtlogging
>> OCL from http://github.com/snrkiwi/orocos-ocl/tree/next-logging
>> branches for Orocos but the standard 2.1 where I changed default CMake options to match :
>> rtt
>> _ OS_RT_MALLOC = ON
>> _ OS_RT_MALLOC_SBRK = OFF
>> _ OS_RT_MALLOC_MMAP = OFF
>> ocl
>> _ BUILD_LOGGING = ON
>>
>> Until now, I kept this rtt v2.1 "nature" branches because they are "standard" and my logging was working.
>
> I _think_ that will be ok, but I've never tried this. Not sure if anyone else has actually built/run any real-time logging v2 programs/components?
>
>> Enclosed my make result. They are identical with and without the "custom logging function". It's noticable that I link twice my executable I will correct this. I mainly link with ocl and rtt components and librairies.
>
> Definitely fix the double link, that might causes issues. What does "ldd" give on the "orocos-logging-gnulinux" library?
>
> ard@ard-host-4:/opt/orocos2/install/lib/orocos$ ldd liborocos-logging-gnulinux.so
> linux-gate.so.1 => (0xb77ae000)
> liborocos-rtt-gnulinux.so.2.1 => /opt/orocos2/install/lib/liborocos-rtt-gnulinux.so.2.1 (0xb75be000)
> liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb7580000)
> libboost_filesystem.so.1.42.0 => /usr/lib/libboost_filesystem.so.1.42.0 (0xb7559000)
> libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0 (0xb7555000)
> libboost_serialization.so.1.42.0 => /usr/lib/libboost_serialization.so.1.42.0 (0xb74e3000)
> libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb74ca000)
> librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb74c1000)
> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb74bc000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb73c7000)
> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb73a1000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7383000)
> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb723d000)
> libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7225000)
> /lib/ld-linux.so.2 (0xb77af000)
> ard@ard-host-4:/opt/orocos2/install/lib/orocos$
That looks fine, which makes me wonder more about that double link.
>
>> P.S.1 : I do not know anything about TLSF, so if I have to do something that was not in the wiki, for sure I did not initialized it (because I don't know how to do it).
>
> See the initialization code in ocl/bin/deployer.cpp
>
> I'm working around this, I'll tell you the result
How? OCL logging _requires_ TLSF. If you don't initialize the default memory pool, you'll get a std::bad_allcoc exception.
S
Using real time Log4cpp out of a deployer
2010/11/1 Stephen Roderick <kiwi [dot] net [..] ...>
> On Nov 1, 2010, at 14:55 , Willy Lambert wrote:
>
>
>
> 2010/11/1 Stephen Roderick <kiwi [dot] net [..] ...>
>
>>
>> On Nov 1, 2010, at 13:29 , Willy Lambert wrote:
>>
>> I don't have anything in /usr/lib for log4cpp.
>>
>> What I forgot to precise and may have it's importance is that I didn't
>> choose the
>>
>> - RTT from http://github.com/snrkiwi/orocos-rtt/tree/next-rtlogging
>> - OCL from http://github.com/snrkiwi/orocos-ocl/tree/next-logging
>>
>> branches for Orocos but the standard 2.1 where I changed default CMake
>> options to match :
>> rtt
>> _ OS_RT_MALLOC = ON
>> _ OS_RT_MALLOC_SBRK = OFF
>> _ OS_RT_MALLOC_MMAP = OFF
>> ocl
>> _ BUILD_LOGGING = ON
>>
>> Until now, I kept this rtt v2.1 "nature" branches because they are
>> "standard" and my logging was working.
>>
>>
>> I _think_ that will be ok, but I've never tried this. Not sure if anyone
>> else has actually built/run any real-time logging v2 programs/components?
>>
>> Enclosed my make result. They are identical with and without the "custom
>> logging function". It's noticable that I link twice my executable I will
>> correct this. I mainly link with ocl and rtt components and librairies.
>>
>>
>> Definitely fix the double link, that might causes issues. What does "ldd"
>> give on the "orocos-logging-gnulinux" library?
>>
>
> ard@ard-host-4:/opt/orocos2/install/lib/orocos$ ldd
> liborocos-logging-gnulinux.so
> linux-gate.so.1 => (0xb77ae000)
> liborocos-rtt-gnulinux.so.2.1 =>
> /opt/orocos2/install/lib/liborocos-rtt-gnulinux.so.2.1 (0xb75be000)
> liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb7580000)
> libboost_filesystem.so.1.42.0 => /usr/lib/libboost_filesystem.so.1.42.0
> (0xb7559000)
> libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0
> (0xb7555000)
> libboost_serialization.so.1.42.0 =>
> /usr/lib/libboost_serialization.so.1.42.0 (0xb74e3000)
> libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb74ca000)
> librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb74c1000)
> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb74bc000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb73c7000)
> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb73a1000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7383000)
> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb723d000)
> libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7225000)
> /lib/ld-linux.so.2 (0xb77af000)
> ard@ard-host-4:/opt/orocos2/install/lib/orocos$
>
>
> That looks fine, which makes me wonder more about that double link.
>
>
>> P.S.1 : I do not know anything about TLSF, so if I have to do something
>> that was not in the wiki, for sure I did not initialized it (because I don't
>> know how to do it).
>>
>>
>> See the initialization code in ocl/bin/deployer.cpp
>>
>
> I'm working around this, I'll tell you the result
>
>
> How? OCL logging _requires_ TLSF. If you don't initialize the default
> memory pool, you'll get a std::bad_allcoc exception.
> S
>
>
>
Sorry I wasn't clear : I added TLSF initialisation to my init code.
Using real time Log4cpp out of a deployer
Here is the ldd on my exec :
ard@ard-host-4:~/workspace/Core/target$ ldd bin/utest_ARDTaskContext.ard
linux-gate.so.1 => (0xb783a000)
libarp-core.so => /home/ard/workspace/Core/target/lib/libarp-core.so
(0xb75aa000)
liborocos-rtt-gnulinux.so.2.1 =>
/opt/orocos2/install/lib/liborocos-rtt-gnulinux.so.2.1 (0xb7442000)
librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7426000)
liborocos-logging-gnulinux.so.2.1 =>
/opt/orocos2/install/lib/orocos/liborocos-logging-gnulinux.so.2.1
(0xb73a0000)
liborocos-deployment-corba-gnulinux.so.2.1 =>
/opt/orocos2/install/lib/liborocos-deployment-corba-gnulinux.so.2.1
(0xb7376000)
liborocos-deployment-gnulinux.so.2.1 =>
/opt/orocos2/install/lib/liborocos-deployment-gnulinux.so.2.1 (0xb7237000)
liborocos-reporting-gnulinux.so.2.1 =>
/opt/orocos2/install/lib/orocos/liborocos-reporting-gnulinux.so.2.1
(0xb71af000)
liborocos-timer-gnulinux.so.2.1 =>
/opt/orocos2/install/lib/orocos/liborocos-timer-gnulinux.so.2.1 (0xb7110000)
liborocos-taskbrowser-gnulinux.so.2.1 =>
/opt/orocos2/install/lib/liborocos-taskbrowser-gnulinux.so.2.1 (0xb70df000)
liborocos-ocl-common-gnulinux.so.2.1 =>
/opt/orocos2/install/lib/orocos/liborocos-ocl-common-gnulinux.so.2.1
(0xb6f48000)
libboost_unit_test_framework.so.1.42.0 =>
/usr/lib/libboost_unit_test_framework.so.1.42.0 (0xb6e9a000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6da4000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb6d7e000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d60000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6c1a000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb6c01000)
* liblog4cpp.so.4 => not found*
libboost_filesystem.so.1.42.0 => /usr/lib/libboost_filesystem.so.1.42.0
(0xb6bed000)
libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0
(0xb6be9000)
libboost_serialization.so.1.42.0 =>
/usr/lib/libboost_serialization.so.1.42.0 (0xb6b77000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6b73000)
/lib/ld-linux.so.2 (0xb783b000)
* liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb6b34000)*
liborocos-rtt-corba-gnulinux.so.2.1 =>
/opt/orocos2/install/lib/liborocos-rtt-corba-gnulinux.so.2.1 (0xb6a44000)
librtt-marshalling-gnulinux.so.2.1.0 =>
/opt/orocos2/install/lib/orocos/plugins/librtt-marshalling-gnulinux.so.2.1.0
(0xb69b4000)
librtt-scripting-gnulinux.so.2.1.0 =>
/opt/orocos2/install/lib/orocos/plugins/librtt-scripting-gnulinux.so.2.1.0
(0xb65ff000)
libomniORB4.so.1 => /usr/lib/libomniORB4.so.1 (0xb6479000)
libomniDynamic4.so.1 => /usr/lib/libomniDynamic4.so.1 (0xb6237000)
libomnithread.so.3 => /usr/lib/libomnithread.so.3 (0xb6231000)
libreadline.so.5 => /lib/libreadline.so.5 (0xb61fe000)
libncurses.so.5 => /lib/libncurses.so.5 (0xb61c4000)
libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb61ac000)
2010/11/1 Willy Lambert <lambert [dot] willy [..] ...>
>
>
> 2010/11/1 Stephen Roderick <kiwi [dot] net [..] ...>
>
>> On Nov 1, 2010, at 14:55 , Willy Lambert wrote:
>>
>>
>>
>> 2010/11/1 Stephen Roderick <kiwi [dot] net [..] ...>
>>
>>>
>>> On Nov 1, 2010, at 13:29 , Willy Lambert wrote:
>>>
>>> I don't have anything in /usr/lib for log4cpp.
>>>
>>> What I forgot to precise and may have it's importance is that I didn't
>>> choose the
>>>
>>> - RTT from http://github.com/snrkiwi/orocos-rtt/tree/next-rtlogging
>>> - OCL from http://github.com/snrkiwi/orocos-ocl/tree/next-logging
>>>
>>> branches for Orocos but the standard 2.1 where I changed default CMake
>>> options to match :
>>> rtt
>>> _ OS_RT_MALLOC = ON
>>> _ OS_RT_MALLOC_SBRK = OFF
>>> _ OS_RT_MALLOC_MMAP = OFF
>>> ocl
>>> _ BUILD_LOGGING = ON
>>>
>>> Until now, I kept this rtt v2.1 "nature" branches because they are
>>> "standard" and my logging was working.
>>>
>>>
>>> I _think_ that will be ok, but I've never tried this. Not sure if anyone
>>> else has actually built/run any real-time logging v2 programs/components?
>>>
>>> Enclosed my make result. They are identical with and without the "custom
>>> logging function". It's noticable that I link twice my executable I will
>>> correct this. I mainly link with ocl and rtt components and librairies.
>>>
>>>
>>> Definitely fix the double link, that might causes issues. What does "ldd"
>>> give on the "orocos-logging-gnulinux" library?
>>>
>>
>> ard@ard-host-4:/opt/orocos2/install/lib/orocos$ ldd
>> liborocos-logging-gnulinux.so
>> linux-gate.so.1 => (0xb77ae000)
>> liborocos-rtt-gnulinux.so.2.1 =>
>> /opt/orocos2/install/lib/liborocos-rtt-gnulinux.so.2.1 (0xb75be000)
>> liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb7580000)
>> libboost_filesystem.so.1.42.0 =>
>> /usr/lib/libboost_filesystem.so.1.42.0 (0xb7559000)
>> libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0
>> (0xb7555000)
>> libboost_serialization.so.1.42.0 =>
>> /usr/lib/libboost_serialization.so.1.42.0 (0xb74e3000)
>> libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb74ca000)
>> librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb74c1000)
>> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb74bc000)
>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb73c7000)
>> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb73a1000)
>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7383000)
>> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb723d000)
>> libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7225000)
>> /lib/ld-linux.so.2 (0xb77af000)
>> ard@ard-host-4:/opt/orocos2/install/lib/orocos$
>>
>>
>> That looks fine, which makes me wonder more about that double link.
>>
>>
>>> P.S.1 : I do not know anything about TLSF, so if I have to do something
>>> that was not in the wiki, for sure I did not initialized it (because I don't
>>> know how to do it).
>>>
>>>
>>> See the initialization code in ocl/bin/deployer.cpp
>>>
>>
>> I'm working around this, I'll tell you the result
>>
>>
>> How? OCL logging _requires_ TLSF. If you don't initialize the default
>> memory pool, you'll get a std::bad_allcoc exception.
>> S
>>
>>
>>
> Sorry I wasn't clear : I added TLSF initialisation to my init code.
>
>
>
>
>
Using real time Log4cpp out of a deployer
I corrected dual linking but it did not change anything :(
2010/11/1 Willy Lambert <lambert [dot] willy [..] ...>
> Here is the ldd on my exec :
>
> ard@ard-host-4:~/workspace/Core/target$ ldd bin/utest_ARDTaskContext.ard
> linux-gate.so.1 => (0xb783a000)
> libarp-core.so => /home/ard/workspace/Core/target/lib/libarp-core.so
> (0xb75aa000)
> liborocos-rtt-gnulinux.so.2.1 =>
> /opt/orocos2/install/lib/liborocos-rtt-gnulinux.so.2.1 (0xb7442000)
> librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7426000)
> liborocos-logging-gnulinux.so.2.1 =>
> /opt/orocos2/install/lib/orocos/liborocos-logging-gnulinux.so.2.1
> (0xb73a0000)
> liborocos-deployment-corba-gnulinux.so.2.1 =>
> /opt/orocos2/install/lib/liborocos-deployment-corba-gnulinux.so.2.1
> (0xb7376000)
> liborocos-deployment-gnulinux.so.2.1 =>
> /opt/orocos2/install/lib/liborocos-deployment-gnulinux.so.2.1 (0xb7237000)
> liborocos-reporting-gnulinux.so.2.1 =>
> /opt/orocos2/install/lib/orocos/liborocos-reporting-gnulinux.so.2.1
> (0xb71af000)
> liborocos-timer-gnulinux.so.2.1 =>
> /opt/orocos2/install/lib/orocos/liborocos-timer-gnulinux.so.2.1 (0xb7110000)
> liborocos-taskbrowser-gnulinux.so.2.1 =>
> /opt/orocos2/install/lib/liborocos-taskbrowser-gnulinux.so.2.1 (0xb70df000)
> liborocos-ocl-common-gnulinux.so.2.1 =>
> /opt/orocos2/install/lib/orocos/liborocos-ocl-common-gnulinux.so.2.1
> (0xb6f48000)
> libboost_unit_test_framework.so.1.42.0 =>
> /usr/lib/libboost_unit_test_framework.so.1.42.0 (0xb6e9a000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6da4000)
> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb6d7e000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d60000)
> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6c1a000)
> libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb6c01000)
>
> * liblog4cpp.so.4 => not found*
> libboost_filesystem.so.1.42.0 => /usr/lib/libboost_filesystem.so.1.42.0
> (0xb6bed000)
> libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0
> (0xb6be9000)
> libboost_serialization.so.1.42.0 =>
> /usr/lib/libboost_serialization.so.1.42.0 (0xb6b77000)
> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6b73000)
> /lib/ld-linux.so.2 (0xb783b000)
> * liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb6b34000)*
> liborocos-rtt-corba-gnulinux.so.2.1 =>
> /opt/orocos2/install/lib/liborocos-rtt-corba-gnulinux.so.2.1 (0xb6a44000)
> librtt-marshalling-gnulinux.so.2.1.0 =>
> /opt/orocos2/install/lib/orocos/plugins/librtt-marshalling-gnulinux.so.2.1.0
> (0xb69b4000)
> librtt-scripting-gnulinux.so.2.1.0 =>
> /opt/orocos2/install/lib/orocos/plugins/librtt-scripting-gnulinux.so.2.1.0
> (0xb65ff000)
> libomniORB4.so.1 => /usr/lib/libomniORB4.so.1 (0xb6479000)
> libomniDynamic4.so.1 => /usr/lib/libomniDynamic4.so.1 (0xb6237000)
> libomnithread.so.3 => /usr/lib/libomnithread.so.3 (0xb6231000)
> libreadline.so.5 => /lib/libreadline.so.5 (0xb61fe000)
> libncurses.so.5 => /lib/libncurses.so.5 (0xb61c4000)
> libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb61ac000)
>
>
>
>
>
> 2010/11/1 Willy Lambert <lambert [dot] willy [..] ...>
>
>
>>
>> 2010/11/1 Stephen Roderick <kiwi [dot] net [..] ...>
>>
>>> On Nov 1, 2010, at 14:55 , Willy Lambert wrote:
>>>
>>>
>>>
>>> 2010/11/1 Stephen Roderick <kiwi [dot] net [..] ...>
>>>
>>>>
>>>> On Nov 1, 2010, at 13:29 , Willy Lambert wrote:
>>>>
>>>> I don't have anything in /usr/lib for log4cpp.
>>>>
>>>> What I forgot to precise and may have it's importance is that I didn't
>>>> choose the
>>>>
>>>> - RTT from http://github.com/snrkiwi/orocos-rtt/tree/next-rtlogging
>>>> - OCL from http://github.com/snrkiwi/orocos-ocl/tree/next-logging
>>>>
>>>> branches for Orocos but the standard 2.1 where I changed default CMake
>>>> options to match :
>>>> rtt
>>>> _ OS_RT_MALLOC = ON
>>>> _ OS_RT_MALLOC_SBRK = OFF
>>>> _ OS_RT_MALLOC_MMAP = OFF
>>>> ocl
>>>> _ BUILD_LOGGING = ON
>>>>
>>>> Until now, I kept this rtt v2.1 "nature" branches because they are
>>>> "standard" and my logging was working.
>>>>
>>>>
>>>> I _think_ that will be ok, but I've never tried this. Not sure if anyone
>>>> else has actually built/run any real-time logging v2 programs/components?
>>>>
>>>> Enclosed my make result. They are identical with and without the "custom
>>>> logging function". It's noticable that I link twice my executable I will
>>>> correct this. I mainly link with ocl and rtt components and librairies.
>>>>
>>>>
>>>> Definitely fix the double link, that might causes issues. What does
>>>> "ldd" give on the "orocos-logging-gnulinux" library?
>>>>
>>>
>>> ard@ard-host-4:/opt/orocos2/install/lib/orocos$ ldd
>>> liborocos-logging-gnulinux.so
>>> linux-gate.so.1 => (0xb77ae000)
>>> liborocos-rtt-gnulinux.so.2.1 =>
>>> /opt/orocos2/install/lib/liborocos-rtt-gnulinux.so.2.1 (0xb75be000)
>>> liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb7580000)
>>> libboost_filesystem.so.1.42.0 =>
>>> /usr/lib/libboost_filesystem.so.1.42.0 (0xb7559000)
>>> libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0
>>> (0xb7555000)
>>> libboost_serialization.so.1.42.0 =>
>>> /usr/lib/libboost_serialization.so.1.42.0 (0xb74e3000)
>>> libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb74ca000)
>>> librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb74c1000)
>>> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb74bc000)
>>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb73c7000)
>>> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb73a1000)
>>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7383000)
>>> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb723d000)
>>> libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7225000)
>>> /lib/ld-linux.so.2 (0xb77af000)
>>> ard@ard-host-4:/opt/orocos2/install/lib/orocos$
>>>
>>>
>>> That looks fine, which makes me wonder more about that double link.
>>>
>>>
>>>> P.S.1 : I do not know anything about TLSF, so if I have to do something
>>>> that was not in the wiki, for sure I did not initialized it (because I don't
>>>> know how to do it).
>>>>
>>>>
>>>> See the initialization code in ocl/bin/deployer.cpp
>>>>
>>>
>>> I'm working around this, I'll tell you the result
>>>
>>>
>>> How? OCL logging _requires_ TLSF. If you don't initialize the default
>>> memory pool, you'll get a std::bad_allcoc exception.
>>> S
>>>
>>>
>>>
>> Sorry I wasn't clear : I added TLSF initialisation to my init code.
>>
>>
>>
>>
>>
>
Using real time Log4cpp out of a deployer
On Nov 1, 2010, at 16:35 , Willy Lambert wrote:
> I corrected dual linking but it did not change anything :(
I've not see this before. Sorry .... only thing that I can think of is to turn on debugging output from the linker (ld), and try to see why it is bringing in log4cpp twice. Also, does your LD_LIBRARY_PATH include /usr/local/lib?
S
> 2010/11/1 Willy Lambert <lambert [dot] willy [..] ...>
> Here is the ldd on my exec :
>
> ard@ard-host-4:~/workspace/Core/target$ ldd bin/utest_ARDTaskContext.ard
> linux-gate.so.1 => (0xb783a000)
> libarp-core.so => /home/ard/workspace/Core/target/lib/libarp-core.so (0xb75aa000)
> liborocos-rtt-gnulinux.so.2.1 => /opt/orocos2/install/lib/liborocos-rtt-gnulinux.so.2.1 (0xb7442000)
> librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7426000)
> liborocos-logging-gnulinux.so.2.1 => /opt/orocos2/install/lib/orocos/liborocos-logging-gnulinux.so.2.1 (0xb73a0000)
> liborocos-deployment-corba-gnulinux.so.2.1 => /opt/orocos2/install/lib/liborocos-deployment-corba-gnulinux.so.2.1 (0xb7376000)
> liborocos-deployment-gnulinux.so.2.1 => /opt/orocos2/install/lib/liborocos-deployment-gnulinux.so.2.1 (0xb7237000)
> liborocos-reporting-gnulinux.so.2.1 => /opt/orocos2/install/lib/orocos/liborocos-reporting-gnulinux.so.2.1 (0xb71af000)
> liborocos-timer-gnulinux.so.2.1 => /opt/orocos2/install/lib/orocos/liborocos-timer-gnulinux.so.2.1 (0xb7110000)
> liborocos-taskbrowser-gnulinux.so.2.1 => /opt/orocos2/install/lib/liborocos-taskbrowser-gnulinux.so.2.1 (0xb70df000)
> liborocos-ocl-common-gnulinux.so.2.1 => /opt/orocos2/install/lib/orocos/liborocos-ocl-common-gnulinux.so.2.1 (0xb6f48000)
> libboost_unit_test_framework.so.1.42.0 => /usr/lib/libboost_unit_test_framework.so.1.42.0 (0xb6e9a000)
> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6da4000)
> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb6d7e000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d60000)
> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6c1a000)
> libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb6c01000)
>
> liblog4cpp.so.4 => not found
> libboost_filesystem.so.1.42.0 => /usr/lib/libboost_filesystem.so.1.42.0 (0xb6bed000)
> libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0 (0xb6be9000)
> libboost_serialization.so.1.42.0 => /usr/lib/libboost_serialization.so.1.42.0 (0xb6b77000)
> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6b73000)
> /lib/ld-linux.so.2 (0xb783b000)
> liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb6b34000)
> liborocos-rtt-corba-gnulinux.so.2.1 => /opt/orocos2/install/lib/liborocos-rtt-corba-gnulinux.so.2.1 (0xb6a44000)
> librtt-marshalling-gnulinux.so.2.1.0 => /opt/orocos2/install/lib/orocos/plugins/librtt-marshalling-gnulinux.so.2.1.0 (0xb69b4000)
> librtt-scripting-gnulinux.so.2.1.0 => /opt/orocos2/install/lib/orocos/plugins/librtt-scripting-gnulinux.so.2.1.0 (0xb65ff000)
> libomniORB4.so.1 => /usr/lib/libomniORB4.so.1 (0xb6479000)
> libomniDynamic4.so.1 => /usr/lib/libomniDynamic4.so.1 (0xb6237000)
> libomnithread.so.3 => /usr/lib/libomnithread.so.3 (0xb6231000)
> libreadline.so.5 => /lib/libreadline.so.5 (0xb61fe000)
> libncurses.so.5 => /lib/libncurses.so.5 (0xb61c4000)
> libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb61ac000)
Using real time Log4cpp out of a deployer
2010/11/1 Stephen Roderick <kiwi [dot] net [..] ...>
> On Nov 1, 2010, at 16:35 , Willy Lambert wrote:
>
> I corrected dual linking but it did not change anything :(
>
>
> I've not see this before. Sorry .... only thing that I can think of is to
> turn on debugging output from the linker (ld), and try to see why it is
> bringing in log4cpp twice. Also, does your LD_LIBRARY_PATH include
> /usr/local/lib?
> S
>
>
It was not ! And it was not because it is not in env.sh and I forgot to add
it. And ***it works*** now with this. Thanks for your time.
What is surprising is that it sometimes find it alone (classical deployer or
during the second link) ... I think there is something behind all this.
> 2010/11/1 Willy Lambert <lambert [dot] willy [..] ...>
>
>> Here is the ldd on my exec :
>>
>> ard@ard-host-4:~/workspace/Core/target$ ldd bin/utest_ARDTaskContext.ard
>> linux-gate.so.1 => (0xb783a000)
>> libarp-core.so => /home/ard/workspace/Core/target/lib/libarp-core.so
>> (0xb75aa000)
>> liborocos-rtt-gnulinux.so.2.1 =>
>> /opt/orocos2/install/lib/liborocos-rtt-gnulinux.so.2.1 (0xb7442000)
>> librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7426000)
>> liborocos-logging-gnulinux.so.2.1 =>
>> /opt/orocos2/install/lib/orocos/liborocos-logging-gnulinux.so.2.1
>> (0xb73a0000)
>> liborocos-deployment-corba-gnulinux.so.2.1 =>
>> /opt/orocos2/install/lib/liborocos-deployment-corba-gnulinux.so.2.1
>> (0xb7376000)
>> liborocos-deployment-gnulinux.so.2.1 =>
>> /opt/orocos2/install/lib/liborocos-deployment-gnulinux.so.2.1 (0xb7237000)
>> liborocos-reporting-gnulinux.so.2.1 =>
>> /opt/orocos2/install/lib/orocos/liborocos-reporting-gnulinux.so.2.1
>> (0xb71af000)
>> liborocos-timer-gnulinux.so.2.1 =>
>> /opt/orocos2/install/lib/orocos/liborocos-timer-gnulinux.so.2.1 (0xb7110000)
>> liborocos-taskbrowser-gnulinux.so.2.1 =>
>> /opt/orocos2/install/lib/liborocos-taskbrowser-gnulinux.so.2.1 (0xb70df000)
>> liborocos-ocl-common-gnulinux.so.2.1 =>
>> /opt/orocos2/install/lib/orocos/liborocos-ocl-common-gnulinux.so.2.1
>> (0xb6f48000)
>> libboost_unit_test_framework.so.1.42.0 =>
>> /usr/lib/libboost_unit_test_framework.so.1.42.0 (0xb6e9a000)
>> libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6da4000)
>> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb6d7e000)
>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d60000)
>> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6c1a000)
>> libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb6c01000)
>>
>> * liblog4cpp.so.4 => not found*
>> libboost_filesystem.so.1.42.0 =>
>> /usr/lib/libboost_filesystem.so.1.42.0 (0xb6bed000)
>> libboost_system.so.1.42.0 => /usr/lib/libboost_system.so.1.42.0
>> (0xb6be9000)
>> libboost_serialization.so.1.42.0 =>
>> /usr/lib/libboost_serialization.so.1.42.0 (0xb6b77000)
>> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb6b73000)
>> /lib/ld-linux.so.2 (0xb783b000)
>> * liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0xb6b34000)*
>> liborocos-rtt-corba-gnulinux.so.2.1 =>
>> /opt/orocos2/install/lib/liborocos-rtt-corba-gnulinux.so.2.1 (0xb6a44000)
>> librtt-marshalling-gnulinux.so.2.1.0 =>
>> /opt/orocos2/install/lib/orocos/plugins/librtt-marshalling-gnulinux.so.2.1.0
>> (0xb69b4000)
>> librtt-scripting-gnulinux.so.2.1.0 =>
>> /opt/orocos2/install/lib/orocos/plugins/librtt-scripting-gnulinux.so.2.1.0
>> (0xb65ff000)
>> libomniORB4.so.1 => /usr/lib/libomniORB4.so.1 (0xb6479000)
>> libomniDynamic4.so.1 => /usr/lib/libomniDynamic4.so.1 (0xb6237000)
>> libomnithread.so.3 => /usr/lib/libomnithread.so.3 (0xb6231000)
>> libreadline.so.5 => /lib/libreadline.so.5 (0xb61fe000)
>> libncurses.so.5 => /lib/libncurses.so.5 (0xb61c4000)
>> libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb61ac000)
>>
>
>