 |
The Question is:
Is there any limitation to RMS I/O from a shared image?
I have a program (in c) that works correctly when linked with /image. This
program has a main() that calls a (soon to be global) routine that calls
printf().
These same printf() calls don't work when that source is linked with /share
and a linker options file that names the above mentioned global entry point.
The caller of LIB$FIND_IMAGE_SYMBOL (?) might be loading the image from EXEC
mode.
I didn't write the loader, and I have no access to its source.
I've tried fprintf to stderr, but no luck.
I've redirected stdout to a file, but no joy.
The Answer is :
You will first need to determine what processor mode the application
is operating in -- most standard language run-time libraries and even
the OpenVMS system run-time libraries are not supported for inner-mode
operations.
Applications executing in inner processor modes will usually use only
OpenVMS system services and/or entry points directly in the OpenVMS
executive -- while a subset of the C run-time library is available to
inner mode code in recent OpenVMS Alpha releases, this is not the
default C run-time and it requires an explicitly and deliberately
different linking procedure. (See the OpenVMS Alpha device driver
documentation for details of the kernel-mode C run-time interface.)
The standard C (user-mode) run-time library routines require explicit
initialization when not used with a C main program -- please see the
details of the VAXC$CRTL_INIT call included in the C documentation.
There are a large number of (user-mode) shareable images written in
C, and a cookbook for the creation of a shareable image is included
in the Ask The Wizard area -- these (user-mode) shareable images do
work just fine... A full source example of a C shareable image is
included in topic 2486 here in Ask The Wizard, including a call to
lib$find_image_symbol to activate the shareable image, and the use
of printf from within the shareable image.
|
|
|
|
|
