Upgrading to 3003 on an RS/6000
Jim Hudgens
hudgens at sun13.SCRI.FSU.EDU
Sun Mar 24 00:36:26 AEST 1991
In article <?P{=7=C at rpi.edu> borchers at aix01.aix.rpi.edu (Brian T. Borchers) writes:
We recently upgrades to 3003. I have a collection of Fortran and C
routines called grafic (a simple scientific plotting package). When
I tried to link with this library after the upgrade, ld reported that
.#SYSTEM and .#ABORT were undefined. I took this to mean that I should
recompile everything. After I recompiled the library and the main
program, I still had the undefined symbols.
Interesting, cause I am dealing with the same problem, a program with
lots of C and fortran routines. Previous to this upgrade, the fortran
compiler, when given code like:
call signal(...)
call system(...)
call abort(...)
call getenv(...)
(and undoubtedly others, as well.) would produce the names in the
object module of the form:
U .#ABORT
U .#GETENV
U .#SIGNAL
U .#SYSTEM
However, under 3003, these names were converted into:
U .abort
U .getenv
U .signal
U .system
With programs which link in C and fortran, and do similar type
operations (getenv, signal, abort, etc.) now find that the names given
by the fortran and C compilers are identical, and are apparently
freely interlinkable, even though the arguments are quite different.
What we are seeing is that the programs link without error, and
instantly die, if the C version of the program uses one of these
routines. Probably, the C reference to {getenv, signal, system,
abort} are getting linked to the fortran library routines of the same
name:
nm /usr/lib/libxlf.a | grep ..... | grep T
00001b90 T .getenv
00000000 T .getenv
00009b58 T .abort
00000000 T .signal
00000000 T .system
nm /lib/libc.a | grep ..... | grep T
000066c8 T .getenv
00020884 T .signal
00026cec T .system
00016898 T .abort
Since the C getenv routine takes one argument, and returns a
string, and the fortran getenv takes two arguments, mayhem results
if the fortran libraries' getenv actually satisfies the .getenv call in the
C module.
Actually, I understand the reason for making this change to the
fortran compiler. Someone probably had a fortran routine they wrote
called signal or abort, and bitterly complained that it wasn't getting called,
and that signal (or abort) was a perfectly valid fortran routine name.
But still, I feel compelled to complain. :-)
What I am curious about, is what is an easy workaround to get the
original behavior back. Also, where is there a detailed description
of how the ld program actually works. I am almost certain that there
is some flag which might exert some control over this process. And the
frequent duplication of identical names in the libraries (note the
two getenv's in the fortran library namelist above) makes me wonder.
Anyone have any pointers to the relevent document inside info?
JHH
--
Jim Hudgens Supercomputer Computations Research Institute
hudgens at sun13.scri.fsu.edu
More information about the Comp.unix.aix
mailing list