[Bug 507] New: import of /usr/ lib tries to import every lib instead of only ocl-ones

For more infomation about this bug, visit
Summary: import of /usr/lib tries to import every lib instead of
only ocl-ones
Product: OCL
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Deployment
AssignedTo: orocos-dev [..] ...
ReportedBy: ruben [dot] smits [..] ...
CC: orocos-dev [..] ...
Estimated Hours: 0.0

When i install my ocl-components in /usr/ (i guess that's where they will be
located when i install the debian packages) and i try to import /usr/lib in the
deployer, the deployer tries to load _every_ lib he finds in /usr/lib which are
a lot, taking 10's of minutes to start up.

I suggest to install the ocl-component libs in a smarter directory or let the
deployer only load ocl-related libs.

Ruben

[Bug 507] import of /usr/ lib tries to import every lib instead

For more infomation about this bug, visit

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

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

--- Comment #1 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-01-24 11:11:11 ---
(In reply to comment #0)
> When i install my ocl-components in /usr/ (i guess that's where they will be
> located when i install the debian packages) and i try to import /usr/lib in the
> deployer, the deployer tries to load _every_ lib he finds in /usr/lib which are
> a lot, taking 10's of minutes to start up.
>
> I suggest to install the ocl-component libs in a smarter directory or let the
> deployer only load ocl-related libs.

Import does exactly what it is supposed to do: recursively read libraries in a
directory. It can not know if a library is an Orocos component or not, until it
has loaded it. Hence, import of /usr/lib will always take a long time, and
possibly cause trouble.

The Debian guidelines say that you may place a library in a subdirectory of
/usr/lib if it is a 'plugin' or 'module' of an application. I guess an Orocos
component falls into this category. But not all OCL libraries contain
components, and not all components are loadable (for example, the taskbrowser
and the deployment component). So I'm not against a /usr/lib/[ocl|orocos] or
even an /usr/lib/ocl/lxrt directory, but it's unclear for me what to do with
the non loadable components and device driver libraries, which are used to link
against. A quick-and-dirty solution is to put the -L flag in the .pc file and
put all ocl libraries in a subdir of /usr/lib/.. but an import will
nevertheless load to many libraries...

Ruben Smits's picture

[Bug 507] import of /usr/ lib tries to import every lib instead

On Thursday January 24 2008 11:11:11 Peter Soetens wrote:
> For more infomation about this bug, visit
>
>
> Peter Soetens
<peter [dot] soetens [..] ...> changed:
>
> What |Removed |Added
> --------------------------------------------------------------------------
> Severity|major |normal
> CC| |peter [dot] soetens [..] ...
>
>
>
> --- Comment #1 from Peter Soetens
<peter [dot] soetens [..] ...> 2008-01-24
> 11:11:11 --- (In reply to comment #0)
>
> > When i install my ocl-components in /usr/ (i guess that's where they will
> > be located when i install the debian packages) and i try to import
> > /usr/lib in the deployer, the deployer tries to load _every_ lib he finds
> > in /usr/lib which are a lot, taking 10's of minutes to start up.
> >
> > I suggest to install the ocl-component libs in a smarter directory or let
> > the deployer only load ocl-related libs.
>
> Import does exactly what it is supposed to do: recursively read libraries
> in a directory. It can not know if a library is an Orocos component or not,
> until it has loaded it. Hence, import of /usr/lib will always take a long
> time, and possibly cause trouble.
>
> The Debian guidelines say that you may place a library in a subdirectory of
> /usr/lib if it is a 'plugin' or 'module' of an application. I guess an
> Orocos component falls into this category. But not all OCL libraries
> contain components, and not all components are loadable (for example, the
> taskbrowser and the deployment component). So I'm not against a
> /usr/lib/[ocl|orocos] or even an /usr/lib/ocl/lxrt directory, but it's
> unclear for me what to do with the non loadable components and device
> driver libraries, which are used to link against. A quick-and-dirty
> solution is to put the -L flag in the .pc file and put all ocl libraries in
> a subdir of /usr/lib/.. but an import will nevertheless load to many
> libraries...

And why is it so hard to install only the deployable components in
/usr/lib/subdir and all other in /usr/lib ???

Ruben

> --
> Configure bugmail:
> https://www.fmtc.be/bugzilla/orocos/userprefs.cgi?tab=email ------- You are
> receiving this mail because: -------
> You are on the CC list for the bug.
> You are the assignee for the bug.