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_at_gmail.com> wrote:
> On Thu, Dec 5, 2019 at 5:19 PM James Kulp <jek_at_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
>
Received on Thu Dec 05 2019 - 22:36:09 CST