Hi Bo,
Yes, I was referring to the ESS EPICS setup, which has been developed based on the PSI implementation.
And: no, there is no way to get this working with just a "normal base" system. That run-time module resolution and linking mechanism is a complicated beast, and needs additional tools and services.
Bugs in such setups have the tendency to show up at run time as spontaneous core dumps.
Starting from "normal base", your basic option is shared libraries vs. statically built binaries. When using shared libraries, you have to make sure that the right versions of the right libraries are in the right place when running the IOC. EPICS won't help you with that, so people use package managers or containers to do this.
If you build statically, you can usually get by with tarring up the installation directories of your IOC application, and extracting that archive on the machine that will run the IOC.
That is a lot easier and pretty robust.
Cheers,
~Ralph
Hi
I am also very interested in this thread as I am working on a new
setup.
I worked with the below described configuration when working with
the ESS EPICS setup, but could you please provide some information
on how to do this from the "normal base" epics system. All demos
and docs I have seen ends up with compiling the ioc binary
including the support libraries in the process.
On 2018-10-12 09:37, Ralph Lange wrote:
Other institutes are using an NFS mounted
repository of all applications and shared libraries and a
database of versions of tested combinations of these, and load
device support and EPICS modules dynamically from the startup
script of the IOC. This also needs a careful design and serious
building infrastructure in the background, but maybe requires
less upfront work and learning compared to the first option.
Best
Bo
