Is --enable-64 still experimental?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Is --enable-64 still experimental?

Orion Poplawski
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.

--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       [hidden email]
Boulder, CO 80301                   http://www.nwra.com

Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

John W. Eaton
Administrator
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.

Does Fedora already have blas, lapack, suitesparse, etc. libraries
compiled with 64-bit indexing?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

Orion Poplawski
On 03/19/2015 09:42 AM, 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.
>
> Does Fedora already have blas, lapack, suitesparse, etc. libraries compiled
> with 64-bit indexing?

No, that's the other major reason for not enabling it :).

> jwe
>


--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       [hidden email]
Boulder, CO 80301                   http://www.nwra.com

Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

chechu

Good evening, There are packages like blas, openblas, lapack that are already built with 64 bit options in official repos; we are using them and localy we rebuild suitesparse, qrupdate and the others ones.

Le 2015-03-19 16:55, "Orion Poplawski" <[hidden email]> a écrit :
On 03/19/2015 09:42 AM, 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.
>
> Does Fedora already have blas, lapack, suitesparse, etc. libraries compiled
> with 64-bit indexing?

No, that's the other major reason for not enabling it :).

> jwe
>


--
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       [hidden email]
Boulder, CO 80301                   http://www.nwra.com

Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

Philip Nienhuis
In reply to this post by John W. Eaton
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.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

chechu

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 <[hidden email]>:
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.

Philip




--
View this message in context: http://octave.1599824.n4.nabble.com/Is-enable-64-still-experimental-tp4669274p4669280.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

chechu
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.

There are any "make check" tests that could be done for verify the integrity of the built image package? It seems to work ,thought.
On previous octave editions; like v3.2; there was also possible to run #make static-binary-dist or  #make dynamic-binary-dist for been able of creating distributable packages with the libraries embedded on it.  There is any documentation or workaround that someone could point us for been able of creating it? GNU/Debian and Red Hat Enterprise Linux are our distributions.

Thankyou so much in advance,
Yours sincerely, Jose

2015-04-16 8:35 GMT+00:00 Chechu Garguez <[hidden email]>:

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 <[hidden email]>:
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.

Philip




--
View this message in context: http://octave.1599824.n4.nabble.com/Is-enable-64-still-experimental-tp4669274p4669280.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.



Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

PhilipNienhuis
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 <[hidden email]
> <mailto:[hidden email]>>:
>
>
>     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 <[hidden email]
>     <mailto:[hidden email]>>:
>
>         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


Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

chechu
Good morning everyone,

During last week we have built mxe-octave on three different linux environments, using the  suggestions from mxe-octave wiki and http://savannah.gnu.org/bugs/index.php?43319
i#comment 13.
We are trying to use image package with 64bit indexing on Linux.

On mxe-octave stable-branch we can't build image 2.4.0; it needs octave 4.0.0>=
We have not succeded on those builds, the problem remains, maybe we have done something wrong.  We are not succeeding on Linux 64bit addressing with image package without "modifying" the includes containing the "typos" that fail, either with mxe-octave :(

Any suggestions? Thanks so much in advance.

-----------------
----- Logs of the results obtained


RedHatEnterprise Linux 7: gcc-4.9.2


---stable-octave: 3.8.2 with image package 2.2.2:

Builds stable-octave successfully with 64bit addressing ---->image 2.2.2  it fails at spatial_filtering complaining about ambiguous assumption as with an standard octave build:


__spatial_filtering__.cc:193:25: note: candidates are:

               
/mnt/extra1/mxe-octave-006263ce4905/usr/include/octave-3.8.2/octave/../octave/oct-inttypes.h:884:3: note: octave_int<T>::operator float() const [with T = unsigned char]
   operator float (void) const { return float_value (); }
   ^
/mnt/extra1/mxe-octave-006263ce4905/usr/include/octave-3.8.2/octave/../octave/oct-inttypes.h:882:3: note: octave_int<T>::operator double() const [with T = unsigned char]
   operator double (void) const { return double_value (); }
   ^
/mnt/extra1/mxe-octave-006263ce4905/usr/include/octave-3.8.2/octave/../octave/oct-inttypes.h:878:3: note: octave_int<T>::operator T() const [with T = unsigned char]




---default-octave: 4.0.0rc3 with octave-forge image package 2.4.0:

Builds default-octave successfully with 64bit addressing ---->image 2.4.0  it fails at spatial_filtering complaining about ambiguous assumption as with the octave stable-build out or within of mxe-octave



Debian 8.0 Jessie:  gcc-4.9.2


---stable-octave: 3.8.2 with image package 2.2.2:

Builds stable-octave successfully with 64bit addressing ---->image 2.2.2  it fails at spatial_filtering complaining about ambiguous assumption.



---default-octave: 4.0.0rc3 with octave-forge image package 2.4.0:

Builds default-octave successfully with 64bit addressing ---->image 2.4.0  it fails at spatial_filtering complaining about ambiguous assumption



Fresh install of Ubuntu 14.04 LTS: gcc-4.8.2-19 ubuntu


---stable-octave: 3.8.2 with image package 2.2.2:

Builds stable-octave successfully with 64bit addressing ---->image 2.2.2  it fails at spatial_filtering complaining about ambiguous assumption.


---default-octave: 4.0.0rc3 with octave-forge image package 2.4.0:

Fails on Building default-octave; because of libosmesa -gui- errors
Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

Carnë Draug
On 28 April 2015 at 10:59, chechu <[hidden email]> wrote:

> Good morning everyone,
>
> During last week we have built mxe-octave on three different linux
> environments, using the  suggestions from mxe-octave wiki and
> http://savannah.gnu.org/bugs/index.php?43319
> i#comment 13.
> We are trying to use image package with 64bit indexing on Linux.
>
> On mxe-octave stable-branch we can't build image 2.4.0; it needs octave
> 4.0.0>=
> We have not succeded on those builds, the problem remains, maybe we have
> done something wrong.  We are not succeeding on Linux 64bit addressing with
> image package without "modifying" the includes containing the "typos" that
> fail, either with mxe-octave :(
>
> Any suggestions? Thanks so much in advance.

I have just pushed a commit to the image package that may make it
installable.  Can you make a clone of the image package (stable branch)
and see if it builds?

Alternatively, apply the following changeset to your image package

http://hg.code.sf.net/p/octave/image/rev/9971d3d64673

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

chechu
This post was updated on .
Thank you so much !, we are gonna test it and will come back to you as soon as possible.
We will make a fresh clone of mxe-octave and image package.
Yours sincerely
Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

chechu
This post was updated on .
In reply to this post by Carnë Draug
Good morning Carnë, thanks for your effort.

We had cloned the image stable branch from the repository and it builds; the downside is that bwlabeln and other functions are not yet included on 2.5.0+ image package.

We had tried to leave the spatial_filter.cc file in  2.4.0 image package as your change proposed, deleting that two lines leaves the code as follows:

.........

else if (method == "entropy")
    {
      // Do the real work
      #define ACTION(MT, FUN, ET) \
              GENERAL_ACTION(MT, FUN, ET, NDArray, double, entropy_filt)
      if (args (0).is_bool_matrix ())
        ACTION (boolNDArray, bool_array_value, bool)
      else if (args (0).is_uint8_type ())
        ACTION (uint8NDArray, uint8_array_value, octave_uint8)
      else
        error ("__spatial_filtering__: first input should be a real, complex, or integer array");

........
 -------------------

That change is not helping to compile the 2.4.0 octave-forge package, the log is as follows :


__spatial_filtering__.cc:600:9:   required from here
__spatial_filtering__.cc:191:25: error: conversion from ‘octave_int<unsigned char>’ to ‘octave_idx_type {aka long int}’ is ambiguous
     hist (vals (i) + add) ++;
                         ^
__spatial_filtering__.cc:191:25: note: candidates are:
In file included from /usr/include/octave-4.0.0-rc3/octave/../octave/idx-vector.h:36:0,
                 from /usr/include/octave-4.0.0-rc3/octave/../octave/Array.h:36,
                 from /usr/include/octave-4.0.0-rc3/octave/../octave/boolMatrix.h:27,
                 from /usr/include/octave-4.0.0-rc3/octave/../octave/mx-base.h:32,
                 from /usr/include/octave-4.0.0-rc3/octave/../octave/Matrix.h:30,
                 from /usr/include/octave-4.0.0-rc3/octave/../octave/oct.h:33,
                 from __spatial_filtering__.cc:21:
/usr/include/octave-4.0.0-rc3/octave/../octave/oct-inttypes.h:891:3: note: octave_int<T>::operator float() const [with T = unsigned char]
   operator float (void) const { return float_value (); }
   ^
/usr/include/octave-4.0.0-rc3/octave/../octave/oct-inttypes.h:889:3: note: octave_int<T>::operator double() const [with T = unsigned char]
   operator double (void) const { return double_value (); }
   ^
/usr/include/octave-4.0.0-rc3/octave/../octave/oct-inttypes.h:885:3: note: octave_int<T>::operator T() const [with T = unsigned char]
   operator T (void) const { return value (); }

-----------

Thanks so much, your sincerely Jose


Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

Carnë Draug
On 29 April 2015 at 10:10, chechu <[hidden email]> wrote:
> Good morning Carnë, thanks for your effort.
>
> We had cloned the image stable branch from the repository and it build; the
> downside is that bwlabeln and other functions are not yet included on 2.5.0+
> image package.

What do you mean? bwlabeln is part of the image package since 2.0.0 and
hasn't gone anywhere.

> We had tried to leave the spatial_filter.cc file in  2.4.0 image package as
> your change proposed, deleting that two lines leaves the code as follows:
>
> [...]

I can't really go and fix this now.  This part of the code is only used by
entropyfilt().  If this function is not important for you, you could simply
remove the entropyfilt m file [1], the function entropy_filt() from
__spatial_filtering__.cc [2], and the block between lines 592 and 605 that
calls it, also from __spatial_filtering__.cc [3].

Also, could you please a bug report about this bug in specific?

Carnë

[1] http://hg.code.sf.net/p/octave/image/file/a524dd48ae28/inst/entropyfilt.m
[2] http://hg.code.sf.net/p/octave/image/file/a524dd48ae28/src/__spatial_filtering__.cc#l183
[3]  http://hg.code.sf.net/p/octave/image/file/a524dd48ae28/src/__spatial_filtering__.cc#l592

Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

chechu
Good evening Carnë, thanks for your attention.

We download the image stable branch revision a524dd from sourceforge, your last change is tagged as done two days ago.

We do
tar czf image-x.x.x.tar.gz octave-image

and inside octave we run with success
# pkg install -verbose image-x.x.x.tar.gz

after that octave version prints like this:


GNU Octave Version: 4.0.0-rc4
GNU Octave License: GNU General Public License
Operating System: Linux 3.10.0-123.20.1.el7.x86_64 #1 SMP Wed Jan 21 09:45:55 EST 2015 x86_64
----------------------------------------------------------------------
Package Name  | Version | Installation directory
--------------+---------+-----------------------
     control  |   2.8.0 | /usr/share/octave/packages/control-2.8.0
     general  |   1.3.4 | /usr/share/octave/packages/general-1.3.4
       image  |   2.4.0 | /usr/share/octave/packages/image-2.4.0

running bwlabeln returns:

bwlabeln

warning: the 'bwlabeln' function belongs to the image package from Octave Forge
but has not yet been implemented.

Please read <http://www.octave.org/missing.html> to learn how you can
contribute missing functionality.
warning: called from
    __unimplemented__ at line 523 column 5


I'll search for the best way to post a bug, thank you so much for your noteson disabling entropy function.


Yours sincerly Jose
------

Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

Carnë Draug
On 30 April 2015 at 13:40, chechu <[hidden email]> wrote:

> Good evening Carnë, thanks for your attention.
>
> We download the image stable branch revision *a524dd* from sourceforge, your
> last change is tagged as done two days ago.
>
> We do
> tar czf image-x.x.x.tar.gz octave-image
>
> and inside octave we run with success
> # pkg install -verbose image-x.x.x.tar.gz
>

A release is more than just a tarball of the repository.  What you did will
create a tarball that installs fine but it won't create a configure script.
Without the configure script, there src/Makefile won't be created, so none
of the C++ functions (such as bwlabeln) gets built and installed.

To mimic a release, cd into the repository and enter "make dist".  This
will create a tarball that you can install with "pkg install".  Look into
the Makefile and bootstrap at the root of the repository if you are
interested in details.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

chechu
Good evening everyone.

Looking into savannah.gnu.org, this error that remains at image package was submitted as bug number #38085.

I will try to change that lines as Jordi GH proposed on march that year 2015.

https://savannah.gnu.org/bugs/?38085

Thank you all  for your efforts, Octave 4.0.0 just coming
Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

Carnë Draug
On 4 May 2015 at 16:03, chechu <[hidden email]> wrote:

> Good evening everyone.
>
> Looking into savannah.gnu.org, this error that remains at image package was
> submitted as bug number #38085.
>
> I will try to change that lines as Jordi GH proposed on march that year
> 2015.
>
> https://savannah.gnu.org/bugs/?38085
>

Hi Chechu

can you please confirm whether Jordi's proposal fixes the problem for you?

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Is --enable-64 still experimental?

chechu


Le 12 mai 2015 19:18, "Carnë Draug" <[hidden email]> a écrit :
>
> On 4 May 2015 at 16:03, chechu <[hidden email]> wrote:
> > Good evening everyone.
> >
> > Looking into savannah.gnu.org, this error that remains at image package was
> > submitted as bug number #38085.
> >
> > I will try to change that lines as Jordi GH proposed on march that year
> > 2015.
> >
> > https://savannah.gnu.org/bugs/?38085
> >
>
> Hi Chechu
>
> can you please confirm whether Jordi's proposal fixes the problem for you?
>
> Carnë

I'm sorry not Carnë .  I tried with your proposal and also with a fresh octave build using the changes proposed by Jordi GH.
The problem persists.
I had no time for making a descriptive post on savannah,sorry