no good way to export 3rd party software libraries with workers

Description

If i have a 3rd party worker library either a .a or a .so that i want to build against i have to put the library down into the core (/opencpi/lib/target-my-target-gpp)

in order to have an exportable library we need a way to put these libraries to link against in the worker or library itself. something like

-component_lib
---worker1.rcc
---worker2.hdl
---specs
---rcc_lib
------include
------lib

Environment

None

Activity

Show:
James Kulp
May 21, 2015, 12:28 PM

There are three cases here.
1. A truly "third party library" dependency, where we do not export it, but we put the dependency into the worker's Makefile and expect the user to install it in the standard way (e.g. yum install xxx-devel etc.).

2. A primitive library that we simply want to build against, but statically within the worker binary file, where there
is no binary export issue, but there is a source export issue.

3. A primitive library that we want to export as a dynamic library to be dynamically loaded as workers are dynamically loaded.

James Kulp
April 12, 2017, 11:17 AM

The case of establishing prerequisite libraries for use by workers, either static or dynamic, is in 2017.Q1, and should be used in cases where the third party library has a well defined build process of its own. An example is the "liquid dsp" library, see scripts/install-liquid.sh.

The case RCC primitive libraries are not yet supported, where the source code in in an OpenCPI project, and it is built inside the project by the OpenCPI build engine.

Assignee

James Kulp

Reporter

Chris Hinkey

Labels

None

Components

Priority

Major
Configure