XL Fortran Enterprise Edition for AIX : User's Guide - IBM

v
Static linking means that the code for all routines called by your program
becomes part of the executable file.
Statically linked programs can be moved to and run on systems without the XL
Fortran libraries. They may perform better than dynamically linked programs if
they make many calls to library routines or call many small routines. They do
require some precautions in choosing names for data objects and routines in the
program if you want to avoid naming conflicts with library routines (as
explained in “Avoiding Naming Conflicts during Linking”). They also may not
work if you compile them on one level of the operating system and run them on
a different level of the operating system.
You can use -b linker options on the compiler command line to create statically
linked object files:
xlf95 -bnso -bI:/usr/lib/syscalls.exp file1.f file2.f
You must also specify -bI:/usr/lib/threads.exp when you are statically linking
with the xlf_r, xlf_r7, xlf90_r, xlf90_r7, xlf95_r, or xlf95_r7 command.
If you are using Asynchronous I/O, you must also specify -bI:/usr/lib/aio.exp.
The -bnso option places the library procedures that your program references into
the program’s object file. Files with a suffix of .exp specify the names of system
routines that must be imported to your program from the system.
An alternative that requires less disk space is to link any XL Fortran libraries
statically but to leave references to other system libraries dynamic. This example
statically links just the XL Fortran libraries:
# Build a temporary object from the Fortran library:
ld -r -o libtmp.o -bnso -lxlf90
# Build the application with this object on the command line:
xlf95 -o appl appl1.o appl2.o libtmp.o
Avoiding Naming Conflicts during Linking
If you define an external subroutine, external function, or common block with the
same name as a run-time subprogram, your definition of that name may be used
in its place, or it may cause a link-edit error.
Try the following general solution to help avoid these kinds of naming conflicts:
v
Compile all files with the -qextname option. It adds an underscore to the end of
the name of each global entity, making it distinct from any names in the system
libraries.
v
v
Note: When you use this option, you do not need to use the final underscore in
the names of Service and Utility Subprograms, such as dtime_ and flush_.
Link your programs dynamically, which is the default. Many naming conflicts
only apply to statically linked programs.
Order the names of libraries and object files on the command line so that the
one that should take precedence comes first. For example, to make names in
libxlf90.a take precedence over duplicate names in an object file, specify -lxlf90
first on the command line.
If you do not use the -qextname option, you must take the following extra
precautions to avoid conflicts with the names of the external symbols in the XL
Fortran and system libraries:
v Do not name a subroutine or function main, because XL Fortran defines an entry
point main to start your program.
v Do not use any global names that begin with an underscore. In particular, the XL
Fortran libraries reserve all names that begin with _xl.
Editing, Compiling, Linking, and Running XL Fortran Programs 47