Dirk Zimoch wrote:
> Hi Kate and all others,
> Kate Feng wrote:
> > ... My wish also gives RTEMS or Linux users an option to dynamically
> > load a new application code (e.g. ld("new.obj")), which might need a
> > new record/device/driver support entry table registered (e.g.
> > new_SRCS += new_registerRecordDeviceDriver.cpp) at run time or even
> > during an IOC test/development stage, which could occur very often
> > during a development cycle. I actually found it handy in beamline
> > applications.
> > ...
> Attached you will find a Linux (UNIX?) implementation of the 'ld'
> command. Just link it to your iocsh. On Linux, it can load shared
> libraries (*.so). Maybe the code has to be modified to run on other
> platforms. I used the 'dlopen' function to implement it.
> ld ("foo")
I use RTEMS-CEXP, which has a dynamic loader except it does not support
> Searches LD_LIBRARY_PATH for libfoo.so, foo.so, foo (in this order).
> After loading the code, all C++ constructors of global objects are
> executed (for registering, etc.)
> I have not tried it on any other platform.
However, I do not think the shared libraries is vital in the matter of
C++ static constructor. C++ static constructor will work for function
registration, which is not necessary (e.g. not even iocsh, dbl, dbpr.....)
using RTEMS-CEXP though. C++ static constructor was the first
thing I tried to register Record/Device/Driver before I used
<app>_registerRecordDeviceDriver. Because of the sequence of the
startup.cmd, it seems to be impossibe to get the C++ static constructor
to work for the registerRecordDeviceDriver. It has to be executed
after, not before, the dbLoadDatabase("dbd/app.dbd") command.
For example, the following sequence in the startup.cmd will work :
ld ("app.obj") #load the application codes
But not the following :
Ditto , the following will crash :
ld ("app.obj") #C++ static constructor auto-register the record/device/driver
#Oh, no , record/device/driver has to be registered after the database is
Dirk Zimoch also wrote :
> Unfortunately, registerRecordDeviceDriver is not static nor prefixed by
> <project>_ as you already noticed. And that means, auto register or not,
> you will have name clashes when linking/loading multiple projects on the
> same ioc. Your suggestion of prefixing the name will be a solution.
I did not get a chance to try R3.14.2 yet. Based on the developer's guide,
one can use registryRecordTypeAdd(), regsitryDeviceSupportAdd()
and registryDriverSupportAdd() to dynamically regsiter each
record (RSET), device (DSET), driver support entry table, respectively,
instead of using only one command. However,
I suspect it requires developers to build the applcation as a shared libray.
As what I mentioned earlier that, RTEMS-CEXP does not support
shared libraries. It requires static-built objects.
Luckily, R3.14.2 still has the registerRecordDeviceDriver.pl, which means
that I can still use my existing tools. As long as the future release of
maintains its backward-compatiblity with the current release
( R3.14.0beta2 and up) by keeping the function of
registerRecordDeviceDriver.pl , it will work with my applications and tools.
- R3.14 and registerRecordDeviceDriver Kate Feng
- Re: R3.14 and registerRecordDeviceDriver Dirk Zimoch
- Navigate by Date:
Re: including external libraries in EPICS R3.14.2 builds Ralph Lange
IOC Support Stephen Goodsell
- Navigate by Thread:
Re: R3.14 and registerRecordDeviceDriver Dirk Zimoch
EPICS collaboration meeting presentations Hayton, TG (Tim)