Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!asuvax!noao!ncar!gatech!prism!mailer.cc.fsu.edu!sun13!sun13.scri.fsu.edu!hudgens
From: hudgens@sun13.SCRI.FSU.EDU (Jim Hudgens)
Newsgroups: comp.unix.aix
Subject: Re: Upgrading to 3003 on an RS/6000
Message-ID: <HUDGENS.91Mar23093626@sun13.sun13.SCRI.FSU.EDU>
Date: 23 Mar 91 14:36:26 GMT
References: <?P{=7=C@rpi.edu>
Sender: hudgens@sun13.scri.fsu.edu
Organization: SCRI, Florida State University
Lines: 80
In-reply-to: borchers@aix01.aix.rpi.edu's message of 22 Mar 91 19:36:37 GMT


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