octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3.1.52 fails to build in hppa/linux


From: Jaroslav Hajek
Subject: Re: 3.1.52 fails to build in hppa/linux
Date: Mon, 23 Feb 2009 08:40:55 +0100

On Mon, Feb 23, 2009 at 7:58 AM, Jaroslav Hajek <address@hidden> wrote:
> On Mon, Feb 23, 2009 at 7:27 AM, Marco Atzeri <address@hidden> wrote:
>>
>> --- Lun 23/2/09, John W. Eaton  ha scritto:
>>
>>> Da: John W. Eaton
>>> Oggetto: Re: 3.1.52 fails to build in hppa/linux
>>> A: address@hidden
>>> Cc: "Jaroslav Hajek" , address@hidden
>>> Data: Lunedì 23 febbraio 2009, 02:02
>>> On 22-Feb-2009, Marco Atzeri wrote:
>>>
>>> |
>>> | --- Dom 22/2/09, Jaroslav Hajek  ha scritto:
>>> |
>>> | > >> And is OCTAVE_INT_USE_LONG_DOUBLE defined
>>> in
>>> | > config.h? Do
>>> | > >> you get the
>>> | > >> same error as Rafael? You see, lines 511
>>> and 514
>>> | > in
>>> | > >> oct-inttypes.cc
>>> | > >> are inside an #ifdef
>>> OCTAVE_INT_USE_LONG_DOUBLE
>>> | > block.
>>> | > >>
>>> | > >>
>>> | > >>
>>> | > >> --
>>> | > >> RNDr. Jaroslav Hajek
>>> | > >
>>> | > > OCTAVE_INT_USE_LONG_DOUBLE is defined
>>> | > >
>>> | > > same errors from 511 to 516
>>> | > >
>>> | > > Regards
>>> | > > Marco
>>> | >
>>> | > Whoa, that's wicked. Those lines should not even
>>> be
>>> | > compiled, then (I
>>> | > meant, of course, ifndef block in the previous
>>> message).
>>> | > Can you maybe
>>> | > try posting just the preprocessor output?
>>> | >
>>> | > The easiest way to get it is to cd to liboctave/, do
>>> | > make pic/oct-inttypes.o
>>> | >
>>> | > then copy the command shown to compile, but replace
>>> | > "-c" by "-E" and
>>> | > redirect -o to a suitable file. It will be probably
>>> too
>>> | > large to post
>>> | > it on the mailing list.
>>> |
>>> | uploaded on
>>> | http://matzeri.altervista.org/octave/
>>> |
>>> | gcc -E output    oct-inttypes.E
>>> | gcc -c logs      oct-inttypes.log-20090222-202140
>>> | full command     oct_int.sh
>>>
>>> Does the attached change avoid the problem for you?  It
>>> allows me to
>>> build Octave with GCC and OCTAVE_INT_USE_LONG_DOUBLE
>>> undefined.  So
>>> maybe this is a GCC bug because I didn't change any
>>> code, I just moved
>>> some function definitions to a header file.  But I did
>>> remove some
>>> explicit instantiations, and I'm not sure I fully
>>> understand the rules
>>> for instantiating templates, especially when some are
>>> explicitly
>>> instantiated and some are not (at least I think that is
>>> true for the
>>> classes defined in oct-inttypes.{h,cc}).
>>>
>>> I also don't see how these lines could be compiled if
>>> OCTAVE_INT_USE_LONG_DOUBLE is defined.
>>>
>>> The lines to define it in config.h are
>>>
>>>   #if (SIZEOF_LONG_DOUBLE >= 10) && defined
>>> (HAVE_ROUNDL)
>>>   #define OCTAVE_INT_USE_LONG_DOUBLE
>>>   #endif
>>>
>>> I think you already said SIZEOF_LONG_DOUBLE is 12.  Is
>>> HAVE_ROUNDL
>>> defined on your system?
>>>
>>> jwe
>>>
>>
>> John,
>> I am stupid, I used grep to find
>> #define OCTAVE_INT_USE_LONG_DOUBLE
>>
>> and have not checked the line arounds.
>> HAVE_ROUNDL is not defined
>>
>> so also OCTAVE_INT_USE_LONG_DOUBLE is not defined.
>>
>> Marco
>>
>>
>
> What a relief :) And I was becoming afraid that I invented something
> that makes the preprocessor go crazy...
> I just filed a bug for GCC: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39270
>
> I'm currently trying a workaround that would allow us to keep the ugly
> emulation code (that is a workaround by itself) in oct-inttypes.cc. If
> I'm not successful, I guess we should go with John's patch.
>
> regards
>

The attached relatively small patch enables building without
OCTAVE_INT_USE_LONG_DOUBLE for me, but still keeps the emulation code
in oct-inttypes.cc.

Marco, Rafael, can you try it out?

regards

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

Attachment: workaround.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]