failed build with current mercurial sources

[Ben Abbott]

On Wednesday, March 19, 2008, at 02:43PM, "John W. Eaton" <jwe at bevo.che.wisc.edu> wrote:
>On 19-Mar-2008, Jaroslav Hajek wrote:
>
>| On Wed, Mar 19, 2008 at 7:35 AM, Jaroslav Hajek <highegg at gmail.com> wrote:
>| > >  OK, now I see that the problem that we tried to avoid by introducing
>| >  >  libcruft/blas-xtra/xzdotu.f will show up with the zdotc function
>| >  >  called from zqrhqv.  The following changes should avoid the problem,
>| >  >  but at the expense of not using an accelerated version of the zdotc
>| >  >  function.  If we can modify the configure script to detect these kinds
>| >  >  of incompatibilities in the Fortran compilers, then maybe we can
>| >  >  eventually remove the xzdotc.f and xzdotu.f files from Octave.
>| >  >
>| >
>| >  There are number of LAPACK subroutines in libcruft/lapack that call
>| >  ZDOTC as well.
>| >  Perhaps these should be modified, too. This will only cause problem if the user
>| >  has a BLAS (or ATLAS) library compiled by an incompatible compiler
>| >  (like g77), but no LAPACK (so that the subroutines from
>| >  libcruft/lapack get used).
>| >
>| >  What about just adding an extra version of ZDOTC to blas-xtra? It will
>| >  then get linked instead of the BLAS version, when ZDOTC is referenced
>| >  from libcruft. And no source changes needed.
>| >
>| 
>| Ugh, I see that this solves nothing, as it would confuse the linked
>| BLAS as well.
>| 
>| Hmm. I see two solutions:
>| 1. use user-supplied (and slow) xzdotc instead of zdotc through libcruft
>| (i.e. currently in libcruft/lapack and libcruft/qrupdate).
>
>The files in libcruft/lapack (and libcruft/blas) are irrelevant here
>because they are not used if we have an externally compiled lapack (or
>blas) library.  If they are compiled at the same time as other parts
>of Octave, then we can assume they are compiled by the same compiler,
>so there would be no compatibility issue.
>
>jwe
>

So if I configure using the options below, there will be no problem?

./configure '--prefix=/sw'  'FLIBS=/sw/lib/gcc4.3/lib/libgfortran.dylib' 'F77=/sw/bin/gfortran' '--infodir=${prefix}/share/info' '--mandir=${prefix}/share/man' '--libexecdir=${prefix}/lib' '-enable-shared' '-enable-dl' '--disable-static' '--without-mpi' '--with-hdf5' '--with-fftw' 'CFLAGS=-g -O3' 'LDFLAGS=-g -L/sw/lib' 'CPPFLAGS=-I/sw/include' 'CXXFLAGS=-g -O3' 'FFLAGS=-g -O3 -fbounds-check -ff2c' --cache-file=/dev/null --srcdir=.

Further, in this instance, the -ff2c is not needed?

I still plan on trying the to configure using the patch discussed earlier, but am also interested in building an operational octave ;-)

Ben

Ben