Re: [OctDev] Octave-3.6.4-rc0 Mingw gcc4.7.2 panics

[Michael G. <mic...@gm...>]

On Fri, Nov 16, 2012 at 11:52 AM, Philip Nienhuis <pr....@hc...>wrote:

> nitnit wrote:
> > Hello all,
> >
> > I have tried to re-build Octave-3.6.4-rc0 with an updated mingw/msys
> > environment (recent repository with gcc-4.7.2).
> >
> > I have used Tatsuros libraries which have been built with gcc-4.6.2.
> >
> > I had to rebuild lapack and reference blas in order for the configure
> script
> > to succeed. All other libs are those which have been pre-compiled by
> Tatsuro
> > with gcc-4.6.2.
> >
> > I could build octave successfully but with make -check, I am getting a
> seg.
> > fault in eigs.cc:
> >
> >    ...
> >    src\DLD-FUNCTIONS\dot.cc ............................... PASS    3/3
> >    src\DLD-FUNCTIONS\eig.cc ............................... PASS   20/20
> >    src\DLD-FUNCTIONS\eigs.cc ..............................panic:
> > Segmentation violation -- stopping myself...
> > make[1]: [check] Error 3 (ignored)
> > make[1]: Leaving directory `/c/OctaveB/octave-3.6.4-rc0/test'
> >
> > Any ideas about cab cause it ?
>
> In principle I'd agree with Michael's suggestion to rebuild ALL deps
> with gcc 4.7.2. Who knows what other hidden problems pop up with a mixed
> build chain. In this respect the various BLAS<->arch segfaults come to
> mind.
>

For the record, such problems are easily triggered. Consider a piece of
fortran code, compiled with 4.6.x, making a call to EXP with a complex
number. This is translated by gcc/gfortran into a call to cexp, which is
provided by libgcc, hence 4.7.x. This function returns a double complex
structure (> 8 bytes), so the fortran code and libgcc will use different
calling conventions, leading to stack corruption.

Michael.