John W. Eaton schrieb:
On 14-Sep-2007, Thomas Treichl wrote:
| I didn't get any further in the discussion with Apple so my wish
would be that | something like the attached patch could be added
to the Octave sources before | the next tarball will be build. I
didn't implement anything in the file | acx_blas.m4 because it
seems that we only set LIBS flags and no CFLAGS. Like | I've
already told you, if any changes in Apple's vecLib are made then
for newer | versions (but not for past versions of vecLib). As
long as we support Octave.app | for OS X 10.3 and 10.4 we need
this fix then (I actually would say at least 2..3 | years). Thanks,
For me, one of the great things about free software is that it can be
fixed by the user, so there is no need for working around bugs in
other packages. Instead, you fix the other package. So I would
really prefer that we not litter the Octave sources with lots of
workarounds for bugs in other software. But if you must, then it
would be much better to fix this problem with a feature test instead
of just checking a system type.
jwe
Ok John, I keep on going with the Apple people and I hope the bug
will be fixed for future versions of this library. Meanwhile I try
to fix this for Octave.app locally by applying a patch before
building Octave - this doesn't really matter because there are some
minor changes that I must patch before building Octave, eg. comment
out the 'sed' lines <I should learn m4 for writing tests, hhhmmm...>
However, I made mistakes in my patch that I sent before - I'm sorry
for that. Not CFLAGS should be changed but CPPFLAGS and my test
functions should do the right tests... This patch is not meant for
the Octave sources but is meant for Mac users who want to give it a
try or other distribution packagers that build Octave with vecLib.
Thomas
--- octave/configure.in 2007-09-14 21:04:57.000000000 +0200
+++ octave/configure.in 2007-09-14 21:05:26.000000000 +0200
@@ -852,6 +852,24 @@
ACX_LAPACK([BLAS_LIBS="$LAPACK_LIBS $BLAS_LIBS"],
[LAPACK_DIR="lapack"])
AC_SUBST(BLAS_DIR)
AC_SUBST(LAPACK_DIR)
+# Checks if compiled with Apple's vecLib framework. If true then we
+# know there is a bug in the 'dgelss_' implementation. Set the
#define
+# HAVE_MACOSX_VECLIB_BUG and solve the problem by the workaround in
+# the file dMatrix.cc. If not sure that this bug still exists for any
+# newer vecLib versions cf.
+# http://www.nabble.com/Re%3A-consistent-crash-using-gammrnd-
tf4077367.html#a11672466
+warn_vecLib_bug=""
+case "$canonical_host_type" in
+ *-*-darwin*)
+ case "$BLAS_LIBS" in
+ *-framework\ vecLib*)
+ warn_vecLib_bug="setting workaround for vecLib's dgelss_
function"
+ AC_MSG_WARN($warn_vecLib_bug)
+ CPPFLAGS="$CPPFLAGS -DHAVE_MACOSX_VECLIB_BUG"
+ ;;
+ esac
+ ;;
+esac
# Check for AMD library
AMD_LIBS=
--- octave/liboctave/dMatrix.cc 2007-09-14 21:04:58.000000000 +0200
+++ octave/liboctave/dMatrix.cc 2007-09-14 21:05:53.000000000 +0200
@@ -2083,7 +2083,17 @@
(*current_liboctave_error_handler) ("unrecoverable error in
dgelss");
else
{
+
+#if defined (HAVE_MACOSX_VECLIB_BUG)
+ // Have a look for a more detailed explanation about this
+ // bug of MacOSX in the file configure.in.
+#define mymax(a, b) ( (a)>(b) ? (a) : (b) )
+#define mymin(a, b) ( (a)<(b) ? (a) : (b) )
+ lwork = 3 * mymin(m,n) + mymax(mymax(mymax(m,n), nrhs),
2*mymin(m,n));
+#else
lwork = static_cast<octave_idx_type> (work(0));
+#endif // HAVE_MACOSX_VECLIB_BUG
+
work.resize (lwork);
F77_XFCN (dgelss, DGELSS, (m, n, nrhs, tmp_data, m, presult,
@@ -2106,6 +2116,11 @@
return retval;
}
+/* Test if the vecLib bug is still there in function Matrix::lssolve
+%!test A=[1:55]'/[1:55]'; # always works even if the bug is there
+%!test A=[1:1000]'/[1:1000]'; # Octave should crash if bug is
still there
+*/
+
ComplexMatrix
Matrix::lssolve (const ComplexMatrix& b) const
{