Mail Archives: djgpp/1999/10/05/08:09:35
In article <7skr62$7ff AT fingers DOT shocking DOT com>,
I <ralph AT fingers DOT shocking DOT com> wrote:
>
>The 387 emulation library seems to have a problem. I compiled the
>little program below with gcc2.95 and DJGPP, using the following
>command lines in an MSDOS 6.22 OS on a 486SX25:
>
>gcc -s -O2 -Wall -c sqrt.c
>gcc -s -O2 -Wall -o sqrt.exe sqrt.o -lemu
>
>No errors or warnings appear during compilation or linking. Running
>the resulting program (SQRT.EXE) produces no output at all, and I was
>able to terminate the program with CTRL-C. Here is the program
>source:
>
>==============================cut here==============================
>
>/*Demonstrate the EMU387 error.*/
>
>#include <math.h>
>#include <stdio.h>
>
>int main (void) {
> printf ("%g\n", sqrt (2.0));
> return (0);
>} /*main*/
>
>==============================cut here==============================
After some email and file exchanging, Eli Zaretskii and I determined
that this problem was caused by a bug in the emulation library in
version 2.02 and earlier DJGPP gcc distributions. The 387 emulation
library for version 2.03 seems to fix this problem. I found that
several of the many functions listed in the math.h header would hang
with the older emulation library installed, while all of the functions
produced output once the new library was installed.
--
Ralph. N6BNO. Wisdom comes from central processing, not from I/O.
ralph AT shocking DOT com http://www.shocking.com/~ralph
Opinions herein are either mine or they are flame bait.
SEC (x) / COSEC (x) = (TAN (x) / COTAN (x)) ^ 2
- Raw text -