Ubuntu 19 Support
I'm trying to add Ubuntu 19.x support to OpenCPI. My procedure has been to
add the directory projects/core/rcc/platforms/ubuntu19 and the following
files:
- README
- ubuntu19-check.sh
- ubuntu19.mk
- ubuntu-packages.sh
I also needed to change some source files due to updated GCC warnings
turning into errors, specifically:
- os/interfaces/include/OcpiOsEther.h
- runtime/dataplane/transport/impl/include/OcpiInputBuffer.h
- runtime/util/property/include/OcpiPValueApi.h
- runtime/util/property/src/OcpiUtilPValue.cxx
I also had to change the kernel module to have a different return type to
get everything to build.
Unfortunately, when I try to perform a command to show me the installed
platforms, I get this error:
$ ocpidev show platforms
OCPI:ERROR: STDERR output from Make (set_vars_from_make):
/bin/sh: 1: Bad substitution
For platform configuration file alst4x_zipper_hsmc_alst4_port_a_rx: File
"alst4x_zipper_hsmc_alst4_port_a_rx" could not be opened for
reading/parsing. Files tried: alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/misc_comps/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/misc_comps/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/util_comps/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/util_comps/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/dsp_comps/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/dsp_comps/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/comms_comps/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/comms_comps/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/base_comps/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/base_comps/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../hdl/devices/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../hdl/devices/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../imports/ocpi.core/exports/lib/devices/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../imports/ocpi.core/exports/lib/devices/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../hdl/cards/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../hdl/cards/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../imports/ocpi.core/exports/lib/cards/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../imports/ocpi.core/exports/lib/components/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../imports/ocpi.core/exports/lib/components/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
alst4x_zipper_hsmc_alst4_port_a_rx.xml,
gen/alst4x_zipper_hsmc_alst4_port_a_rx.xml. CWD is
/home/bpadalino/projects/opencpi.git/projects/assets/hdl/platforms/alst4x
/home/bpadalino/projects/opencpi.git/cdk/include/hdl/hdl-platform.mk:199:
*** Processing platform configuration XML
"alst4x_zipper_hsmc_alst4_port_a_rx": . Stop.
OCPI:ERROR: The following make command returned an error:
make -n -r -s -C
/home/bpadalino/projects/opencpi.git/projects/assets/hdl/platforms/alst4x
ShellHdlPlatformVars=1 showpackage
I tried searching through the archives, but nothing popped out at me as a
solution.
Any idea what's happening?
Thanks,
Brian
Sometimes the framework/registry gests in a weird state like this i think
you have projects in your registry with bad imports/exports links. My next
step would be to do "ocpidev show registry" and re register each project
(ocpidev -d <project-dir> register project) which will re-create the
imports and exports in each project and try again.
I find this happens to me when switching between branches or doing cleans
but I'm not exactly sure what's going on.
On 12/5/19 4:56 PM, Brian Padalino wrote:
I'm trying to add Ubuntu 19.x support to OpenCPI.
Thanks!
My procedure has been to
add the directory projects/core/rcc/platforms/ubuntu19 and the following
files:
- README
- ubuntu19-check.sh
- ubuntu19.mk
- ubuntu-packages.sh
I also needed to change some source files due to updated GCC warnings
turning into errors, specifically:
- os/interfaces/include/OcpiOsEther.h
- runtime/dataplane/transport/impl/include/OcpiInputBuffer.h
- runtime/util/property/include/OcpiPValueApi.h
- runtime/util/property/src/OcpiUtilPValue.cxx
Note that you can usually just add a compiler flag that turns these
errors back into warnings so that you don't need to touch framework code
to get this job done. Its not a bad thing to "fix" that code if the
warnings are good, but it you can avoid a framework patch to get your
job done, that's better.
I also had to change the kernel module to have a different return type to
get everything to build.
Which kernel version did you end up with?
Is the default shell on that system bash? We sometimes end up assuming
bash when we shouldn't.
Chris is right, sometimes there are bootstrapping issues with adding new
software platforms where you have to do stuff to get the project exports
redone from the project that the new platform is in.
Unfortunately, when I try to perform a command to show me the installed
platforms, I get this error:
$ ocpidev show platforms
OCPI:ERROR: STDERR output from Make (set_vars_from_make):
/bin/sh: 1: Bad substitution
For platform configuration file alst4x_zipper_hsmc_alst4_port_a_rx: File
"alst4x_zipper_hsmc_alst4_port_a_rx" could not be opened for
reading/parsing. Files tried: alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/misc_comps/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/misc_comps/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/util_comps/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/util_comps/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/dsp_comps/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/dsp_comps/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/comms_comps/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/comms_comps/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/base_comps/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../components/base_comps/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../hdl/devices/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../hdl/devices/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../imports/ocpi.core/exports/lib/devices/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../imports/ocpi.core/exports/lib/devices/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../hdl/cards/lib/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../hdl/cards/lib/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../imports/ocpi.core/exports/lib/cards/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../imports/ocpi.core/exports/lib/components/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
./../../../imports/ocpi.core/exports/lib/components/hdl/alst4x_zipper_hsmc_alst4_port_a_rx.xml,
alst4x_zipper_hsmc_alst4_port_a_rx.xml,
gen/alst4x_zipper_hsmc_alst4_port_a_rx.xml. CWD is
/home/bpadalino/projects/opencpi.git/projects/assets/hdl/platforms/alst4x
/home/bpadalino/projects/opencpi.git/cdk/include/hdl/hdl-platform.mk:199:
*** Processing platform configuration XML
"alst4x_zipper_hsmc_alst4_port_a_rx": . Stop.
OCPI:ERROR: The following make command returned an error:
make -n -r -s -C
/home/bpadalino/projects/opencpi.git/projects/assets/hdl/platforms/alst4x
ShellHdlPlatformVars=1 showpackage
I tried searching through the archives, but nothing popped out at me as a
solution.
Any idea what's happening?
Thanks,
Brian
Hey Chris,
On Thu, Dec 5, 2019 at 5:06 PM Chris Hinkey chinkey@geontech.com wrote:
Sometimes the framework/registry gests in a weird state like this i think
you have projects in your registry with bad imports/exports links. My next
step would be to do "ocpidev show registry" and re register each project
(ocpidev -d <project-dir> register project) which will re-create the
imports and exports in each project and try again.
This is the output of showing my registry:
$ ocpidev show registry
Project registry is located at:
/home/bpadalino/projects/opencpi.git/project-registry
| Project Package-ID | Path to Project
| Valid/Exists |
| ------------------ |
------------------------------------------------------- | ------------ |
| ocpi.core | /home/bpadalino/projects/opencpi.git/projects/core
| True |
| ocpi.assets_ts |
/home/bpadalino/projects/opencpi.git/projects/assets_ts | True |
| ocpi.assets | /home/bpadalino/projects/opencpi.git/projects/assets
| True |
It doesn't seem like anything is out of the ordinary?
I tried adding the projects back and I get the same error.
Anything else come to mind to try?
Thanks,
Brian
On Thu, Dec 5, 2019 at 5:19 PM James Kulp jek@parera.com wrote:
On 12/5/19 4:56 PM, Brian Padalino wrote:
I'm trying to add Ubuntu 19.x support to OpenCPI.
Thanks!
My procedure has been to
add the directory projects/core/rcc/platforms/ubuntu19 and the following
files:
- README
- ubuntu19-check.sh
- ubuntu19.mk
- ubuntu-packages.sh
I also needed to change some source files due to updated GCC warnings
turning into errors, specifically:
- os/interfaces/include/OcpiOsEther.h
- runtime/dataplane/transport/impl/include/OcpiInputBuffer.h
- runtime/util/property/include/OcpiPValueApi.h
- runtime/util/property/src/OcpiUtilPValue.cxx
Note that you can usually just add a compiler flag that turns these
errors back into warnings so that you don't need to touch framework code
to get this job done. Its not a bad thing to "fix" that code if the
warnings are good, but it you can avoid a framework patch to get your
job done, that's better.
Good call. I'll give that a shot instead.
I also had to change the kernel module to have a different return type to
get everything to build.
Which kernel version did you end up with?
Currently I've got 5.3.0-19-generic running.
Is the default shell on that system bash? We sometimes end up assuming
bash when we shouldn't.
No, it's dash. I changed the scripts over to explicitly use bash after
sending this e-mail.
Chris is right, sometimes there are bootstrapping issues with adding new
software platforms where you have to do stuff to get the project exports
redone from the project that the new platform is in.
Alright. I'll cleaneverything and try building again.
Thanks,
Brian
you might beagle to bypass some of the weirdness you are getting from
hdl-platform.mk http://hdl-platform.mk:199 by running "ocpidev show rcc
platforms" but this doesn't really solve the problem.
the particular files that it is complaining about are just symbolic links
to files in the alst4 platform:
lrwxrwxrwx. 1 chinkey domain users 52 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_a_rx_tx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_a_rx_tx.xml
lrwxrwxrwx. 1 chinkey domain users 49 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_a_rx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_a_rx.xml
lrwxrwxrwx. 1 chinkey domain users 49 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_a_tx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_a_tx.xml
lrwxrwxrwx. 1 chinkey domain users 52 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_b_rx_tx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_b_rx_tx.xml
lrwxrwxrwx. 1 chinkey domain users 49 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_b_rx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_b_rx.xml
lrwxrwxrwx. 1 chinkey domain users 49 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_b_tx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_b_tx.xml
I'm not sure what causes these links to be created, but it seems like the
call to the hdl-platform.mk file is doing this somehow. If I remove the
links, call "ocpidev show platforms" and they are recreated. the make call
"make -n -r -s -C
/home/bpadalino/projects/opencpi.git/projects/assets/hdl/platforms/alst4x
ShellHdlPlatformVars=1 showpackage" must be failing to do this correctly
"
On Thu, Dec 5, 2019 at 5:24 PM Brian Padalino bpadalino@gmail.com wrote:
On Thu, Dec 5, 2019 at 5:19 PM James Kulp jek@parera.com wrote:
On 12/5/19 4:56 PM, Brian Padalino wrote:
I'm trying to add Ubuntu 19.x support to OpenCPI.
Thanks!
My procedure has been to
add the directory projects/core/rcc/platforms/ubuntu19 and the
following
files:
- README
- ubuntu19-check.sh
- ubuntu19.mk
- ubuntu-packages.sh
I also needed to change some source files due to updated GCC warnings
turning into errors, specifically:
- os/interfaces/include/OcpiOsEther.h
- runtime/dataplane/transport/impl/include/OcpiInputBuffer.h
- runtime/util/property/include/OcpiPValueApi.h
- runtime/util/property/src/OcpiUtilPValue.cxx
Note that you can usually just add a compiler flag that turns these
errors back into warnings so that you don't need to touch framework code
to get this job done. Its not a bad thing to "fix" that code if the
warnings are good, but it you can avoid a framework patch to get your
job done, that's better.
Good call. I'll give that a shot instead.
I also had to change the kernel module to have a different return type
to
get everything to build.Which kernel version did you end up with?
Currently I've got 5.3.0-19-generic running.
Is the default shell on that system bash? We sometimes end up assuming
bash when we shouldn't.
No, it's dash. I changed the scripts over to explicitly use bash after
sending this e-mail.
Chris is right, sometimes there are bootstrapping issues with adding new
software platforms where you have to do stuff to get the project exports
redone from the project that the new platform is in.
Alright. I'll cleaneverything and try building again.
Thanks,
Brian
On Thu, Dec 5, 2019 at 5:36 PM Chris Hinkey chinkey@geontech.com wrote:
you might beagle to bypass some of the weirdness you are getting from
hdl-platform.mk http://hdl-platform.mk:199 by running "ocpidev show rcc
platforms" but this doesn't really solve the problem.
the particular files that it is complaining about are just symbolic links
to files in the alst4 platform:
lrwxrwxrwx. 1 chinkey domain users 52 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_a_rx_tx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_a_rx_tx.xml
lrwxrwxrwx. 1 chinkey domain users 49 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_a_rx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_a_rx.xml
lrwxrwxrwx. 1 chinkey domain users 49 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_a_tx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_a_tx.xml
lrwxrwxrwx. 1 chinkey domain users 52 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_b_rx_tx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_b_rx_tx.xml
lrwxrwxrwx. 1 chinkey domain users 49 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_b_rx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_b_rx.xml
lrwxrwxrwx. 1 chinkey domain users 49 Nov 27 12:53
alst4x_zipper_hsmc_alst4_port_b_tx.xml ->
../../alst4/alst4_zipper_hsmc_alst4_port_b_tx.xml
I'm not sure what causes these links to be created, but it seems like the
call to the hdl-platform.mk file is doing this somehow. If I remove the
links, call "ocpidev show platforms" and they are recreated. the make call
"make -n -r -s -C
/home/bpadalino/projects/opencpi.git/projects/assets/hdl/platforms/alst4x
ShellHdlPlatformVars=1 showpackage" must be failing to do this correctly
Thanks. I added the symbolic links and I was able to get "ocpitest
ocpidev" to pass and the command seems to work now.
When it comes to setting up my environment, should I simply run
"./scripts/install-opencpi.sh" or do I need to supply the platform I want
to install?
If I want to be able to target both ubuntu19 (host machine) and xilinx18_3
(Vivado 2018.3 target), how should I go about doing that?
Lastly, it seems I get an error on the IQ file mapping tests when running
"./scripts/test-opencpi.sh". Specifically:
========Running iqstream_max_calculator_test:
Executing the iqstream_max_calculator_test application.
TEST: file_read->RCC worker->file_write
app failed: No acceptable implementations found in any libraries for
"ocpi.assets.util_comps.iqstream_max_calculator". Use log level 8 for more
detail.
Any idea how to use log level 8 for more detail?
Thanks,
Brian
"
On Thu, Dec 5, 2019 at 5:24 PM Brian Padalino bpadalino@gmail.com wrote:
On Thu, Dec 5, 2019 at 5:19 PM James Kulp jek@parera.com wrote:
On 12/5/19 4:56 PM, Brian Padalino wrote:
I'm trying to add Ubuntu 19.x support to OpenCPI.
Thanks!
My procedure has been to
add the directory projects/core/rcc/platforms/ubuntu19 and the
following
files:
- README
- ubuntu19-check.sh
- ubuntu19.mk
- ubuntu-packages.sh
I also needed to change some source files due to updated GCC warnings
turning into errors, specifically:
- os/interfaces/include/OcpiOsEther.h
- runtime/dataplane/transport/impl/include/OcpiInputBuffer.h
- runtime/util/property/include/OcpiPValueApi.h
- runtime/util/property/src/OcpiUtilPValue.cxx
Note that you can usually just add a compiler flag that turns these
errors back into warnings so that you don't need to touch framework code
to get this job done. Its not a bad thing to "fix" that code if the
warnings are good, but it you can avoid a framework patch to get your
job done, that's better.Good call. I'll give that a shot instead.
I also had to change the kernel module to have a different return
type to
get everything to build.Which kernel version did you end up with?
Currently I've got 5.3.0-19-generic running.
Is the default shell on that system bash? We sometimes end up assuming
bash when we shouldn't.No, it's dash. I changed the scripts over to explicitly use bash after
sending this e-mail.Chris is right, sometimes there are bootstrapping issues with adding new
software platforms where you have to do stuff to get the project exports
redone from the project that the new platform is in.Alright. I'll cleaneverything and try building again.
Thanks,
Brian
On Thu, Dec 5, 2019 at 6:16 PM Brian Padalino bpadalino@gmail.com wrote:
========Running iqstream_max_calculator_test:
Executing the iqstream_max_calculator_test application.
TEST: file_read->RCC worker->file_write
app failed: No acceptable implementations found in any libraries for
"ocpi.assets.util_comps.iqstream_max_calculator". Use log level 8 for more
detail.
Any idea how to use log level 8 for more detail?
I wish I waited a little bit longer before asking since I found the
OCPI_LOG_LEVEL environment variable.
I have a Centos7 lxc running as a supported installation, versus my Ubuntu
one to try to do A/B comparisons on. Here is what I found, but I have
absolutely no idea what would cause these things to happen.
== Ubuntu 19 ==
TEST: file_read->RCC worker->file_write
OCPI( 8:763.0769): Component: ocpi.core.file_read name: file_read impl:
spec: ocpi.core.file_read selection:
OCPI( 8:763.0769): Component:
ocpi.assets.util_comps.iqstream_max_calculator name:
iqstream_max_calculator impl: spec:
ocpi.assets.util_comps.iqstream_max_calculator selection:
OCPI( 8:763.0769): Component: ocpi.core.file_write name: file_write impl:
spec: ocpi.core.file_write selection:
OCPI( 8:763.0769): Considering implementation for instance "file_read" with
spec "ocpi.core.file_read": "file_read" from artifact
"/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_read.rcc.0.ubuntu19.so"
OCPI( 8:763.0769): Accepted implementation before connectivity checks with
score 1
OCPI( 8:763.0769): Considering implementation for instance "file_read" with
spec "ocpi.core.file_read": "file_read" from artifact
"/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_read.rcc.0.xilinx18_3.so"
OCPI( 8:763.0770): Accepted implementation before connectivity checks with
score 1
OCPI( 8:763.0770): Error Exception: No acceptable implementations found in
any libraries for "ocpi.assets.util_comps.iqstream_max_calculator". Use
log level 8 for more detail.
== Centos 7 ==
TEST: file_read->RCC worker->file_write
OCPI( 8:363.0964): Component: ocpi.core.file_read name: file_read impl:
spec: ocpi.core.file_read selection:
OCPI( 8:363.0964): Component:
ocpi.assets.util_comps.iqstream_max_calculator name:
iqstream_max_calculator impl: spec:
ocpi.assets.util_comps.iqstream_max_calculator selection:
OCPI( 8:363.0964): Component: ocpi.core.file_write name: file_write impl:
spec: ocpi.core.file_write selection:
OCPI( 8:363.0965): Considering implementation for instance "file_read" with
spec "ocpi.core.file_read": "file_read" from artifact
"/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_read.rcc.0.centos7.so"
OCPI( 8:363.0965): Accepted implementation before connectivity checks with
score 1
OCPI( 8:363.0965): Considering implementation for instance
"iqstream_max_calculator" with spec
"ocpi.assets.util_comps.iqstream_max_calculator": "iqstream_max_calculator"
from artifact
"/home/bpadalino/projects/opencpi.git/projects/assets/artifacts/
ocpi.assets.util_comps.iqstream_max_calculator.rcc.0.centos7.so"
OCPI( 8:363.0965): Accepted implementation before connectivity checks with
score 1
OCPI( 8:363.0965): Considering implementation for instance "file_write"
with spec "ocpi.core.file_write": "file_write" from artifact
"/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_write.rcc.0.centos7.so"
OCPI( 8:363.0965): Accepted implementation before connectivity checks with
score 1
OCPI( 8:363.0965): For instance file_read there were 1 candidates. These
had potential containers:
OCPI( 8:363.0965): Checking implementation file_read model rcc os linux
version c7 arch x86_64 platform centos7 dynamic 0 opencpi version 1.5
OCPI( 8:363.0965): OpenCPI version is: 1.5
OCPI( 8:363.0965): Artifact version checking is in effect. Set
OCPI_ALLOW_VERSION_MISMATCH to 1 to allow.
OCPI( 8:363.0965): vs. container rcc0 (0) model rcc os linux version c7
arch x86_64 platform centos7 dynamic 0 opencpi version 1.5 ==> accepted
OCPI( 8:363.0965): Candidate 0
/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_read.rcc.0.centos7.so is ok for containers: 0: rcc0
OCPI( 8:363.0965): For instance iqstream_max_calculator there were 1
candidates. These had potential containers:
OCPI( 8:363.0965): Checking implementation iqstream_max_calculator model
rcc os linux version c7 arch x86_64 platform centos7 dynamic 0 opencpi
version 1.5
OCPI( 8:363.0965): vs. container rcc0 (0) model rcc os linux version c7
arch x86_64 platform centos7 dynamic 0 opencpi version 1.5 ==> accepted
OCPI( 8:363.0965): Candidate 0
/home/bpadalino/projects/opencpi.git/projects/assets/artifacts/
ocpi.assets.util_comps.iqstream_max_calculator.rcc.0.centos7.so is ok for
containers: 0: rcc0
OCPI( 8:363.0965): For instance file_write there were 1 candidates. These
had potential containers:
OCPI( 8:363.0965): Checking implementation file_write model rcc os linux
version c7 arch x86_64 platform centos7 dynamic 0 opencpi version 1.5
OCPI( 8:363.0965): vs. container rcc0 (0) model rcc os linux version c7
arch x86_64 platform centos7 dynamic 0 opencpi version 1.5 ==> accepted
OCPI( 8:363.0965): Candidate 0
/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_write.rcc.0.centos7.so is ok for containers: 0: rcc0
OCPI( 8:363.0965): Negotiating connection from instance file_read (in
<none>) port out to instance iqstream_max_calculator (in <none>) port in
(buffer size is 18446744073709551615/0xffffffffffffffff)
OCPI( 8:363.0965): Negotiating connection from instance
iqstream_max_calculator (in <none>) port out to instance file_write (in
<none>) port in (buffer size is 18446744073709551615/0xffffffffffffffff)
OCPI( 8:363.0965): Negotiating connection from instance file_read (in rcc0)
port out to instance iqstream_max_calculator (in rcc0) port in (buffer size
is 8192/0x2000)
OCPI( 8:363.0965): Negotiating connection from instance
iqstream_max_calculator (in rcc0) port out to instance file_write (in rcc0)
port in (buffer size is 8192/0x2000)
OCPI( 8:363.0965): Loading RCC worker artifact
/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_read.rcc.0.centos7.so
OCPI( 8:363.0965): Loading RCC worker artifact
/home/bpadalino/projects/opencpi.git/projects/assets/artifacts/
ocpi.assets.util_comps.iqstream_max_calculator.rcc.0.centos7.so
OCPI( 8:363.0965): Loading RCC worker artifact
/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_write.rcc.0.centos7.so
OCPI( 8:363.0965): Starting worker: file_write in container rcc0 from
file_write/
OCPI( 8:363.0965): Starting worker: iqstream_max_calculator in container
rcc0 from iqstream_max_calculator/
OCPI( 8:363.0965): Starting worker: file_read in container rcc0 from
file_read/
OCPI( 8:363.0966): Waiting for "done" worker, "file_write", to finish
OCPI( 8:363.0966): iqstream_max_calculator: max_I updated to value of 0
OCPI( 8:363.0966): iqstream_max_calculator: max_Q updated to value of 0
OCPI( 8:363.0976): iqstream_max_calculator: max_I property read, queueing
up max_I reset...
OCPI( 8:363.0976): iqstream_max_calculator: ...performing max_I reset (to
-32768) that was previously queued
OCPI( 8:363.0976): iqstream_max_calculator: max_Q property read, queueing
up max_Q reset...
TEST: max_I_0_Q_0.bin: PASSED
It seems like my candidate .so files are being seen, but rejected by Ubuntu
and not on Centos7.
I'll try taking a look at OcpiLibraryAssembly.cxx, but I wouldn't imagine I
should have to do that to simply add the new platform. Any insights would
be useful.
Brian
On Thu, Dec 5, 2019 at 6:37 PM Brian Padalino bpadalino@gmail.com wrote:
On Thu, Dec 5, 2019 at 6:16 PM Brian Padalino bpadalino@gmail.com wrote:
========Running iqstream_max_calculator_test:
Executing the iqstream_max_calculator_test application.
TEST: file_read->RCC worker->file_write
app failed: No acceptable implementations found in any libraries for
"ocpi.assets.util_comps.iqstream_max_calculator". Use log level 8 for more
detail.
Any idea how to use log level 8 for more detail?
I wish I waited a little bit longer before asking since I found the
OCPI_LOG_LEVEL environment variable.
I have a Centos7 lxc running as a supported installation, versus my Ubuntu
one to try to do A/B comparisons on. Here is what I found, but I have
absolutely no idea what would cause these things to happen.
== Ubuntu 19 ==
TEST: file_read->RCC worker->file_write
OCPI( 8:763.0769): Component: ocpi.core.file_read name: file_read impl:
spec: ocpi.core.file_read selection:
OCPI( 8:763.0769): Component:
ocpi.assets.util_comps.iqstream_max_calculator name:
iqstream_max_calculator impl: spec:
ocpi.assets.util_comps.iqstream_max_calculator selection:
OCPI( 8:763.0769): Component: ocpi.core.file_write name: file_write impl:
spec: ocpi.core.file_write selection:
OCPI( 8:763.0769): Considering implementation for instance "file_read"
with spec "ocpi.core.file_read": "file_read" from artifact
"/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_read.rcc.0.ubuntu19.so"
OCPI( 8:763.0769): Accepted implementation before connectivity checks with
score 1
OCPI( 8:763.0769): Considering implementation for instance "file_read"
with spec "ocpi.core.file_read": "file_read" from artifact
"/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_read.rcc.0.xilinx18_3.so"
OCPI( 8:763.0770): Accepted implementation before connectivity checks with
score 1
OCPI( 8:763.0770): Error Exception: No acceptable implementations found in
any libraries for "ocpi.assets.util_comps.iqstream_max_calculator". Use
log level 8 for more detail.
== Centos 7 ==
TEST: file_read->RCC worker->file_write
OCPI( 8:363.0964): Component: ocpi.core.file_read name: file_read impl:
spec: ocpi.core.file_read selection:
OCPI( 8:363.0964): Component:
ocpi.assets.util_comps.iqstream_max_calculator name:
iqstream_max_calculator impl: spec:
ocpi.assets.util_comps.iqstream_max_calculator selection:
OCPI( 8:363.0964): Component: ocpi.core.file_write name: file_write impl:
spec: ocpi.core.file_write selection:
OCPI( 8:363.0965): Considering implementation for instance "file_read"
with spec "ocpi.core.file_read": "file_read" from artifact
"/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_read.rcc.0.centos7.so"
OCPI( 8:363.0965): Accepted implementation before connectivity checks with
score 1
OCPI( 8:363.0965): Considering implementation for instance
"iqstream_max_calculator" with spec
"ocpi.assets.util_comps.iqstream_max_calculator": "iqstream_max_calculator"
from artifact
"/home/bpadalino/projects/opencpi.git/projects/assets/artifacts/
ocpi.assets.util_comps.iqstream_max_calculator.rcc.0.centos7.so"
OCPI( 8:363.0965): Accepted implementation before connectivity checks with
score 1
OCPI( 8:363.0965): Considering implementation for instance "file_write"
with spec "ocpi.core.file_write": "file_write" from artifact
"/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_write.rcc.0.centos7.so"
OCPI( 8:363.0965): Accepted implementation before connectivity checks with
score 1
OCPI( 8:363.0965): For instance file_read there were 1 candidates. These
had potential containers:
OCPI( 8:363.0965): Checking implementation file_read model rcc os linux
version c7 arch x86_64 platform centos7 dynamic 0 opencpi version 1.5
OCPI( 8:363.0965): OpenCPI version is: 1.5
OCPI( 8:363.0965): Artifact version checking is in effect. Set
OCPI_ALLOW_VERSION_MISMATCH to 1 to allow.
OCPI( 8:363.0965): vs. container rcc0 (0) model rcc os linux version c7
arch x86_64 platform centos7 dynamic 0 opencpi version 1.5 ==> accepted
OCPI( 8:363.0965): Candidate 0
/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_read.rcc.0.centos7.so is ok for containers: 0: rcc0
OCPI( 8:363.0965): For instance iqstream_max_calculator there were 1
candidates. These had potential containers:
OCPI( 8:363.0965): Checking implementation iqstream_max_calculator model
rcc os linux version c7 arch x86_64 platform centos7 dynamic 0 opencpi
version 1.5
OCPI( 8:363.0965): vs. container rcc0 (0) model rcc os linux version c7
arch x86_64 platform centos7 dynamic 0 opencpi version 1.5 ==> accepted
OCPI( 8:363.0965): Candidate 0
/home/bpadalino/projects/opencpi.git/projects/assets/artifacts/
ocpi.assets.util_comps.iqstream_max_calculator.rcc.0.centos7.so is ok for
containers: 0: rcc0
OCPI( 8:363.0965): For instance file_write there were 1 candidates. These
had potential containers:
OCPI( 8:363.0965): Checking implementation file_write model rcc os linux
version c7 arch x86_64 platform centos7 dynamic 0 opencpi version 1.5
OCPI( 8:363.0965): vs. container rcc0 (0) model rcc os linux version c7
arch x86_64 platform centos7 dynamic 0 opencpi version 1.5 ==> accepted
OCPI( 8:363.0965): Candidate 0
/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_write.rcc.0.centos7.so is ok for containers: 0: rcc0
OCPI( 8:363.0965): Negotiating connection from instance file_read (in
<none>) port out to instance iqstream_max_calculator (in <none>) port in
(buffer size is 18446744073709551615/0xffffffffffffffff)
OCPI( 8:363.0965): Negotiating connection from instance
iqstream_max_calculator (in <none>) port out to instance file_write (in
<none>) port in (buffer size is 18446744073709551615/0xffffffffffffffff)
OCPI( 8:363.0965): Negotiating connection from instance file_read (in
rcc0) port out to instance iqstream_max_calculator (in rcc0) port in
(buffer size is 8192/0x2000)
OCPI( 8:363.0965): Negotiating connection from instance
iqstream_max_calculator (in rcc0) port out to instance file_write (in rcc0)
port in (buffer size is 8192/0x2000)
OCPI( 8:363.0965): Loading RCC worker artifact
/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_read.rcc.0.centos7.so
OCPI( 8:363.0965): Loading RCC worker artifact
/home/bpadalino/projects/opencpi.git/projects/assets/artifacts/
ocpi.assets.util_comps.iqstream_max_calculator.rcc.0.centos7.so
OCPI( 8:363.0965): Loading RCC worker artifact
/home/bpadalino/projects/opencpi.git/projects/assets/imports/ocpi.core/exports/artifacts/
ocpi.core.file_write.rcc.0.centos7.so
OCPI( 8:363.0965): Starting worker: file_write in container rcc0 from
file_write/
OCPI( 8:363.0965): Starting worker: iqstream_max_calculator in container
rcc0 from iqstream_max_calculator/
OCPI( 8:363.0965): Starting worker: file_read in container rcc0 from
file_read/
OCPI( 8:363.0966): Waiting for "done" worker, "file_write", to finish
OCPI( 8:363.0966): iqstream_max_calculator: max_I updated to value of 0
OCPI( 8:363.0966): iqstream_max_calculator: max_Q updated to value of 0
OCPI( 8:363.0976): iqstream_max_calculator: max_I property read, queueing
up max_I reset...
OCPI( 8:363.0976): iqstream_max_calculator: ...performing max_I reset (to
-32768) that was previously queued
OCPI( 8:363.0976): iqstream_max_calculator: max_Q property read, queueing
up max_Q reset...
TEST: max_I_0_Q_0.bin: PASSED
It seems like my candidate .so files are being seen, but rejected by
Ubuntu and not on Centos7.
I'll try taking a look at OcpiLibraryAssembly.cxx, but I wouldn't imagine
I should have to do that to simply add the new platform. Any insights
would be useful.
This was solved by actually looking at the error and noting it didn't have
iqstream_max_calculator - the file stuff was fine. I then noted that the
appropriate .so files were in different asset locations. When I first:
$ export
OCPI_LIBRARY_PATH=/home/bpadalino/projects/opencpi.git/projects/assets/artifacts:/home/bpadalino/projects/opencpi.git/projects/core/artifacts
I can now get the ocpitest assets to work correctly. This seems to be
another issue with symbolic links not being correctly created or propagated
through the project.
I'll take a deeper look and hopefully resolve the issue. Sorry for the
noise, but thanks for the quick responses.
Brian