Re: ANN: RTEMS libnetworking relocation

["Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov>]

On Mar 8, 2021, at 4:49 PM, Chris Johns via Core-talk <core-talk at aps.anl.gov> wrote:

The stacks are considered separate packages and I hope they can be built
independently and installed side by side under the BSP. From an RTEMS
perspective if a stack (or any 3rd party package) can be built I would prefer
that happens so users can select which ever stack they want using options or
configurations they have control over.

Isn’t there an overlap between the header files that come with the two stacks? If you want to be able to install both stacks, they probably need to install their headers into different places.

I recently rebuilt a BSP to change from the libbsd stack to the legacy one, installing the result into the same prefix. I didn’t delete the old BSP tree first, and the result was a mixture of headers in the BSP’s lib/include directory. The EPICS code was still pulling in a header from the libbsd stack that it shouldn’t have been using, and the result was a linker error with missing symbols for some shell commands that are not present in the legacy stack. It wasn’t until I rebuilt the BSP from scratch that I found the wrong header issue in our code.

Can the EPICS build system check the BSP to see which libraries are present and
then decide which stack to use? The libbsd library is libbsd.a and I am not sure
what the net-legacy archive name is.

How do you reconcile those two: If both stacks can be built for a BSP, both sets of libraries would be present, so checking for the presence of one or the other library wouldn’t tell us which to use.

We don’t currently have a way in EPICS to adjust what we build based on what libraries are available upstream, although that could be added if necessary. The user needs to specify that kind of thing somewhere, but I think we’d prefer that the RTEMS BSP tell us how it has been configured in the makefile fragments that we include from the BSP. If the user has to provide information about how the RTEMS BSP was built in their EPICS build configuration but they get it wrong our code will fail to build, so it seems more sensible for our build system to get as much information as it can directly from your build system.

If you get to the stage were a user can have both stacks built and installed so that switching between them would just be a matter of user preference when EPICS gets built, then letting the user choose the stack in their EPICS target configuration would be fine, but we’d want to be able to confirm that their RTEMS build actually contains the stack they’re asking for at the start of our build, not when we first try to compile or link an application image against it.

- Andrew

-- 

Complexity comes for free, simplicity you have to work for.