>>>>> "KM" == Konstantinos Margaritis <[EMAIL PROTECTED]> writes:
KM> I was about to fill a bug report on this, but I thought I
KM> asked first.
KM> In r-base 0.63.2/src/unix/system.c there are two references to
KM> the C function setfpucw
KM> #ifdef linux
KM> __setfpucw(_FPU_IEEE);
KM> #endif
KM> line 626:
KM> #ifdef linux
KM> __setfpucw(_FPU_DEFAULT);
KM> #endif
KM> There is an obvious problem as to why this package could not be
KM> built. The final executable get compiled and linked with g77,
KM> while this function is available ONLY in libc (version that I
KM> have is 2.0.100). Compilation was fine, but linking failed with
KM> an unresolved symbol in __setfpucw.
KM> I tried commenting out this line, and guess what, it
KM> succeeded. Then, I thought "yeah, but all tests will
KM> fail". Guess again, all tests were successful. Then I
KM> considered that this command was not really that needed after
KM> all and proceeded to building the package, which was also
KM> successful.
KM> So what do you say? I have also CC'd to the package
KM> maintainer. Is this a bug to fill a report, or is this specific
KM> to my specific setup (what is the status on other platforms reg
KM> this package?)
It is unfortunately a result of assuming that "linux" means the i386
architecture. Those calls are to set the floating point control word
on the Intel processors for IEEE behavior or for the default behavior.
Let me check with some of the folks in the R-core group on what is the
best way to trap on both Linux and Intel for those calls. It may even
be possible to avoid those calls entirely. I believe that the Linux
standard now is to default to IEEE floating point rounding, even on
the Intel processors.
