Re: howto debug this damned thing?

[Craig Burley <burley at gnu dot org>]

>The only thing i could assume is, that it tries to use the native
>compilers write or some of its helper routines and not those of g77.
>the code works fine if i compile the whole program with g77.
>But it is a big circuit simulator which has to run very fast, so i 
>would like to stick with the native compiler for that.

I wonder if the problem is that g77's run-time library (libf2c aka libg2c)
defines external names that conflict with Sun's.  I'm pretty sure there
are such conflicts, and that they include I/O support routines.  That
might explain what you're running into.

One way to check, I suppose, is to link all your g77-compiled code into
one "executable", and all your Sun-f77-compiled code into another, with
no libraries linked with them.  In each case, you should get lots of
undefined-symbol errors.

Look through these two sets of errors.  If there are any identically
named symbols being referenced, that's a suggestion of a possible
collision.

Some collisions are okay.  If neither Fortran run-time library defines
a collided name, i.e. only one underlying (or overlying) library
defines it, it's not really a collision.  `exit' might be an example of
this.

Other collisions might seem okay because they're leaf routines, at
least conceptually.  E.g. `dsqrt_' might be okay even if both Fortran
libraries define it.  However, that's true only if the interface
(you could say, the function's design) is identical, meaning only
the implementation differs.  In some cases, e.g. `cabs_', this has
turned out to not be the case -- Sun's Fortran library has a different
idea of *how* to receive arguments and return the result than g77's,
so even though both libraries do the same thing conceptually, the
disagree on how the interface is done.

Bad collisions are basically anything involving I/O, e.g. `s_rfse' or
whatever, because Sun Fortran and g77 definitely are not compatible at
this level the way, e.g., g77 and f2c are, or (apparently) g77 and
Portland Group Fortran.

The bad collisions are an overt problem because you can't really link
the g77-called versions only to the g77 calls and the f77-called
versions only to the f77 calls.  Even if you could, there's likely
to be underlying (support) routines *they* call that have colliding
names as well.

Even if you could work all *that* out, you'd still have the problem of
not being able to OPEN a file in g77-compiled code and then do anything
with it (or even test to see if the Fortran unit number was in use)
in f77-compiled code, and vice versa.  Some "leafy" things, like
internal I/O, you might get away with.

We tell most people to simply not mix g77-compiled code with code
compiled via any other compiler except f2c (and as I say, I think
Portland Group says it's okay to combine theirs, or one or theirs,
with g77, but I'm repeating gossip I've read on comp.lang.fortran).

However, you've done some pretty gut-check-type work just getting to
this point, so it seems to me you can probably cope with these grody
details.  I hope you're able to make some use of the above, even if it
just convinces you to stick with one or the other compiler for a
particular executable (which makes generating libraries a pain, I know!).
But it might give you some indications of how restructuring a library
or program might permit such combining.

        tq vm, (burley)