|
VMS Help CXX, Qualifiers, /EXPORT_SYMBOLS *Conan The Librarian |
/EXPORT_SYMBOLS=(OPTIONS_FILE=<name>
[,EXCLUDE=<list of images>]
[,export_option]
[,NOTEMPLATES]) (I64 only)
Creating OpenVMS shareable images that contain C++ code has long
been a problem for users. When building a shareable image, you
must specify a list of exported global symbols. For C++ code,
determining this list can be very difficult for the following
reasons:
o Required C++ name mangling makes it difficult to know the name
of the external symbol created for a C++ name.
o OpenVMS CRC encoding (to 31 characters) further complicates
mapping source names to object names.
o Certain C++ constructs require compiler-generated names to be
created and exported.
To help solve the problem, the HP C++ compiler provides the
/EXPORT_SYMBOLS qualifier and __declspec(dllexport) declaration
modifier.
The default file extension for the OPTIONS_FILE <name> is .OPT.
If the file exists, the compiler appends to it. If the file does
not exist, the compiler creates it.
The output for the compilation is:
!
! Entries added for <module>
!
<symbol vector>
<symbol vector>
.
.
.
The output file is suitable input to a linker options file that
can be used to build a shareable image containing the compiled
object.
The format of each <symbol vector> is:
SYMBOL_VECTOR=(<global name>={DATA | PROCEDURE}) ! <comment field>
The <comment field> format is:
<unmangled name> [<promoted static flag>] [<class information>]
The <promoted static flag> is one of the following:
*PSDM* - for promoted static data members
*PTSDM* - for promoted template static data members
The <promoted static flag> is output whenever the symbol is a
promoted local static or a promoted template static data member.
This is important because these variables, while declared static,
actually become global symbols when compiled.
The <class information> field is present if the symbol is a
member of a class. It contains the name of the class.
NOTES
o When /EXPORT_SYMBOLS is specified, an object file must
also be generated. So /EXPORT_SYMBOLS cannot be used with
/NOOBJ, /PREPROCESS_ONLY, or any other qualifier that
prevents the creation of an object file.
o When the options file already exists, the compiler reads
all the symbols that are listed there. If the current
compilation also defines one of those symbols, that
symbol will not be added to the options file. This is
necessary to prevent SYMVALRDEF warnings from the linker.
o When the compiler reads the existing file, it treats
SYMBOL_VECTOR directives that are in comments (of the
form !SYMBOL_VECTOR...) as if they were not commented.
In this way, if a user does not want to export a symbol,
placing it in comments will prevent the compiler from
emitting a directive for that symbol when it compiles
other sources that might also define the symbol.
o The symbols placed in the options file are a subset
of the symbols defined in the output object file. The
export_option value controls exactly which symbols are
placed there. There are three choices:
Export_
option
Value Usage
ALL Place all symbols suitable for placement in
a sharable image into the options file. The
compiler knows that certain symbols are not
suited for placement in a shareable image
and excludes them from the options file.
Some examples are certain compiler-generated
constructor/destructor jackets and symbols in
the unnamed namespace.
EXPLICIT Place only those symbols marked with the
__declspec(dllexport) declaration modifier
into the options file.
AUTOMATIC(If the compiler processes a
__declspec(dllexport), then act as if EXPLICIT
was specified. If the compiler does not
process a __declspec(dllexport), then act
as if ALL was specified.
o The EXCLUDE option of the /EXPORT_SYMBOLS qualifier
can be used to specify a list of shareable images. The
compiler searches these images for any symbols that it
might want to place in the output options file. If it
finds the symbol in the image, then that symbol will not
be put into the options file.
o The NOTEMPLATES option can be used to control
the emission of symbols associated with template
instantiations. Specifying this option causes the
compiler to suppress symbols created by template
instantiation. This includes instantiations of class
templates, its data members and member functions, and
instantiations of function templates. This option could
be used to avoid multiple definition diagnostics from the
linker if multiple sharable images might be instantiating
(and exporting) the same template symbols. Symbols
marked with __declspec(dllexport) still get exported.
This option has no effect on symbols from template
specializations. Note that while this option might
make the sharable images smaller by not exporting the
template symbols, the executable image that links with
these sharable images might be larger because it will
contain the instantiated template symbols.
Because shareable images almost always contain a number of
objects, the commands for creating the options file the first
time might be:
$ DELETE options_file.OPT;*
$ CXX SOURCE1/EXPORT_SYMBOLS=OPTIONS_FILE=options_file
$ CXX SOURCE2/EXPORT_SYMBOLS=OPTIONS_FILE=options_file
$ CXX SOURCE3/EXPORT_SYMBOLS=OPTIONS_FILE=options_file
.
.
.
$ CXX SOURCEn/EXPORT_SYMBOLS=OPTIONS_FILE=options_file
Where SOURCE1 - SOURCEn are the sources for the shareable. After
the compilations, the options_file.OPT will contain correct
symbol vector information for the shareable.
The first time this options file is created, it can be considered
a candidate options file. It contains all the symbol vector
entries for all the C++ globals that make sense to export from
the C++ language point of view. A user can then edit this file to
exclude (by commenting out) entries that should not be exported,
based on the design of the library.
Once an options file is created, it should be maintained for
input to subsequent compilations. In this way, any new symbols
caused by a change in the source will be added to the end of the
compilation. Any existing symbols will not be added, as described
in the NOTES section above. This technique ensures that the order
of symbols remains unchanged, and that future shared libraries
are compatible with existing ones.
|
|