By default, you do not need to do anything special to link an XL Fortran program. The linker is executed automatically to produce an executable output file:
xlf95 file1.f file2.o file3.f
After linking, follow the instructions in Running XL Fortran Programs to execute the program.
To produce object files that can be linked later, use the -c option.
xlf95 -c file1.f # Produce one object file xlf95 -c file2.f file3.f # Or multiple object files xlf95 file1.o file2.o file3.o # Link with appropriate libraries
It is often best to execute the linker through the compiler invocation command, because it passes some extra ld options and library names to the linker automatically.
To use the ld command to link an SMP program, follow these guidelines:
On AIX Version 4.3 and higher, the default POSIX pthreads API is the 1003.1-1996 standard. If you had a program called mytest and you wanted to obtain access to the functions in the 1003.1-1996 standard POSIX pthreads API on AIX Version 4.3, you would link with the libpthreads.a library, using something similar to the following command:
ld -bh:4 -bpT:0x10000000 -bpD:0x20000000 /lib/crt0_r.o mytest.o -lxlf90_r -lxlf -lxlsmp -lm_r -lm -lc_r -lc -lpthreads -o mytest
The 1003.1-1996 standard is not fully compatible with Draft 7. If you have programs that require the Draft 7 interface, link your programs with the libpthreads_compat.a and libxlfpthrds_compat.a libraries (which provide compatibility support) followed by the libpthreads.a library. For example, if you have a program called mytest that was written to use the Draft 7 interface, on AIX Version 4.3, you would use something similar to the following command:
ld -bh:4 -bpT:0x10000000 -bpD:0x20000000 /lib/crt0_r.o mytest.o -lxlfpthrds_compat -lxlf90_r -lxlf -lxlsmp -lm_r -lm -lc_r -lc -lpthreads_compat -lpthreads -o mytest
The configuration file /etc/xlf.cfg lists these default libraries and linker options. By doing a sample compilation with the -# option, you can see exactly how the compiler would run the linker.
See the AIX Commands Reference for a description of the linker options.
To use the ld command to link a 64-bit SMP program, follow these guidelines:
For example, to link the object files smpfile1.o and smpfile2.o, you could specify the following:
ld -bh:4 -bpT:0x10000000 -bpD:0x20000000 -b64 /lib/crt0_64.o -lxlf90 -lxlsmp -lm -lc smpfile1.o smpfile2.o
The configuration file /etc/xlf.cfg lists these default libraries and linker options. By doing a sample compilation with the -# option, you can see exactly how the compiler would run the linker.
See the AIX Commands Reference for a description of the linker options.
To use the ld command to link non-SMP object files in a 32-bit environment, follow these guidelines:
For example, to link the object files file1.o and file2.o, you could specify the following:
ld -bh:4 -bpT:0x10000000 -bpD:0x20000000 /lib/crt0.o -lxlf90 -lm -lc
file1.o file2.o
The configuration file /etc/xlf.cfg lists these default libraries and linker options. By doing a sample compilation with the -# option, you can see exactly how the compiler would run the linker.
See the AIX Commands Reference for a description of the linker options.
To use the ld command to link non-SMP object files in a 64-bit environment, follow these guidelines:
For example, to link the object files file1.o and file2.o, you could specify the following:
ld -bh:4 -bpT:0x10000000 -bpD:0x20000000 -b64 /lib/crt0_64.o -lxlf90 -lm
-lc file1.o file2.o
The configuration file /etc/xlf.cfg lists these default libraries and linker options. By doing a sample compilation with the -# option, you can see exactly how the compiler would run the linker.
See the AIX Commands Reference for a description of the linker options.
If you need to link with ld options that are not part of the XL Fortran default, you can include those options on the compiler command line:
xlf95 -bhalt:2 -K -r file.f # xlf95 passes all these options to ld
The compiler passes unrecognized options, except -q options, on to the ld command.
If you specify the -qextchk compiler option, the linker may refuse to link object files containing mismatching procedure interfaces or common block definitions, allowing you to find these errors at link time, instead of trying to debug incorrect results.
If the linking problem can be isolated to a few names that do not resolve, perhaps because of uppercase letters in C names or trailing underscores added by the -qextname option, you can use the -brename linker option to change just those names:
xlf95 -brename:Old_Link_Name,new_link_name fort_prog.o c_prog.o
If you have .o or other object files that you compiled with an earlier version of XL Fortran, you can link them with object files that you compile with XL Fortran Version 8, subject to the following notes. The main XL Fortran libraries are libxlf90.a and libxlf90_r.a, but calls to older entry points in libxlf.a are still possible; the calls are passed to the new entry points in the main libraries, which makes the resulting programs slower than if everything is recompiled.
Notes:
Because the linker accepts executable files as input, you can link an existing executable file with updated object files.You cannot, however, relink executable files that were previously linked using the -qipa option.
If you have a program consisting of several source files and only make localized changes to some of the source files, you do not necessarily have to compile each file again. Instead, you can include the executable file as the last input file when compiling the changed files:
xlf95 -omansion front_door.f entry_hall.f parlor.f sitting_room.f \
master_bath.f kitchen.f dining_room.f pantry.f utility_room.f
vi kitchen.f # Fix problem in OVEN subroutine
xlf95 -o newmansion kitchen.f mansion
Limiting the number of files to compile and link the second time reduces the compile time, disk activity, and memory use.
XL Fortran allows your programs to take advantage of the AIX operating system facilities for both dynamic and static linking:
Dynamically linked programs take up less disk space and less virtual memory if more than one program uses the routines in the shared libraries. During linking, they do not require any special precautions to avoid naming conflicts with library routines. They may perform better than statically linked programs if several programs use the same shared routines at the same time. They also allow you to upgrade the routines in the shared libraries without relinking.
Because this form of linking is the default, you need no additional options to turn it on.
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
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:
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:
| XLF-Provided Function Name | Common Block or Subprogram Name You Cannot Use |
|---|---|
| mclock | times |
| rand | irand |
Be careful not to use the names of subroutines or functions without defining the actual routines in your program. If the name conflicts with a name from one of the libraries, the program could use the wrong version of the routine and not produce any compile-time or link-time errors.
If different versions of a routine occur in more than one library or object file, be careful to use the specific version that you want. Specify the file with the correct version as the first file on the command line or in the configuration file. If the file is a library, specify the appropriate -l option first on the command line. This technique does not apply to references between routines that are in the same shared library or to routines that are explicitly imported from one shared library to another.