Re: 3.1.52 fails to build in hppa/linux

[Jaroslav Hajek]

On Sun, Feb 22, 2009 at 10:10 PM, Rafael Laboissiere <address@hidden> wrote:
> * Jaroslav Hajek <address@hidden> [2009-02-22 21:21]:
>
>> I don't recokn this is the reason. I bet that on the amd64,
>> OCTAVE_INT_USE_LONG_DOUBLE is defined, unlike on mipsel. Isn't that
>> so?
>
> Yes, I think so.  I do not have the full Octave sources on each machine, but
> looking from the code in configure.in:
>
> #if (SIZEOF_LONG_DOUBLE >= 10) && defined (HAVE_ROUNDL)
> #define OCTAVE_INT_USE_LONG_DOUBLE
> #endif
>
> and looking from the build log for the Debian octave3.1 package, version
> 3.1.52-4 [1]:
>
> * mipsel:
>  checking for roundl... yes
>  checking for long double... yes
>  checking size of long double... 8
>
> * i386:
>  checking for roundl... yes
>  checking for long double... yes
>  checking size of long double... 12
>
> * hppa:
>  checking for roundl... yes
>  checking for long double... yes
>  checking size of long double... 8
>
> * sparc:
>  checking for roundl... yes
>  checking for long double... yes
>  checking size of long double... 16
>
> * powerpc
>  checking for roundl... yes
>  checking for long double... yes
>  checking size of long double... 16
>
> [1] http://experimental.debian.net/build.php?pkg=octave3.1
>
> On amd64 the size of long double is 16.  This means that compilation of
> oct-inttype.cc fails on all architectures where OCTAVE_INT_USE_LONG_DOUBLE
> is undefined (mipsel and hppa) and succeed on the others (amd64, i386,
> sparc, and powerpc).  Note that the compilation on sparc fails for another
> reason (procstream.cc:32976802: error: expected unqualified-id).
>
> I would guess that the problem lies in the Octave sources, whenever
> OCTAVE_INT_USE_LONG_DOUBLE in undefined.  It does not seem to be a gcc 4.3.3
> bug.  BTW, I just tried to undef OCTAVE_INT_USE_LONG_DOUBLE in config.h and
> I can replicate the "ambiguous template specialization" compilation failure
> on amd64.
>

It still seems to be a gcc bug, just a different one. See my reply to
Marco. If you think the code is invalid, then please explain why.

> --
> Rafael
>



-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz