Deploying an Orogen component from the OCL Deployer
| Submitted by Charles Lesire-... on Fri, 2012-11-23 06:49 |
Hi,
I have created an Orogen component and I try to deploy it with the OCL
Deployer.
The component is correctly loaded, but its associated typekit is not!
For instance, with the MessageProducer component (from the first Rock
tutorials), the deployer complains that:
~/work/rock$ deployer-gnulinux
0.102 [ ERROR ][DeploymentComponent::configure] Could not load library
'/home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so':
0.103 [ ERROR ][DeploymentComponent::configure]
/home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so:
undefined symbol: _ZN11omni_thread6init_tD1Ev
0.174 [ ERROR ][DeploymentComponent::configure] could not load library
'/home/lesire/work/rock/install/lib/orocos/types/libmessage_producer-typekit-gnulinux.so':
/home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so:
undefined symbol: _ZN11omni_thread6init_tD1Ev
And then the message_procuder types and unknown.
The symbol is not defined because the typekit does not link to any omniorb
library, which is a good thing anyway!
Any idea how to fix it?
Charles.
Deploying an Orogen component from the OCL Deployer
On 11/23/2012 07:49 AM, Charles Lesire-Cabaniols wrote:
> /home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so:
> undefined symbol: _ZN11omni_thread6init_tD1Ev
Don't know if it is related but it seems familiar to me :
See thread [Orocos-Dev] regression on master for orogen + xenomai on Lucid (only)
See bug 979 : http://orocos.org/forum/rtt/rtt-dev/bug-979-new-add-taskcontext-factory-...
And
https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
https://fedoraproject.org/wiki/UnderstandingDSOLinkChange
[Rock-dev] Deploying an Orogen component from the OCL Deployer
On 11/23/2012 07:49 AM, Charles Lesire-Cabaniols wrote:
> Hi,
>
> I have created an Orogen component and I try to deploy it with the OCL
> Deployer.
> The component is correctly loaded, but its associated typekit is not!
>
> For instance, with the MessageProducer component (from the first Rock
> tutorials), the deployer complains that:
>
> ~/work/rock$ deployer-gnulinux
> 0.102 [ ERROR ][DeploymentComponent::configure] Could not load
> library
> '/home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so':
> 0.103 [ ERROR ][DeploymentComponent::configure]
> /home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so:
> undefined symbol: _ZN11omni_thread6init_tD1Ev
> 0.174 [ ERROR ][DeploymentComponent::configure] could not load
> library
> '/home/lesire/work/rock/install/lib/orocos/types/libmessage_producer-typekit-gnulinux.so':
> /home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so:
> undefined symbol: _ZN11omni_thread6init_tD1Ev
>
> And then the message_procuder types and unknown.
>
> The symbol is not defined because the typekit does not link to any
> omniorb library, which is a good thing anyway!
>
> Any idea how to fix it?
Two issues here:
- the deployer tries to load the port_proxy tasks. Are you actually
trying to really load it ? Can you check whether
message_producer-tasks-gnulinux links to port_proxy-tasks-gnulinux ?
- the port_proxy tasks should link to corba libraries because,
unfortunately, "someone" decided to add some corba name resolution stuff
in there (/me takes his big fluffy hammer and goes to friendly hit that
"someone").
[Rock-dev] Deploying an Orogen component from the OCL Deployer
On Fri, Nov 23, 2012 at 10:23 AM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...>wrote:
> On 11/23/2012 07:49 AM, Charles Lesire-Cabaniols wrote:
> > Hi,
> >
> > I have created an Orogen component and I try to deploy it with the OCL
> > Deployer.
> > The component is correctly loaded, but its associated typekit is not!
> >
> > For instance, with the MessageProducer component (from the first Rock
> > tutorials), the deployer complains that:
> >
> > ~/work/rock$ deployer-gnulinux
> > 0.102 [ ERROR ][DeploymentComponent::configure] Could not load
> > library
> >
> '/home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so':
> > 0.103 [ ERROR ][DeploymentComponent::configure]
> >
> /home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so:
> > undefined symbol: _ZN11omni_thread6init_tD1Ev
> > 0.174 [ ERROR ][DeploymentComponent::configure] could not load
> > library
> >
> '/home/lesire/work/rock/install/lib/orocos/types/libmessage_producer-typekit-gnulinux.so':
> >
> /home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so:
> > undefined symbol: _ZN11omni_thread6init_tD1Ev
> >
> > And then the message_procuder types and unknown.
> >
> > The symbol is not defined because the typekit does not link to any
> > omniorb library, which is a good thing anyway!
> >
> > Any idea how to fix it?
> Two issues here:
> - the deployer tries to load the port_proxy tasks. Are you actually
> trying to really load it ? Can you check whether
> message_producer-tasks-gnulinux links to port_proxy-tasks-gnulinux ?
> - the port_proxy tasks should link to corba libraries because,
> unfortunately, "someone" decided to add some corba name resolution stuff
> in there (/me takes his big fluffy hammer and goes to friendly hit that
> "someone").
>
There was a similar issue with the TaskContextProxy/Server headers in rtt,
pulling in omniorb symbols. We accepted a patch to create a rtt header
which won't cause the client to include corba headers and hence don't link
with the omniorb libraries, but only to the orocos-rtt-corba library. As
such, client code was free of the specific corba implementation.
Would that work here too ?
Peter
[Rock-dev] Deploying an Orogen component from the OCL Deployer
On 11/23/2012 11:56 AM, Peter Soetens wrote:
>
> There was a similar issue with the TaskContextProxy/Server headers in
> rtt, pulling in omniorb symbols. We accepted a patch to create a rtt
> header which won't cause the client to include corba headers and hence
> don't link with the omniorb libraries, but only to the
> orocos-rtt-corba library. As such, client code was free of the
> specific corba implementation.
>
> Would that work here too ?
Could, but would not fix the actual issue: message_producer should still
be available even though the port_proxy library cannot be loaded.
As I understand it, the issue was that message_producer was linking to
port_proxy ... which it should definitely not do.
[Rock-dev] Deploying an Orogen component from the OCL Deployer
Now, after rebuild everything, I still have the port_proxy related error,
but the message_producer libraries loads correctly.
$ deployer-gnulinux 0.204 [ ERROR ][DeploymentComponent::configure] Could
not load library
'/home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so':
0.204 [ ERROR ][DeploymentComponent::configure]
/home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so:
undefined symbol: _ZN11omni_thread6init_tD1Ev
0.387 [ ERROR ][TypekitRepository::Import] A protocol with id 2 was
already added for type /message_driver/Message
Switched to : Deployer
The message_driver / message_procuder types are correctly loaded and
understood by the Deployer.
However, all the basic RTT types are unknown:
Deployer [S]> 3
= (unknown_t)
Deployer [S]> true
= (unknown_t)
2012/11/23 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 11/23/2012 11:56 AM, Peter Soetens wrote:
>
>>
>> There was a similar issue with the TaskContextProxy/Server headers in
>> rtt, pulling in omniorb symbols. We accepted a patch to create a rtt header
>> which won't cause the client to include corba headers and hence don't link
>> with the omniorb libraries, but only to the orocos-rtt-corba library. As
>> such, client code was free of the specific corba implementation.
>>
>> Would that work here too ?
>>
> Could, but would not fix the actual issue: message_producer should still
> be available even though the port_proxy library cannot be loaded.
>
> As I understand it, the issue was that message_producer was linking to
> port_proxy ... which it should definitely not do.
>
>
> --
> Sylvain Joyeux (Dr.Ing.)
> Senior Researcher
>
> Space & Security Robotics
> Underwater Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> ------------------------------**------------------------------**
> -----------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> ------------------------------**------------------------------**
> -----------
>
>
[Rock-dev] Deploying an Orogen component from the OCL Deployer
On 11/23/2012 02:53 PM, Charles Lesire-Cabaniols wrote:
> Now, after rebuild everything, I still have the port_proxy related
> error, but the message_producer libraries loads correctly.
>
> $ deployer-gnulinux 0.204 [ ERROR ][DeploymentComponent::configure]
> Could not load library
> '/home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so':
> 0.204 [ ERROR ][DeploymentComponent::configure]
> /home/lesire/work/rock/install/lib/orocos/libport_proxy-tasks-gnulinux.so:
> undefined symbol: _ZN11omni_thread6init_tD1Ev
> 0.387 [ ERROR ][TypekitRepository::Import] A protocol with id 2 was
> already added for type /message_driver/Message
> Switched to : Deployer
>
> The message_driver / message_procuder types are correctly loaded and
> understood by the Deployer.
>
> However, all the basic RTT types are unknown:
>
> Deployer [S]> 3
> = (unknown_t)
>
> Deployer [S]> true
> = (unknown_t)
You did compile with "OCL compatibility" to ON, right ?
In principle, oroGen / typeGen does NOT touch the base types, only adds
transports to them. So I don't really know what is going on. Could you
have a look at how RTT got configured (cmake line in
install/logs/rtt-configure.log) and send that ?
[Rock-dev] Deploying an Orogen component from the OCL Deployer
2012/11/23 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 11/23/2012 02:53 PM, Charles Lesire-Cabaniols wrote:
>
>> Now, after rebuild everything, I still have the port_proxy related error,
>> but the message_producer libraries loads correctly.
>>
>> $ deployer-gnulinux 0.204 [ ERROR ][DeploymentComponent::**configure]
>> Could not load library '/home/lesire/work/rock/**
>> install/lib/orocos/libport_**proxy-tasks-gnulinux.so':
>> 0.204 [ ERROR ][DeploymentComponent::**configure]
>> /home/lesire/work/rock/**install/lib/orocos/libport_**proxy-tasks-gnulinux.so:
>> undefined symbol: _ZN11omni_thread6init_tD1Ev
>> 0.387 [ ERROR ][TypekitRepository::Import] A protocol with id 2 was
>> already added for type /message_driver/Message
>> Switched to : Deployer
>>
>> The message_driver / message_procuder types are correctly loaded and
>> understood by the Deployer.
>>
>> However, all the basic RTT types are unknown:
>>
>> Deployer [S]> 3
>> = (unknown_t)
>>
>> Deployer [S]> true
>> = (unknown_t)
>>
> You did compile with "OCL compatibility" to ON, right ?
>
Yes. USE_OCL = true in my config.yml file.
>
> In principle, oroGen / typeGen does NOT touch the base types, only adds
> transports to them. So I don't really know what is going on. Could you have
> a look at how RTT got configured (cmake line in install/logs/rtt-configure.
> **log) and send that ?
cmake -DCMAKE_INSTALL_PREFIX=/home/lesire/work/rock/install
-DCMAKE_MODULE_PATH=/home/lesire/work/rock/base/types/cmake
-DDEFAULT_PLUGIN_PATH=/ -DBUILD_TESTING=OFF -DPLUGINS_ENABLE_SCRIPTING=ON
-DENABLE_CORBA=YES -DCORBA_IMPLEMENTATION=OMNIORB
-DCMAKE_BUILD_TYPE=Release -DOROCOS_TARGET=gnulinux
/home/lesire/work/rock/tools/rtt
IMO, the issue is that the deployer finds something in install/lib/orocos
(which is my RTT_COMPONENT_PATH), and then does not go to look at
install/lib/orocos/gnulinux, where the rtt typekit is. In another
'pure-orocos' install (i.e. without Rock), I have nothing directly in
install/lib/orocos. Libs are either in gnulinux/ or in types/.
A partial view of my install tree (built with Rock) is below:
$ tree install/lib/orocos/
install/lib/orocos/
??? gnulinux
? ??? ocl
? ? ??? liborocos-ocl-common-gnulinux.so ->
liborocos-ocl-common-gnulinux.so.2.3.2
? ? ??? (...)
? ? ??? plugins
? ? ? ??? libos-gnulinux.so -> libos-gnulinux.so.2.3.2
? ? ? ??? libos-gnulinux.so.2.3.2
? ? ? ??? libprint-gnulinux.so -> libprint-gnulinux.so.2.3.2
? ? ? ??? libprint-gnulinux.so.2.3.2
? ? ??? types
? ? ??? libocl-gnulinux.so -> libocl-gnulinux.so.2.3.2
? ? ??? libocl-gnulinux.so.2.3.2
? ??? plugins
? ? ??? librtt-marshalling-gnulinux.so ->
librtt-marshalling-gnulinux.so.2.5.0
? ? ??? librtt-marshalling-gnulinux.so.2.5.0
? ? ??? librtt-scripting-gnulinux.so ->
librtt-scripting-gnulinux.so.2.5.0
? ? ??? librtt-scripting-gnulinux.so.2.5.0
? ??? types
? ??? (...)
? ??? librtt-typekit-gnulinux.so -> librtt-typekit-gnulinux.so.2.5.0
? ??? librtt-typekit-gnulinux.so.2.5.0
??? liblogger-tasks-gnulinux.so
??? libmessage_producer-tasks-gnulinux.so
??? libport_proxy-tasks-gnulinux.so
??? libtransformer-tasks-gnulinux.so
??? types
??? libaggregator-transport-corba-gnulinux.so
??? libaggregator-transport-mqueue-gnulinux.so
??? libaggregator-transport-typelib-gnulinux.so
??? libaggregator-typekit-gnulinux.so
??? libbase-transport-corba-gnulinux.so
??? libbase-transport-mqueue-gnulinux.so
??? libbase-transport-typelib-gnulinux.so
??? libbase-typekit-gnulinux.so
??? liblogger-transport-corba-gnulinux.so
??? liblogger-transport-mqueue-gnulinux.so
??? liblogger-transport-typelib-gnulinux.so
??? liblogger-typekit-gnulinux.so
??? libmessage_producer-transport-corba-gnulinux.so
??? libmessage_producer-transport-mqueue-gnulinux.so
??? libmessage_producer-transport-typelib-gnulinux.so
??? libmessage_producer-typekit-gnulinux.so
??? libport_proxy-transport-corba-gnulinux.so
??? libport_proxy-transport-mqueue-gnulinux.so
??? libport_proxy-transport-typelib-gnulinux.so
??? libport_proxy-typekit-gnulinux.so
??? libtransformer-transport-corba-gnulinux.so
??? libtransformer-transport-mqueue-gnulinux.so
??? libtransformer-transport-typelib-gnulinux.so
??? libtransformer-typekit-gnulinux.so
>
>
> --
> Sylvain Joyeux (Dr.Ing.)
> Senior Researcher
>
> Space & Security Robotics
> Underwater Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> ------------------------------**------------------------------**
> -----------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> ------------------------------**------------------------------**
> -----------
>
>
[Rock-dev] Deploying an Orogen component from the OCL Deployer
On 11/23/2012 03:29 PM, Charles Lesire-Cabaniols wrote:
> IMO, the issue is that the deployer finds something in
> install/lib/orocos (which is my RTT_COMPONENT_PATH), and then does not
> go to look at install/lib/orocos/gnulinux, where the rtt typekit is.
> In another 'pure-orocos' install (i.e. without Rock), I have nothing
> directly in install/lib/orocos. Libs are either in gnulinux/ or in types/.
I would need a comment from the OCL developers here ... In principle, I
have nothing against changing oroGen/typeGen to install in gnulinux/ if
that fixes this issue (and is more in line with the "normal" flow).
[Rock-dev] Deploying an Orogen component from the OCL Deployer
2012/11/23 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 11/23/2012 03:29 PM, Charles Lesire-Cabaniols wrote:
> > IMO, the issue is that the deployer finds something in
> > install/lib/orocos (which is my RTT_COMPONENT_PATH), and then does not
> > go to look at install/lib/orocos/gnulinux, where the rtt typekit is.
> > In another 'pure-orocos' install (i.e. without Rock), I have nothing
> > directly in install/lib/orocos. Libs are either in gnulinux/ or in
> types/.
> I would need a comment from the OCL developers here ... In principle, I
> have nothing against changing oroGen/typeGen to install in gnulinux/ if
> that fixes this issue (and is more in line with the "normal" flow).
>
>
This dir may also be "xenomai" or something similar when building different
flavor at the same time. So you have several dirs (gnulinux, xenomai) each
containing libXXX-gnulinux.so or libXXX-xenomai.so
> --
> Sylvain Joyeux (Dr.Ing.)
> Senior Researcher
>
> Space & Security Robotics
> Underwater Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> -----------------------------------------------------------------------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> -----------------------------------------------------------------------
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev [..] ...
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
[Rock-dev] Deploying an Orogen component from the OCL Deployer
On 11/23/2012 03:50 PM, Willy Lambert wrote:
>
>
> 2012/11/23 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
> <mailto:sylvain [dot] joyeux [..] ...>>
>
> On 11/23/2012 03:29 PM, Charles Lesire-Cabaniols wrote:
> > IMO, the issue is that the deployer finds something in
> > install/lib/orocos (which is my RTT_COMPONENT_PATH), and then
> does not
> > go to look at install/lib/orocos/gnulinux, where the rtt typekit is.
> > In another 'pure-orocos' install (i.e. without Rock), I have nothing
> > directly in install/lib/orocos. Libs are either in gnulinux/ or
> in types/.
> I would need a comment from the OCL developers here ... In
> principle, I
> have nothing against changing oroGen/typeGen to install in
> gnulinux/ if
> that fixes this issue (and is more in line with the "normal" flow).
>
>
> This dir may also be "xenomai" or something similar when building
> different flavor at the same time. So you have several dirs (gnulinux,
> xenomai) each containing libXXX-gnulinux.so or libXXX-xenomai.so
Yes, I know. I also have to admit that I did not follow the overall
discussions when this transition has been made. Since we actually have
now the OS both in the folder *and* the shared library name. A bit
redundant. So I assumed that the current way oroGen does it was fine.
I'd like to know if Charles' analysis is right and that it *is* why it
currently does not work.
Sylvain
[Rock-dev] Deploying an Orogen component from the OCL Deployer
Op vrijdag 23 november 2012 schreef Sylvain Joyeux (sylvain [dot] joyeux [..] ...)
het volgende:
> On 11/23/2012 03:50 PM, Willy Lambert wrote:
>
>
>
> 2012/11/23 Sylvain Joyeux <sylvain [dot] joyeux [..] ...
>
>> On 11/23/2012 03:29 PM, Charles Lesire-Cabaniols wrote:
>> > IMO, the issue is that the deployer finds something in
>> > install/lib/orocos (which is my RTT_COMPONENT_PATH), and then does not
>> > go to look at install/lib/orocos/gnulinux, where the rtt typekit is.
>> > In another 'pure-orocos' install (i.e. without Rock), I have nothing
>> > directly in install/lib/orocos. Libs are either in gnulinux/ or in
>> types/.
>> I would need a comment from the OCL developers here ... In principle, I
>> have nothing against changing oroGen/typeGen to install in gnulinux/ if
>> that fixes this issue (and is more in line with the "normal" flow).
>>
>>
> This dir may also be "xenomai" or something similar when building
> different flavor at the same time. So you have several dirs (gnulinux,
> xenomai) each containing libXXX-gnulinux.so or libXXX-xenomai.so
>
> Yes, I know. I also have to admit that I did not follow the overall
> discussions when this transition has been made. Since we actually have now
> the OS both in the folder *and* the shared library name. A bit redundant.
> So I assumed that the current way oroGen does it was fine. I'd like to know
> if Charles' analysis is right and that it *is* why it currently does not
> work
>
Turning on the logger at Debug level will reveal why it skips certain files
or directories.
It's true that files can be skipped if a certain subdirectory is found or
vice versa. I also agree that the filename encoding and directory structure
are redundant. actually, the deployer no longer interpretes the filename
and only uses directory names to look for the OROCOS_TARGET. So you can
omit the -gnulinux suffix of the filename with respect to the deployer.
Peter
>
>
[Rock-dev] Deploying an Orogen component from the OCL Deployer
Hi Charles,
On Tue, Nov 27, 2012 at 6:39 PM, Charles Lesire-Cabaniols
<charles [dot] lesire [..] ...> wrote:
>
>
>
> 2012/11/23 Peter Soetens <peter [..] ...>
>>
>>
>>
>> Op vrijdag 23 november 2012 schreef Sylvain Joyeux
>> (sylvain [dot] joyeux [..] ...) het volgende:
>>
>>> On 11/23/2012 03:50 PM, Willy Lambert wrote:
>>>
>>>
>>>
>>> 2012/11/23 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
>>>>
>>>> On 11/23/2012 03:29 PM, Charles Lesire-Cabaniols wrote:
>>>> > IMO, the issue is that the deployer finds something in
>>>> > install/lib/orocos (which is my RTT_COMPONENT_PATH), and then does not
>>>> > go to look at install/lib/orocos/gnulinux, where the rtt typekit is.
>>>> > In another 'pure-orocos' install (i.e. without Rock), I have nothing
>>>> > directly in install/lib/orocos. Libs are either in gnulinux/ or in
>>>> > types/.
>>>> I would need a comment from the OCL developers here ... In principle, I
>>>> have nothing against changing oroGen/typeGen to install in gnulinux/ if
>>>> that fixes this issue (and is more in line with the "normal" flow).
>>>>
>>>
>>> This dir may also be "xenomai" or something similar when building
>>> different flavor at the same time. So you have several dirs (gnulinux,
>>> xenomai) each containing libXXX-gnulinux.so or libXXX-xenomai.so
>>>
>>> Yes, I know. I also have to admit that I did not follow the overall
>>> discussions when this transition has been made. Since we actually have now
>>> the OS both in the folder *and* the shared library name. A bit redundant. So
>>> I assumed that the current way oroGen does it was fine. I'd like to know if
>>> Charles' analysis is right and that it *is* why it currently does not work
>>
>>
>> Turning on the logger at Debug level will reveal why it skips certain
>> files or directories.
>
>
> The log in attached
The log only says that 'gnulinux' is not a file :-)
Why didn't you upgrade your OCL to 2.5 ? I'm not saying the bug is
fixed there, but I do know that there have been fixes along the way.
Peter
[Rock-dev] Deploying an Orogen component from the OCL Deployer
2012/11/27 Peter Soetens <peter [..] ...>
> Hi Charles,
>
> On Tue, Nov 27, 2012 at 6:39 PM, Charles Lesire-Cabaniols
> <charles [dot] lesire [..] ...> wrote:
> >
> >
> >
> > 2012/11/23 Peter Soetens <peter [..] ...>
> >>
> >>
> >>
> >> Op vrijdag 23 november 2012 schreef Sylvain Joyeux
> >> (sylvain [dot] joyeux [..] ...) het volgende:
> >>
> >>> On 11/23/2012 03:50 PM, Willy Lambert wrote:
> >>>
> >>>
> >>>
> >>> 2012/11/23 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> >>>>
> >>>> On 11/23/2012 03:29 PM, Charles Lesire-Cabaniols wrote:
> >>>> > IMO, the issue is that the deployer finds something in
> >>>> > install/lib/orocos (which is my RTT_COMPONENT_PATH), and then does
> not
> >>>> > go to look at install/lib/orocos/gnulinux, where the rtt typekit is.
> >>>> > In another 'pure-orocos' install (i.e. without Rock), I have nothing
> >>>> > directly in install/lib/orocos. Libs are either in gnulinux/ or in
> >>>> > types/.
> >>>> I would need a comment from the OCL developers here ... In principle,
> I
> >>>> have nothing against changing oroGen/typeGen to install in gnulinux/
> if
> >>>> that fixes this issue (and is more in line with the "normal" flow).
> >>>>
> >>>
> >>> This dir may also be "xenomai" or something similar when building
> >>> different flavor at the same time. So you have several dirs (gnulinux,
> >>> xenomai) each containing libXXX-gnulinux.so or libXXX-xenomai.so
> >>>
> >>> Yes, I know. I also have to admit that I did not follow the overall
> >>> discussions when this transition has been made. Since we actually have
> now
> >>> the OS both in the folder *and* the shared library name. A bit
> redundant. So
> >>> I assumed that the current way oroGen does it was fine. I'd like to
> know if
> >>> Charles' analysis is right and that it *is* why it currently does not
> work
> >>
> >>
> >> Turning on the logger at Debug level will reveal why it skips certain
> >> files or directories.
> >
> >
> > The log in attached
>
> The log only says that 'gnulinux' is not a file :-)
>
> Why didn't you upgrade your OCL to 2.5 ? I'm not saying the bug is
> fixed there, but I do know that there have been fixes along the way.
>
I have started from scratch a new install using the Rock bootstrap with OCL
turned on; I haven't even checked the OCL version that is downloaded by
Rock actually... and you will have to wait till Thursday before giving you
the actual OCL branch I am on ;)
>
> Peter
>
[Rock-dev] Deploying an Orogen component from the OCL Deployer
Ah ... I replied to Markus but not to you, Charles
Rock was indeed on 2.3. I've updated the branch, so it should now
checkout 2.5 on Rock's next and stable and master on master.
[Rock-dev] Deploying an Orogen component from the OCL Deployer
2012/11/23 Sylvain Joyeux <sylvain [dot] joyeux [..] ...>
> On 11/23/2012 07:49 AM, Charles Lesire-Cabaniols wrote:
>
>> Hi,
>>
>> I have created an Orogen component and I try to deploy it with the OCL
>> Deployer.
>> The component is correctly loaded, but its associated typekit is not!
>>
>> For instance, with the MessageProducer component (from the first Rock
>> tutorials), the deployer complains that:
>>
>> ~/work/rock$ deployer-gnulinux
>> 0.102 [ ERROR ][DeploymentComponent::**configure] Could not load
>> library '/home/lesire/work/rock/**install/lib/orocos/libport_**
>> proxy-tasks-gnulinux.so':
>> 0.103 [ ERROR ][DeploymentComponent::**configure]
>> /home/lesire/work/rock/**install/lib/orocos/libport_**proxy-tasks-gnulinux.so:
>> undefined symbol: _ZN11omni_thread6init_tD1Ev
>> 0.174 [ ERROR ][DeploymentComponent::**configure] could not load
>> library '/home/lesire/work/rock/**install/lib/orocos/types/**
>> libmessage_producer-typekit-**gnulinux.so': /home/lesire/work/rock/**
>> install/lib/orocos/libport_**proxy-tasks-gnulinux.so: undefined symbol:
>> _ZN11omni_thread6init_tD1Ev
>>
>> And then the message_procuder types and unknown.
>>
>> The symbol is not defined because the typekit does not link to any
>> omniorb library, which is a good thing anyway!
>>
>> Any idea how to fix it?
>>
> Two issues here:
> - the deployer tries to load the port_proxy tasks. Are you actually
> trying to really load it ? Can you check whether message_producer-tasks-**gnulinux
> links to port_proxy-tasks-gnulinux ?
>
I just starts the deployer... port_proxy is within the default
RTT_COMPONENT_PATH as it is installed in lib/orocos.
I checked that message_producer-tasks-gnulinux was linked to
port_proxy-tasks-gnulinux just before sending my first email... since then,
I added others rock packages to my current layout, everything has been
rebuilt, and now it is not linked anymore :\ and hence the last deployer
error message disappeared!
> - the port_proxy tasks should link to corba libraries because,
> unfortunately, "someone" decided to add some corba name resolution stuff in
> there (/me takes his big fluffy hammer and goes to friendly hit that
> "someone").
>
And then, can I hope this to be fixed soon?
>
> --
> Sylvain Joyeux (Dr.Ing.)
> Senior Researcher
>
> Space & Security Robotics
> Underwater Robotics
>
> !!! Achtung, neue Telefonnummer!!!
>
> Standort Bremen:
> DFKI GmbH
> Robotics Innovation Center
> Robert-Hooke-Straße 5
> 28359 Bremen, Germany
>
> Phone: +49 (0)421 178-454136
> Fax: +49 (0)421 218-454150
> E-Mail: robotik [..] ...
>
> Weitere Informationen: http://www.dfki.de/robotik
> ------------------------------**------------------------------**
> -----------
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
> (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer: 19/673/0060/3
> ------------------------------**------------------------------**
> -----------
>
>