scott@prism.gatech.EDU (Scott Holt) (01/20/91)
I am attempting to port a graphics library (di3000), written in FORTRAN, which makes use of some C support routines. One of the C support routines is used to return the value of an environment variable to the calling FORTRAN routine; consequently, it calls getenv. The problem comes from the fact that XLF provides a FORTRAN callable GETENV and, of course, programs get linked with the FORTRAN version. Thus, anything which calls getenv, expecting it to come from the C runtine library, blows up. Now, my first guess would be to simply replace the offending support routine with a FORTRAN implementation wich calls the FORTRAN GETENV. This would result in a minimal number of changes to existing code. Unfortunately, there are a number of other support routines which call getenv, expecting it to be from the C runtime library and they cannot so easily be rewritten. So much for that. Another (not so hot, but possible) option is to implement my own getenv for the C code, name it something else (say Cgetenv) and replace all the calls in to getenv in C code to calls to this routine. This would be trivial if I had source to AIX 8-). Before I try to do this, I would like to know if there is an easier way around my problem. I thought about simply yanking getenv.o and whatever it needed from libc.a, but I don't see it there. Also, I am not too sure what the implications would be for the version of GETENV in the FORTRAN runtime library. Basicly, what I would really like to find is a way to tell the loader that one set of routines is to satisfy its external references from the C runtine library, and another from the FORTRAN library. Any help would be appreciated. -Scott
bengsig@dk.oracle.com (Bjorn Engsig) (01/21/91)
Article <19946@hydra.gatech.EDU> by scott@prism.gatech.EDU (Scott Holt) says: | |I am attempting to port a graphics library (di3000), written in FORTRAN, |which makes use of some C support routines. One of the C support routines |is used to return the value of an environment variable to the calling |FORTRAN routine; consequently, it calls getenv. I've posted about this once before. The solution I found then was to add -lc when linking your fortran program, this will cause the C version of getenv to be used. I am still left with the question of weather other routines behave like this, i.e. weather C and fortran share other routines with the same name but different interface. | | I thought about simply yanking getenv.o and |whatever it needed from libc.a, but I don't see it there. No you don't. libc.a is not very much more than one big shared object shr.o, which basicly makes is difficult to write your own version of any routine. [Asking if this is possible to comp.lang.c would also give you a few flames] | |Basicly, what I would really like to find is a way to tell the loader |that one set of routines is to satisfy its external references from |the C runtine library, and another from the FORTRAN library. Since the linker works by loading ALL object and libraries into memory, then builing a complete symbol table and make the object in one 'go', you often need a bit of luck in doing this. My solution above might therefore not work in all cases. As a last resort, you could do a stepwise link with the -r option, adding one library at a time, thus simulation linkers know from other Unix platforms. -- Bjorn Engsig, ORACLE Corporation, E-mail: bengsig@oracle.com, bengsig@oracle.nl "Stepping in others footsteps, doesn't bring you ahead"
rudy@chukran.austin.ibm.com (01/22/91)
This bug is a problem on the 3002 update, but is fixed in 3003. The advertised workaround is to link like so: xlf *.o -lc ld -r -o cobjects .... abc.o -lc and then link everything else: xlf -o fort.ex cobjects.... f.o ********************************************************************* Rudy Chukran | EMAIL: IBM AIX Porting Center | RSCS: CHUKRAN at AUSTIN 11400 Burnet Rd. | AWDnet: rudy@chukran.austin.ibm.com Internal ZIP 2830 | internet: chukran@austin.iinus1.ibm.com Austin, Texas 78758 | Voice: 512-838-4674 Tieline: 678-4674 *********************************************************************