My compilation of Octave 3.2.3 in EPEL 5 at http://koji.fedoraproject.org/koji/buildinfo?buildID=152477 fails on i386 with make[2]: Entering directory `/builddir/build/BUILD/octave-3.2.3/test' ./build_sparse_tests.sh ../run-octave --norc --silent --no-history ./fntests.m . fatal: lo_ieee_init: floating point format is not IEEE! Maybe DLAMCH is miscompiled, or you are using some strange system without IEEE floating point math? The same bug was encountered on Fedora 12 https://bugzilla.redhat.com/show_bug.cgi?id=510841#c35 and the problem was revealed to be a wrong compilation flag used for dlamch https://bugzilla.redhat.com/show_bug.cgi?id=520518#c0 which I suspect is behind the problems on RHEL 5, too.
I have verified that this is the case: $ gfortran -o dlamchtst dlamchtst.f -llapack $ ./dlamchtst Epsilon = 2.220446049250313E-016 Safe minimum = 2.225073858507201E-308 Base = 2.00000000000000 Precision = 4.440892098500626E-016 Number of digits in mantissa = 53.0000000000000 Rounding mode = 0.00000000000000 Minimum exponent = -1021.00000000000 Underflow threshold = 2.225073858507201E-308 Largest exponent = 1024.00000000000 Overflow threshold = 1.797693134862316E+308 Reciprocal of safe minimum = 4.494232837155790E+307 according to bug #520518, the result should be Epsilon = 1.11022302462515654E-016 Safe minimum = 2.22507385850720138E-308 Base = 2.0000000000000000 Precision = 2.22044604925031308E-016 Number of digits in mantissa = 53.000000000000000 Rounding mode = 1.0000000000000000 Minimum exponent = -1021.0000000000000 Underflow threshold = 2.22507385850720138E-308 Largest exponent = 1024.0000000000000 Overflow threshold = 1.79769313486231571E+308 Reciprocal of safe minimum = 4.49423283715578977E+307
ping?
If you really want this fixed anytime soon, please contact www.redhat.com/support to raise priority of this issue. Bugzilla is just bug tracker (for the case of RHEL bugs), package bugfix updates are scheduled based on support requests.
I am sorry, but it is now too late in the RHEL-5 release cycle. RHEL-5.10 (the next RHEL-5 minor release) is going to be the first production phase 2 [1] release of RHEL-5. Since phase 2 we'll be addressing only security and critical issues. This issue will be fixed in RHEL-7 therefore I am closing the bug as NEXTRELEASE.