pete@violet.berkeley.edu (Pete Goodeve) (09/04/88)
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 --cdold@starfish.Convergent.COM (Clarence Dold) (09/06/88)
From article <13873@agate.BERKELEY.EDU>, by pete@violet.berkeley.edu (Pete Goodeve): > 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. [...] > 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 found that I had to use the /NOE in order to use wildcard expansion (pg 75 of the programmer's guide). It appears(?) to negate the /E option to 'prprocess to standard output' ( qcl /help ). The run-time error R6002 implies that you have FPU-only code from C. At the time QuickC is installed, you can elect an FPU environment, or it can be invoked with the /FPi87 to QCL. You will also need to change your default libraries. I find this switch to be most inconvenient. Although it runs contrary to pg 204 of the programmer's guide, my tests indicate that code compiled with the FP Emulator will take advantage of an existing FPU, as well as run without one. Code compiled for ..87 will only run on an ..87, causing the R6002 error on machines without. The only savings in ..87 code is some disk space, and perhaps load time. -- Clarence A Dold - cdold@starfish.Convergent.COM (408) 435-5274 ...pyramid!ctnews!mitisft!professo!dold P.O.Box 6685, San Jose, CA 95150-6685