module. Put one entrypoint name on a line. The -bI:/lib/libg.exp line
is required for proper functioning of the program. The -berok argument
at this time (you would think -r would work here, but it doesn't seem to).
into the object. The -lxlf, of course, is the xlf library.
intermediate.o \
/lib/crt0.o -lm -lc
Note the absence of -berok. After this link, all references should
be resolved (unless you're doing a multistage link and making another
intermediate).
NOTE THE ORDER OF MODULES. This is extremely important if, for example,
you had a subroutine named "load" in your Fortran stuff. Putting the
C libraries before the intermediate module would make the C "load"
the operable definition, rather than the Fortran version EVEN THOUGH
THE FORTRAN MODULE HAS ALREADY BEEN THROUGH A LINK AND ALL REFERENCES
TO THE SYMBOL ARE CONTAINED IN THE FORTRAN MODULE. This can
be extremely difficult to find (trust me on this one :-) Is this
a bug, a feature, or what?
[As mentioned in section 2.03 of this article, it is a feature that you
can replace individual objects in linked files, ed.]
The result will be a slightly larger object than normal. (I say slightly
because mine went up 5%, but then it's a 2 MB object :-)
Comments & Caveats:
From the documentation the -r argument to the linker should do what
-berok does. It does not. Very strange results come from using the
-r argument. I have not been able to make -r work in a sensible manner
(even for intermediate links which is what it is supposed to be for).
Note from Mike Heath (mike@pencom.com):
'ld -r' is essentially shorthand for 'ld -berok -bnogc -bnoglink'.
Certainly, using -berok with an export file (so garbage collection
can be done) is preferable to ld -r, but the latter is easier.
When binding an intermediate module, use an export file to define the
entry points you want visible in the later link. If you don't do this,
you'll get the dreaded "unresolved reference" error. Import files name
entry points that will be dynamically resolved (and possibly where).
If you are in doubt about what parameters or libraries to link, use the
-v arg when linking and modify the exec call that shows up into
an ld command. Some thought about the libraries will usually yield an
idea of when to use what. If you don't know what an argument is for,
leave it in. It's there for a purpose (even if you don't understand it).
Watch the order of external definitions (ie, libraries) when more than
one version of a routine may show up, eg "load". The first one defined
on the ld command line is the winner.
The getenv (and system and signal) problem is a problem that started out
minor, got somewhat worse in 3003 and, eventually will be correctly fixed.
Basically, you should extract the 3002 version of these three routines
from xlf.a before doing the update and save them away, then link these
routines in if you use these Fortran system services.
------------------------------
Subject: 3.03: How do I check if a number is NaN?
From: sdl@glasnost.austin.ibm.com (Stephen Linam)
NaN is "Not a Number". It arises because the RISC System/6000 uses
IEEE floating point arithmetic.
To determine if a variable is a NaN you can make use of the property
that a NaN does not compare equal to anything, including itself.
Thus, for real variable X, use
IF (X .NE. X) THEN ! this will be true if X is NaN
Floating point operations which cause exceptions (such as an overflow)
cause status bits to be set in the Floating Point Status and Control
Register (FPSCR). There is a Fortran interface to query the FPSCR, and
it is described in the XLF Fortran manuals -- I don't have the manuals
right here, but look for FPGETS and FPSETS.
The IBM manual "Risc System/6000 Hardware Technical Reference - General
Information" (SA23-2643) describes what floating point exceptions can
occur and which bits are set in the FPSCR as a result of those exceptions.
------------------------------
Subject: 3.04: Some info sources on IEEE floating point.
1. ANSI/IEEE STD 754-1985 (IEEE Standard for Binary Floating-Point
Arithmetic) and ANSI/IEEE STD 854-1987 (IEEE Standard for
Radix-Independent Floating-Point Arithmetic), both available from IEEE.
2. David Goldberg, "What Every Computer Scientist Should Know About
Floating-Point Arithmetic", ACM Computing Surveys, Vol. 23, No. 1,
March 1991, pp. 5-48.
------------------------------
Subject: 3.05: Why does it take so long to compile "hello world" with xlf?
[read 2.07]
------------------------------
Subject: 4.00: GNU and Public Domain software
GNU software comes from the Free Software Foundation and various other
sources. A number of ftp sites archive them. Read the GNU license for
rules on distributing their software.
Lots of useful public domain software have been and continue to be ported
to the RS/6000. See below for ftp or download information.
------------------------------
Subject: 4.01: How do I find sources?
From: jik@GZA.COM (Jonathan Kamens)
There is a newsgroup devoted to posting about how to get a certain
source, comp.sources.wanted. An archive of information about sources,
including FTP sites is available from
------------------------------
Subject: *4.02: Are there any ftp or WWW sites?
SMIT-installable precompiled packages of popular freeware for AIX 4.x at