Re: Is --enable-64 still experimental?

[Philip Nienhuis]

Chechu:

1. Please do not top-post.
Answer BELOW the mail, please

2. See there (=below)

Chechu Garguez wrote:
:
<moved down>
:
> 2015-04-16 8:35 GMT+00:00 Chechu Garguez <address@hidden
> <mailto:address@hidden>>:
>
>
>     So, for sure it's not a clean way to accomplish it, but for been
>     able of compiling image pkg on 64bit systems we have commented out
>     two of the three alternatives that give ambiguous resolution for gcc:
>
>
>     #octave/oct-inttypes.h
>
>
>     //operator T (void) const { return value (); }
>
>     operator double (void) const { return double_value (); }
>
>     //operator float (void) const { return float_value (); }
>
>
>
>     With that, mkoctave is cable of compiling the image 2.4.0 package
>     and we can use its functions.
>
>     We had left out "operator double" because it seems to be the option
>     that could generate double memory variables and could contain more
>     data on it.
>
>
>     Are we doing right? Should we use "operator T" insted? Is there any
>     better way to accomplish it? We had read ancient bug reporting and
>     OF-packages status but we had not been able of finding other solutions.
>
>     Thankyou so much in advance,
>     Your sincerly , Jose
>
>
>
>     2015-03-19 23:15 GMT+01:00 Philip Nienhuis <address@hidden
>     <mailto:address@hidden>>:
>
>         John W. Eaton wrote
>         > On 03/19/2015 11:34 AM, Orion Poplawski wrote:
>         >> There's been a request in Fedora
>         >> (https://bugzilla.redhat.com/show_bug.cgi?id=1082507) to enable 64bit
>         >> indexing
>         >> in octave.  I see in 4.0.0-rc1 this is still marked as experimental,
>         >> which is
>         >> one of the reasons we're not enabling it.  Is this indeed still the 
> case?
>         >> It
>         >> seems like it would be a good thing to enable otherwise.
>         >
>         > I think it's still incomplete.  For example, saving and loading data 
> may
>         > not work properly with 64-bit indexing.
>
>         The test suite contains tests for load/save, I presume?
>
>         I've been using 64-bit indexing builds for several months now on
>         Windows and
>         I saw no issues with load/save, neither with Octave-generated nor
>         Matlab-generated .mat files. I can't vouch for other file types.
>         Apart from that, __run_test_suite__.m shows a number of failed
>         tests that
>         pass on 32-bit and --enable-windows-64 MinGW builds.
>
>         On Linux I've got a 64-bit idx build (4.1.0+) made with MXE
>         along the lines
>         you've sketched in a bug report discussion some months ago; I do
>         not use
>         Octave that much on Linux so I didn't test thoroughly but
>         overall that build
>         works fine as well. Some tests did fail when run manually.
>
>         There are however still issues with several OF packages. See the
>         task
>         tracker task #13313, the OF package issues mentioned there are
>         equally valid
>         for Linux.

> Good morning to everyone
>
> During the last two years we have been trying to prepare octave for
> 64bit addressing. Our goal is to be able of processing 3d images of
> cancer and porifera structures, with them 2GBytes array limitation is a
> big drawback.
> With the last version of image package in OF we are still in need of
> "modifying" the includes from octave for compiling it.

Assuming you are using Windows (Linux see below):
With the --enable-windows-64 flag when cross-building Octave, double 
arrays of up to 16 GB are available, so 64-bit indexing may not be 
required for you.
I regularly make such builds for my own purposes and testing.

It is as easy to make 64-bit indexing builds as well for Windows.


If you run Linux, you can also build using MXE (see the wiki).
Relevant configure options for 64-bit indexing builds based om MXE are here:
http://savannah.gnu.org/bugs/index.php?43319
in comment 13.


With such 64-bit indexing Octave builds, the image package 2.4.0 
installs fine.

Philip