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.
|