Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!pasteur!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu (Pete Goodeve)
Newsgroups: comp.sys.ibm.pc
Subject: Help! Can't mix Microsoft Fortran and C!
Message-ID: <13873@agate.BERKELEY.EDU>
Date: 4 Sep 88 03:58:17 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: pete@violet.berkeley.edu (Pete Goodeve)
Organization: University of California, Berkeley
Lines: 53


I'm hoping somebody may have come across (and solved!) the problems that
I'm having before me.  Has anybody else found that the MicroSoft compilers
don't quite live up to their claim of interlanguage compatibility?

To explain my troubles I'll have to give a little background.  For a year
or so we've had a large ("Real Time") program running very nicely thank
you; it's used by students in their lab classes without problems.  It is
written largely in C, but also has a Fortran module linked in.  The C
compiler was Micrsoft 4.0 and the Fortran one was 3.3.

We were all perfectly happy until someone tried to use it on a machine that
(unlike those in the lab) didn't have a math coprocessor installed.  That
killed it.  With a little thought the reason became obvious: a normal
Fortran main program calls a bunch of initialization routines, one of which
checks whether the 8087 is present and if not makes the necessary
adjustments.  In our case the main program is in C, so no Fortran
initialization is ever done!  Apparently for most things it doesn't matter
-- both languages use the same stack, for instance -- but it screwed us in
this case.

Well, OK, we did find one line buried in the Fortran Users Guide that said
a mixed language program might have to do its own initialization, so I
tried a little test program that called INIX87 as described in the manual.
One little problem: that routine doesn't exist!  There are about ten entry
points that end in "87", but a few guesses at possibilities all led to
disaster.

So, we decided to forget this line of attack, and just link a version with
the alternate math library, which never uses the 8087.  No luck here
either.  There was a duplicate symbol in that and the C library that caused
instant death on any attempt to run.

The next stage was to look at newer revisions of the languages.  I set up a
directory with Fortran 4.1, configured for the large model (which we have
used all along), the Emulator library, and "C compatibilty".  I compiled a
short test program and tried to link it (with llibc+llibfore as specified
in the manual) -- "Duplicate Symbols" all over the place, plus a few
undefined.

Next step... move up to the C 5.1 runtime library (llibce).  Well, the
"undefined"s went away, but were more than made up for by the extra
multiple-definition errors.  There was a note in the error message that
said "use the /NOE option".  Well, that isn't documented anywhere, but what
the hell... Yeah, all those error messages disappeared (guess that's what
"/NOE" means -- "NO Error messages"?), but any attempt to run the program
just gave the error "No Floating Point loaded".  Dunh.  (So what the hell
did it think it was loading from all those libraries?  There were no
undefined symbols flagged.)

I've just about run out of ideas.  Anybody out there have any?

                                            -- Pete --