Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!romp!auschs!awdprime!stingray.austin.ibm.com!marc
From: marc@stingray.austin.ibm.com (Marc J. Stephenson/140000;1C-22)
Newsgroups: comp.unix.aix
Subject: Re: Upgrading to 3003 on an RS/6000
Message-ID: <6098@awdprime.UUCP>
Date: 25 Mar 91 14:25:27 GMT
References: <?P{=7=C@rpi.edu> <t=5fchb@rpi.edu>
Sender: news@awdprime.UUCP
Organization: IBM AWD, Austin
Lines: 31

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