Tim, I've started playing with Xfractint and Cygwin and almost have it compiling all the way. Unfortunately, the header file for ncurses is missing. Cygwin includes several different ncurses library versions, but not the development sources. Hmm, but maybe they do and I just haven't gotten them yet. I haven't downloaded any of the source files at this point. I used some brute force techniques to get to the point I am currently at. The problems have mostly been redefinition of functions or #defines. I'll go back and clean them up after I get it to compile and run. Jonathan
Tim, Having found the ncurses development library, and with a couple of other brute force fixes, Xfractint now compiles. It doesn't link. For some reason the long double math functions (sqrtl, etc) can't be found. From what I can see, the linker shouldn't even be looking for them. Any thoughts? Jonathan
Jonathan wrote:
For some reason the long double math functions (sqrtl, etc) can't be found. From what I can see, the linker shouldn't even be looking for them. Any thoughts?
Is there a long double type in the compiler? Is it 80 bits? If so it would probably be possible to use inline assembler, because there probably are coprocessor functions. The arbitrary precision code needs long double for handling the exponents, but there's a define to turn it off if long double is not available, as it usually isn't for gcc. It does no good to have long double if all the extra bits go to the mantissa and not the exponent. There's probably just a wrong define setting that makes the arbitray precision code need long double. FWIW (probably not much) Google turned up: extern long double __QNANL; long double sqrtl (long double x) { if (x < 0.0L ) { errno = EDOM; return __QNANL; } else { long double res; asm ("fsqrt" : "=t" (res) : "0" (x)); return res; } } But of course this would be useless without an 80 bit long double type like Microsoft C has. Tim
Tim,
Is there a long double type in the compiler? Is it 80 bits? If so it would probably be possible to use inline assembler, because there probably are coprocessor functions.
The compiler is a version of gcc.
There's probably just a wrong define setting that makes the arbitray precision code need long double.
Still haven't found it. I have cleaned up some of the other defines and folded them back into the developer's version. There are some issues with built-in defines for _fastcall and __cdecl which I don't see any clean ways around. I could add another define for CYGWIN, but that's rather ugly. The variable infinity is declared under Cygwin. The declaration we have in /unix/fpu087.c gets in the way of this. Jonathan
Tim, Xfractint now compiles cleanly under Cygwin. And runs very nicely with a windows manager installed. I am using fvwm2 because it was easiest to set up and get running. IOW, I don't know enough about any of the other window managers available to get them running. I did move the XFRACT code for stackscreen() and its associated functions from realdos.c to unix/video.c so that we don't need any #include curses.h in the common directory. I am contemplating doing this for other sections of code. To make it cleaner, I should also move the DOS stackscreen() functions to the dos directory. I would like to make changes so that Xfractint doesn't need to use curses for text screens unless the disk video mode is being used. Jonathan
participants (2)
-
Jonathan Osuch -
Tim Wegner