Program linkage
External reference validation is performed by default with maketpf and can be turned off with maketpf options (TPF_VERIFY_LINK_REFS). Validation issues errors at build time rather than at run time. If the program is built without verifying external references, it will build cleanly, but a run-time error will be issued if a function is not found online.
Standard libraries (including stub libraries) are included automatically by maketpf. The list of standard libraries is managed in the maketpf setup. You can define your own standard libraries. If you reference nonstandard libraries, you need to make a corresponding entry in your makefile. For more information about Makefiles, enter man maketpf.mak on your Linux® on IBM Z build system for a complete list of Makefile variables that can be coded.
Input libraries are specified by using LIBS assignments in the calling makefile. Your z/TPF programs will not be linked if unresolved references are detected.
- Load-time linkage: Normal load-time linkage is sometimes referred to as dynamic linkage because the linkage references are resolved dynamically when the program is loaded into storage.
- Link-time linkage: This internal linkage is resolved at link time and provides the fastest linkage between programs. For CSOs, this linkage is generated by the compiler and cannot be controlled. For BSOs, the BEGIN macro controls the linkage. See z/TPF General Services for more information about the BEGIN macro.
- Run-time linkage: This is the longest linkage because it is resolved at run time. The enter stub branches to a program name hash routine, which locates the program attribute table (PAT) of the program to be entered and determines the stub based on program type. The hash routine then branches to the CSO stub code.
- Nonstandard linkage: One type of common nonstandard linkage involves getting the base address of a program and branching directly to it. You can see an example of this linkage in recoup descriptors, which are programs that are used as data records that also can contain the code needed to chase your own file chains. While not suggested, you can use this type of linkage.
Linking C or C++ objects with BAL objects in the same BAL shared object is not supported. When C++ and BAL objects are linked in the same shared object, the loader shows an error. This error is because of the __TPF_soinit symbol that gets included from the startup code. Similarly, when C and BAL objects are linked in the same shared object, errors can occur when the C object includes imported data or constructors.