Re: Question from the RTEMS corner

[Chris Johns via Core-talk <core-talk at aps.anl.gov>]

On 27/8/20 3:21 am, J. Lewis Muir via Core-talk wrote:
> On 08/26, Ralph Lange via Core-talk wrote:
>> On Wed, 26 Aug 2020 at 13:56, Heinz Junkes via Core-talk <
>> core-talk at aps.anl.gov> wrote:
>>
>>> I received the following question from an RTEMS developer:
>>>
>>>> How is EPICS used in real systems? Is the production executable built by
>>> EPICS
>>>> from the EPICS source tree? Is it a set of libraries that get installed
>>> and an
>>>> application links in these libraries?
>>>
>>> What should I answer?
>>>
>>
>> Obviously the second option.
>> EPICS Base provides libraries and the build system, the user creates their
>> own IOC application binary, linking in those libraries.

Thanks, this is very helpful.

Does the EPICS's build system support `make DESTDIR=/somewhere install`?

> Just so the RTEMS developer doesn't get surprised by non-UNIX-like
> shared library behavior, 

It is me and thanks this seems reasonable.

RTEMS supports dlopen and friends but the link editor is more aligned to a
static absolute link process than the Unix shared library model. On RTEMS there
is nothing to share. The OS, libraries and application can be considered a
single process so the sharing techniques used on Unix provide no advantages on
RTEMS.

> it might also be worth mentioning to them that
> there is no guarantee of API nor ABI backward compatibility whatsoever
> in EPICS Base, even across a patch version increase.

Thanks and yes this is understood ...

https://docs.rtems.org/branches/master/user/exe/executables.html#machine-flags-and-abi

> The UNIX-like shared library versioning scheme is that you have
> libfoo.so.MAJOR.MINOR and symlinks that allow you to provide updated
> libraries that bump MINOR but don't break backward compatibility.
> The MINOR version increase will only contain backward-compatible
> changes, and then when the application starts, it will try to
> load libfoo.so.MAJOR which will be a symlink to the latest
> libfoo.so.MAJOR.MINOR thus allowing the application to receive
> backward-compatible changes without needing to be recompiled.
> 
> Unfortunately, EPICS Base libraries don't work this way.  I only say
> this in light of the "Is it a set of libraries that get installed and an
> application links in these libraries?" question since the "application
> links in" part of that will be very fragile.  The exact version of EPICS
> Base libraries that an application was compiled against are the ones
> that are required to be installed in order for the application to work.
> If instead a new version of EPICS Base is installed that replaces the
> old version, then any applications must be recompiled against the new
> EPICS Base libraries.

This makes sense and follows the same model RTEMS application development needs
to follow. We have a tool called `rtems-execinfo` that accepts an RTEMS ELF
executable with debug info and it will report the various machine flags used to
build the code.

Chris