GCC 5.1.0 in mxe-octave

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

GCC 5.1.0 in mxe-octave

John W. Eaton
Administrator
I updated mxe-octave and noticed that GCC has been updated to 5.1.0.  Is
this necessary for some bug fixes?  If not, I'd prefer to stay at the
previous version for the Octave 4.0.x releases.

More generally, how should we manage Octave releases and mxe-octave
development?  I'd guess that whatever Octave 4.0.x releases that we make
should be done with the same set of tools.  Also possibly with the same
set of packages, with only bug fixes applied, same as we do for the
Octave releases themselves.  But I don't know that we have a good way of
handling that as package development proceeds separately from Octave
development.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: GCC 5.1.0 in mxe-octave

Philip Nienhuis
John W. Eaton wrote
I updated mxe-octave and noticed that GCC has been updated to 5.1.0.  Is
this necessary for some bug fixes?  If not, I'd prefer to stay at the
previous version for the Octave 4.0.x releases.
http://savannah.gnu.org/bugs/index.php?44998

gcc 4.9.2 used to work fine until (I think) the change was made on the host side (Linux) to have a combined 32/64 bit cross-gcc to be able to compile nsis for 64 bit Octave.
However it appears that the so produced binaries turned out to be incompatible with the 64-bit only native gcc for the Windows side, leading to intractable bugs.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: GCC 5.1.0 in mxe-octave

tmacchant
In reply to this post by John W. Eaton
----- Original Message -----

> From: John W. Eaton 
> To: Octave Maintainers List 
> Cc: [hidden email]
> Date: 2015/5/7, Thu 05:05
> Subject: GCC 5.1.0 in mxe-octave
>
> I updated mxe-octave and noticed that GCC has been updated to 5.1.0.  Is this
> necessary for some bug fixes?  If not, I'd prefer to stay at the previous
> version for the Octave 4.0.x releases.
>
> More generally, how should we manage Octave releases and mxe-octave
> development?  I'd guess that whatever Octave 4.0.x releases that we make
> should be done with the same set of tools.  Also possibly with the same set of
> packages, with only bug fixes applied, same as we do for the Octave releases
> themselves.  But I don't know that we have a good way of handling that as
> package development proceeds separately from Octave development.
>


I point annoying bugs for windows users for those who use non-ascii characters.

1. Files and directories with non-ASCII characters not handled correctly on Windows
http://savannah.gnu.org/bugs/?42036


This might come from bug of MinGW compiler handling unicode.

2.  command window problem for windows for Japanese
http://savannah.gnu.org/bugs/?44538

(This bug is not only for Japanese but also for Chinese.)

This might be a problem of handling windows code page.

The bug 1 seems to be related the mingw-gcc (4.x.x).
If it is solved in 5.1.0, it is worth to use it, I think.
I cannot test gcc 5.1 of the mingw64 project because the 5.1 directories are empty.

BTW, the cygwin version of octave does naturally not suffer any problems of the above on octave-3.8.2.

Tatsuro 

Reply | Threaded
Open this post in threaded view
|

Re: GCC 5.1.0 in mxe-octave

Carnë Draug
In reply to this post by John W. Eaton
On 6 May 2015 at 21:05, John W. Eaton <[hidden email]> wrote:
> [...]
> More generally, how should we manage Octave releases and mxe-octave
> development?  I'd guess that whatever Octave 4.0.x releases that we make
> should be done with the same set of tools.  Also possibly with the same set
> of packages, with only bug fixes applied, same as we do for the Octave
> releases themselves.  But I don't know that we have a good way of handling
> that as package development proceeds separately from Octave development.
>

I'd say to use the last patch release of the same minor release of the
package that was present in Octave 4.0.0.  So to be more clear, if Octave
4.0.0 is released with control 2.8.1, then Octave 4.0.1 could be released
with the latest control 2.8.X at the time of release, but not anything
above that.

This would require package developers to use the same rationale as core
to decide if a patch would go into "stable" or "default", which at the
moment does not really happen so it would require core to pay close attention
to the diff between packages.  It would also require package developers
to maintain a old branch and backports patches into it if they want the
next release of Octave to include the fix which is also not ideal.

In an ideal situation, Octave would install pre-built forge packages,
package developers would be able to upload such packages somewhere, and
Octave core would not have to be released with packages at all.  This would
also prevent package developers from rushing out a release in order to get
it into the next octave release (kind of what sometimes happens with upstream
packages before a freeze of a Linux distro). I don't have a solution for
any of this though.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: GCC 5.1.0 in mxe-octave

John Donoghue-3
In reply to this post by John W. Eaton
> Message: 2
> Date: Wed, 6 May 2015 14:58:55 -0700 (PDT)
> From: Philip Nienhuis <[hidden email]>
> To: [hidden email]
> Subject: Re: GCC 5.1.0 in mxe-octave
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
> John W. Eaton wrote
> > I updated mxe-octave and noticed that GCC has been updated to 5.1.0.
> > Is this necessary for some bug fixes?  If not, I'd prefer to stay at
> > the previous version for the Octave 4.0.x releases.
>
> http://savannah.gnu.org/bugs/index.php?44998
>
> gcc 4.9.2 used to work fine until (I think) the change was made on the
host side
> (Linux) to have a combined 32/64 bit cross-gcc to be able to compile nsis
for 64
> bit Octave.
> However it appears that the so produced binaries turned out to be
incompatible
> with the 64-bit only native gcc for the Windows side, leading to
intractable bugs.
>
> Philip
>
>

Well probally needs to go back to 4.9.2 or 4.8.4?
Im sure I had compiled and run it both in 64 and 32 bit mode but its not
doing it now.

As for the question on not changing except for bug releases, so we need a
stable vs dev branch?


Reply | Threaded
Open this post in threaded view
|

Re: GCC 5.1.0 in mxe-octave

tmacchant
In reply to this post by tmacchant
----- Original Message -----

> From: Tatsuro MATSUOKA 
> To: John W. Eaton ; Octave Maintainers List
> Cc:
> Date: 2015/5/7, Thu 17:07
> Subject: Re: GCC 5.1.0 in mxe-octave
>
> ----- Original Message -----
>
>>  From: John W. Eaton 
>>  To: Octave Maintainers List 
>>  Cc: [hidden email]
>>  Date: 2015/5/7, Thu 05:05
>>  Subject: GCC 5.1.0 in mxe-octave
>>
>>  I updated mxe-octave and noticed that GCC has been updated to 5.1.0.  Is
> this
>>  necessary for some bug fixes?  If not, I'd prefer to stay at the
> previous
>>  version for the Octave 4.0.x releases.
>>
>>  More generally, how should we manage Octave releases and mxe-octave
>>  development?  I'd guess that whatever Octave 4.0.x releases that we
> make
>>  should be done with the same set of tools.  Also possibly with the same set
> of
>>  packages, with only bug fixes applied, same as we do for the Octave
> releases
>>  themselves.  But I don't know that we have a good way of handling that
> as
>>  package development proceeds separately from Octave development.
>>
>
>
> I point annoying bugs for windows users for those who use non-ascii characters.
>
> 1. Files and directories with non-ASCII characters not handled correctly on
> Windows
> http://savannah.gnu.org/bugs/?42036
>
>
> This might come from bug of MinGW compiler handling unicode.
>
> 2.  command window problem for windows for Japanese
> http://savannah.gnu.org/bugs/?44538
>
> (This bug is not only for Japanese but also for Chinese.)
>
> This might be a problem of handling windows code page.
>
> The bug 1 seems to be related the mingw-gcc (4.x.x).
> If it is solved in 5.1.0, it is worth to use it, I think.
> I cannot test gcc 5.1 of the mingw64 project because the 5.1 directories are
> empty.
>
> BTW, the cygwin version of octave does naturally not suffer any problems of the
> above on octave-3.8.2.
>


Philip privately provided me mxe-octave built by gcc-5.1.0.
I appreciate Philip's kindness! 

I executed the test for the above two bugs.  
The two above problems are unfortunately not solved by gcc version up to 5.1.0.

Therefore we have to solve the issues independently with gcc(mingw) version.


Tatsuro

Reply | Threaded
Open this post in threaded view
|

Re: GCC 5.1.0 in mxe-octave

tmacchant
----- Original Message -----

> From: Tatsuro MATSUOKA 
> To: tmacchant; John W. Eaton ; Octave Maintainers List <[hidden email]>
> Cc:
> Date: 2015/5/8, Fri 16:35
> Subject: Re: GCC 5.1.0 in mxe-octave
>
> ----- Original Message -----
>
>>  From: Tatsuro MATSUOKA 
>>  To: John W. Eaton ; Octave Maintainers List
>>  Cc:
>>  Date: 2015/5/7, Thu 17:07
>>  Subject: Re: GCC 5.1.0 in mxe-octave
>>
>>  ----- Original Message -----
>>
>>>   From: John W. Eaton 
>>>   To: Octave Maintainers List 
>>>   Cc: [hidden email]
>>>   Date: 2015/5/7, Thu 05:05
>>>   Subject: GCC 5.1.0 in mxe-octave
>>>
>>>   I updated mxe-octave and noticed that GCC has been updated to 5.1.0. 
> Is
>>  this
>>>   necessary for some bug fixes?  If not, I'd prefer to stay at the
>>  previous
>>>   version for the Octave 4.0.x releases.
>>>
>>>   More generally, how should we manage Octave releases and mxe-octave
>>>   development?  I'd guess that whatever Octave 4.0.x releases that
> we
>>  make
>>>   should be done with the same set of tools.  Also possibly with the
> same set
>>  of
>>>   packages, with only bug fixes applied, same as we do for the Octave
>>  releases
>>>   themselves.  But I don't know that we have a good way of handling
> that
>>  as
>>>   package development proceeds separately from Octave development.
>>>
>>
>>
>>  I point annoying bugs for windows users for those who use non-ascii
> characters.
>>
>>  1. Files and directories with non-ASCII characters not handled correctly on
>
>>  Windows
>>  http://savannah.gnu.org/bugs/?42036
>>
>>
>>  This might come from bug of MinGW compiler handling unicode.
>>
>>  2.  command window problem for windows for Japanese
>>  http://savannah.gnu.org/bugs/?44538
>>
>>  (This bug is not only for Japanese but also for Chinese.)
>>
>>  This might be a problem of handling windows code page.
>>
>>  The bug 1 seems to be related the mingw-gcc (4.x.x).
>>  If it is solved in 5.1.0, it is worth to use it, I think.
>>  I cannot test gcc 5.1 of the mingw64 project because the 5.1 directories
> are
>>  empty.
>>
>>  BTW, the cygwin version of octave does naturally not suffer any problems of
> the
>>  above on octave-3.8.2.
>>
>
>
> Philip privately provided me mxe-octave built by gcc-5.1.0.
> I appreciate Philip's kindness! 
>
> I executed the test for the above two bugs.  
> The two above problems are unfortunately not solved by gcc version up to 5.1.0.
>
> Therefore we have to solve the issues independently with gcc(mingw) version.


Philip kindly provided me updated the mxe-octave (4.0.0-rc4 64bit) with gcc 5.1.0.
However, unfortunately the two bug are not affected by the change.

Tatsuro