Mail Archives: cygwin/2005/03/03/02:18:12
cgf wrote:
>On Wed, Mar 02, 2005 at 03:37:42PM +0100, Corinna Vinschen wrote:
>>On Mar 2 15:31, Corinna Vinschen wrote:
>>>On Mar 2 13:33, Dave Korn wrote:
>>>>Hm. We probably need to put a finit instruction into the autoload code
>>>>somewhere. wsock_init () looks like just the place...... now if I
>>>>just persuade the CVS code to build without a SIG11 (grmbl grmbl....)
>>>
>>>Hmm? -v please.
>>
>>I just added an finit call to wsock_init and it seems to work fine.
>>
>>Are there any non-FPU CPUs >= i386 out there which would choke on this
>>machine instruction? I guess not, but I'm not exactly fluent in ix86
>>history...
>
>I mentioned to Corinna on irc that I don't think that just calling finit
>is the right way to handle this. What if someone had already set the
>precision as they liked? Then loading winsock would reset it.
>
>cgf
Seeing this I got a fright, thinking mingw would have the same problem, with
very bad consequences for eg,
libgcj.a, which _always_ loads ws2_32.dll, and many, many other projects
But no, I get:
FPU test OK
FPU test OK
FPU test OK
FPU test OK
I think ws2_32.dll calls _fpreset() which is normally supplied by msvcrt.dll
Mingw provides its own _fpreset in libmingwex.a (crt_fp10.o) ) which sets
64-bit mantissa so all is well
If I load in mingw's crt_fp8.o module, which provides a stub for the msvcrt.dll
import _fpreset, I get the error.
A cygwin version of _fpreset (that calls finit) should do the trick, without the
overhead of fpu environment sav and restore
Danny
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -