C/FORTRAN intermixing problem

[Bjorn Engsig]

Article <19946 at hydra.gatech.EDU> by scott at 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 at oracle.com, bengsig at oracle.nl

            "Stepping in others footsteps, doesn't bring you ahead"