borchers@aix01.aix.rpi.edu (Brian T. Borchers) (03/23/91)
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. Am I right in assuming that .#SYSTEM and .#ABORT are new to this release? Is it likely that there is a mismatch of the compilers and libraries?
hudgens@sun13.SCRI.FSU.EDU (Jim Hudgens) (03/23/91)
In article <?P{=7=C@rpi.edu> borchers@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@sun13.scri.fsu.eduborchers@aix01.aix.rpi.edu (Brian T. Borchers) (03/25/91)
It appears that my earlier problem with .#SYSTEM and .#ABORT had nothing
to do with combining C and Fortran. The simple 2 line program:
CALL SYSTEM('ls')
END
also fails to link properly. I'm assuming at this point that the compiler
and libraries weren't properly installed during the upgrade to 3003.marc@stingray.austin.ibm.com (Marc J. Stephenson/140000;1C-22) (03/25/91)
In article <t=5fchb@rpi.edu> borchers@aix01.aix.rpi.edu (Brian T. Borchers) writes: >It appears that my earlier problem with .#SYSTEM and .#ABORT had nothing >to do with combining C and Fortran. The simple 2 line program: > > CALL SYSTEM('ls') > END > >also fails to link properly. I'm assuming at this point that the compiler >and libraries weren't properly installed during the upgrade to 3003. As was mentioned in another posting, they had to make a change to the FORTRAN (xlf) compiler in generating calls to various routines (system, abort, signal, maybe some others) to accomodate users who had their own versions of these routines. Formerly, xlf had generated calls to .#SYSTEM for instance, and that just called .system from libc. This was done without the users knowledge, and in most cases it doe snot matter; unfortunately, if someone had their own SYSTEM subroutine, it would not be used. I've been told that the old compiler behavior is non-standard because intrinsic subroutines are not allowed (only functions). So, the compiler now generates a call to .system, so it can be replaced. The new .system and .abort should be in the 3003 xlfrte update in libxlf.a - lpp history = 01.01.0002.0003 (or better). Unfortunately, the prerequisite file for xlfcmp does not seem to force that that level of xlfrte be on your system. Hmmm. In any case, you need to make sure that your xlfrte is updated if your xlfcmp is updated to 3003. -- Marc Stephenson IBM PSPA (Personal System Programming - Austin,TX) DISCLAIMER: The content of this posting is independent of official IBM position. marc@stingray.austin.ibm.com VNET: MARC at AUSVMQ IBM T/L: 793-3796
freese@dalvm41b.vnet.ibm.com ("Bradley T. Freese") (05/15/91)
borchers@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. > > Am I right in assuming that .#SYSTEM and .#ABORT are new to this release? > > Is it likely that there is a mismatch of the compilers and libraries? Yes, this is a known mismatch. The upgrade redefined/renamed three symbols: .#SYSTEM; .#ABORT; and .#GETENV. The change was done to improve ANSI compliance. Since you are still getting the error, I suspect that you missed a library somewhere. To find it, I recommend linking with the 'ld' flag "-bloadmap:<filename>", where <filename> is the name of a file of your choice. After doing the link, this file will indicate what object module is still calling the symbols. Good luck.