Prelinker options

The following information describes the prelink options available in z/OS® XL C/C++ by using Language Environment® services.

DLLNAME(dll-name)

DLLNAME specifies the DLL name that appears on generated IMPORT control statements, described in IMPORT control statement. If you specify the DLLNAME option, the prelinker sets the DLL name to the value that you listed on the option.

If you do not specify DLLNAME, the prelinker sets the DLL name to the name that appeared on the last NAME control statement that it processed. If there are no NAME control statements, and the output object module of the prelinker is a PDS member, it sets the DLL name to the name of that member. Otherwise, the prelinker sets the DLL name to the value TEMPNAME, and issues a warning.

DUP | NODUP

DEFAULT: DUP

DUP specifies that if duplicate symbols are detected, their names should be directed to the console, and the return code minimally set to a warning level of 4. NODUP does not affect the return code setting when the prelinker detects duplicates.

DYNAM | NODYNAM

DEFAULT: DYNAM

When the NODYNAM option is in effect, export symbol processing is not performed by the prelinker even when export symbols are present in the input objects. The side-deck is not created and the resulting module will not be a DLL. Specify NODYNAM for prelinked C/C++ programs involved in COBOL C/C++ ILC calls.

ER | NOER

DEFAULT: ER

Note: For the z/OS UNIX Systems Services environment, the default is NOER.

If there are unresolved symbols, ER instructs the prelinker to write a messages and a list of unresolved symbols to the console. If there are unresolved references, the prelinker sets the return code to a minimum warning level of 4. If there are unresolved writable static references, the prelinker sets the return code to a minimum error level of 8. If you use NOER, the prelinker does not write the list of unresolved symbols to the console. If there are unresolved references, the return code is not affected. If there are unresolved writable static references, prelinker sets the return code to a minimum warning level of 4.

MAP | NOMAP

DEFAULT: MAP

In the z/OS UNIX System Services environment, the c89, cc, and c++ utilities specify MAP when you use the -V flag, and NOMAP when you do not.

The MAP option specifies that the prelinker should generate a prelink listing. See Language Environment Prelinker Map for a description of the map.

MEMORY | NOMEMORY

DEFAULT: NOMEMORY

The MEMORY option instructs the prelinker to retain in storage, for the duration of the prelink step, those object modules that it reads and processes.

You can use the MEMORY option to increase prelinker speed. However, you may require additional memory to use this option. If you use MEMORY and the prelink fails because of a storage error, you must increase your storage size or use the prelinker without the MEMORY option.

NCAL | NONCAL

DEFAULT: NONCAL

The NCAL option specifies that the prelinker should not use the automatic library call to resolve unresolved references.

The prelinker performs an automatic library call when you specify the NONCAL option. An automatic library call applies to a library of user routines. For NOOMVS, the data set must be partitioned, but for OMVS the data set that the prelinker searches can be either a PDS or an archive library. Automatic library call cannot apply to a library that contains load modules.

Note: If you are prelinking C++ object modules, you must use the NONCAL option and include the C++ base library in the CEE.SCEECPP data set in your SYSLIB concatenation.

OMVS | NOOMVS

DEFAULT: NOOMVS

The OMVS option causes the prelinker to change the way that it processes INCLUDE and LIBRARY control statements. The c89 utility turns on the OE option (which maps to the OMVS option) by default. Object files and object libraries from c89 are passed as primary input to the prelinker. Object files are passed via INCLUDE control statements, and object libraries via LIBRARY control statements. Only those LIBRARY control statements that are included in primary input are accepted by the prelinker. Their syntax is:

LIBRARY libname

where libname is the name of a DD that defines a library. The library may be either an archive file created through the ar utility or a partitioned data set (PDS) with object modules as members. The prelinker uses LIBRARY control statements like SYSLIBs, to resolve symbols through autocalls.

When you specify the OMVS option, the prelinker accepts INCLUDE and LIBRARY statements which refer to z/OS UNIX files (PATH=) and data set name (DSNAME=) allocations.

When you use the OMVS option, the order in which object files and object libraries are passed is significant. The prelinker processes its primary input sequentially. It searches the library that you specified on the LIBRARY statement only at the point where it encounters the LIBRARY statement. It does not refer to that library or processes it again. For example, if you pass your object files and object libraries as follows:

c89 file1.o lib1.a file2.o lib2.a

The prelinker processes the INCLUDE control statement for file1.o, and incorporates new symbol definitions and unresolved references from the object file into the output file. The prelinker then processes the LIBRARY control statement for lib1.a, and searches the library for currently unresolved symbols. It then processes file2.o followed by lib2.a. If the processing of file2.o results in unresolved symbols, the prelinker will not search the library lib1.a again, because it has already processed it. If you have unresolved symbols that may be defined in a library that has already been processed, you must specify a new LIBRARY statement after your INCLUDE statement to resolve those symbols. You can do this on a c89 command line as follows:

c89 file1.o lib1.a file2.o lib1.a lib2.a

RENAME control statements are processed on output from the prelinker, after all of its input has been processed. Because a library can be processed once only, the SEARCH option on the RENAME control statement has no effect.

Note: The OE prelinker option maps to the OMVS prelinker option.

UPCASE | NOUPCASE

DEFAULT: NOUPCASE

The UPCASE option enforces the uppercase mapping of long names that are 8 characters or fewer and have not been explicitly mapped by another mechanism. These long names are uppercased (with _ mapped to @), and names that begin with IBM or CEE are changed to IB$ and CE$, respectively.

The UPCASE option is useful when calling routines that are written in languages other than z/OS XL C/C++. For example, in COBOL and assembler, all external names are in uppercase. So, if the names are coded in lowercase in the z/OS XL C/C++ program and you use the LONGNAME option, the names will not match by default. You can use the UPCASE option to enforce this matching. You can also use the RENAME control statement for this purpose.

Note: Use of this option can be dangerous, since names with a length of 8 characters or less will lose their case sensitivity. A better way to get the linkage and names correct is through the use of the appropriate pragmas.