Linking XL Fortran Programs

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.

Compiling and Linking in Separate Steps

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.

Passing Options to the ld Command

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 -Wl,<options...> -K -r file.f # xlf95 passes all these options to ld

The compiler passes unrecognized options, except -q options, on to the ld command.

Dynamic Linking

XL Fortran allows your programs to take advantage of the operating system facilities for dynamic linking:

• Dynamic linking means that the code for some external routines is located and loaded when the program is first run. When you compile a program that uses shared libraries, the shared libraries are dynamically linked to your program by default.

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

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:

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

  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.

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:

• Do not name a subroutine or function main, because XL Fortran defines an entry point main to start your program.
• Do not use any global names that begin with an underscore. In particular, the XL Fortran libraries reserve all names that begin with _xlf.
• Do not use names that are the same as names in the XL Fortran library or one of the system libraries. To determine which names are safe to use, you can use the nm command on any libraries that are linked into the program and search the output for names you suspect might also be in your program.
• If your program calls certain XLF-provided routines, some restrictions apply to the common block and subprogram names that you can use:
  

  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.

Contents