ITP: octave-2.1.71

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

ITP: octave-2.1.71

James R. Phillips-3
cygwin maintainers,

With some strong assistance from octave upstream (John W. Eaton at octave.org)
in tailoring the g-b-s for octave, I am close to having an octave package for
upload.  It is linked against lapack (see my ITP for lapack), so lapack is a
build dependency.

Upstream has provided two binary packages from a single source package: the
main octave package, and an accompanying octave-headers package, which is
required for compiling new octave binary (.oct) functions.

The proposed setup.hint files are as follows:

FOR OCTAVE

sdesc: "The GNU Octave language for numerical computations"
category: Math
requires: cygwin lapack gnuplot less readline texinfo
ldesc: "The GNU Octave language for numerical computations
Octave is a (mostly Matlab (R) compatible) high-level language, primarily
intended for numerical computations.  It provides a convenient command-line
interface for solving linear and nonlinear problems numerically."


FOR OCTAVE-HEADERS

sdesc: "Header files for the GNU Octave language"
category: Math
requires: cygwin octave gcc g++ g77 libncurses-devel
external-source: octave
ldesc: "Header files for the GNU Octave language.
This packages provides the include files needed to compile and link
user-supplied code with GNU Octave.  If you only write interpreted .m
files, you do not need this package."

-----------
Please provide comments on the proposal.

Thanks,

Jim Phillips

Reply | Threaded
Open this post in threaded view
|

Re: ITP: octave-2.1.71

Brian Dessent
"James R. Phillips" wrote:

> With some strong assistance from octave upstream (John W. Eaton at octave.org)
> in tailoring the g-b-s for octave, I am close to having an octave package for
> upload.  It is linked against lapack (see my ITP for lapack), so lapack is a
> build dependency.
>
> Upstream has provided two binary packages from a single source package: the
> main octave package, and an accompanying octave-headers package, which is
> required for compiling new octave binary (.oct) functions.

Out of curiosity, what if anything have you done to address the SJLJ
issue/PR 14563?  To summarize, the Cygwin packaged gcc has had
--enable-sjlj-exceptions for quite a while because DW2 exceptions are
broken in certain circumstances (namely, when throwing an exception in a
function used in a callback where the caller doesn't know DW2, eg. win32
api.)  I don't know much at all about octave but if it does not use any
callbacks in these situations then it might be worthwhile if you
compiled the binaries with a DW2 EH-enabled gcc, to avoid the massive
speed hit reported.

Brian

Reply | Threaded
Open this post in threaded view
|

Re: ITP: octave-2.1.71

James R. Phillips-3

--- Brian Dessent  wrote:

> Out of curiosity, what if anything have you done to address the SJLJ
> issue/PR 14563?  To summarize, the Cygwin packaged gcc has had
> --enable-sjlj-exceptions for quite a while because DW2 exceptions are
> broken in certain circumstances (namely, when throwing an exception in a
> function used in a callback where the caller doesn't know DW2, eg. win32
> api.)  I don't know much at all about octave but if it does not use any
> callbacks in these situations then it might be worthwhile if you
> compiled the binaries with a DW2 EH-enabled gcc, to avoid the massive
> speed hit reported.
>
> Brian
>

Brian,

This issue occurs in John Eaton's list of stuff to do, but I don't know
anything else about it.  Will forward to octave maintainers list for comments.

Thanks.

Jim Phillips

Reply | Threaded
Open this post in threaded view
|

Re: ITP: octave-2.1.71

David Bateman-3
James R. Phillips wrote:

>--- Brian Dessent  wrote:
>
>  
>
>>Out of curiosity, what if anything have you done to address the SJLJ
>>issue/PR 14563?  To summarize, the Cygwin packaged gcc has had
>>--enable-sjlj-exceptions for quite a while because DW2 exceptions are
>>broken in certain circumstances (namely, when throwing an exception in a
>>function used in a callback where the caller doesn't know DW2, eg. win32
>>api.)  I don't know much at all about octave but if it does not use any
>>callbacks in these situations then it might be worthwhile if you
>>compiled the binaries with a DW2 EH-enabled gcc, to avoid the massive
>>speed hit reported.
>>
>>Brian
>>
>>    
>>
>
>Brian,
>
>This issue occurs in John Eaton's list of stuff to do, but I don't know
>anything else about it.  Will forward to octave maintainers list for comments.
>
>Thanks.
>
>Jim Phillips
>
>  
>
I'm working on getting a mingw build working that avoids the speed hit.
Using "nothrow new" would mean rather a large number of changes within
octave sources itself, and probably as much work as a mingw build, so I
prefer to work on a mingw build. In any case Paul Thomas reported that
the SJLJ issue equally affects the vtable in octave and so we also take
a large hit there, which can't be addressed with "nothrow new"..

Cheers
David

--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

Reply | Threaded
Open this post in threaded view
|

Re: ITP: octave-2.1.71

John W. Eaton-6
In reply to this post by James R. Phillips-3
On 30-Jun-2005, James R. Phillips wrote:

| --- Brian Dessent  wrote:
|
| > Out of curiosity, what if anything have you done to address the SJLJ
| > issue/PR 14563?  To summarize, the Cygwin packaged gcc has had
| > --enable-sjlj-exceptions for quite a while because DW2 exceptions are
| > broken in certain circumstances (namely, when throwing an exception in a
| > function used in a callback where the caller doesn't know DW2, eg. win32
| > api.)  I don't know much at all about octave but if it does not use any
| > callbacks in these situations then it might be worthwhile if you
| > compiled the binaries with a DW2 EH-enabled gcc, to avoid the massive
| > speed hit reported.
| >
| > Brian
| >
|
| Brian,
|
| This issue occurs in John Eaton's list of stuff to do, but I don't know
| anything else about it.

I don't think it is my responsibility to fix a problem that is really
in GCC or Cygwin.

Also, I don't think we can build Octave with some special version of
GCC because Octave has a plugin feature, and I think that pretty much
requires using the same C++ compiler to build all the parts of Octave
and the plugins.

BTW, wasn't there a thread about this recently on the
[hidden email] list (subject Serious performance problems) that
showed that the problem involved thread handling in Cygwin about as
much as sjlj exception handling?  I think some progress has been made
in addressing the problem.

Anyway, I think the place to fix this problem is in Cygwin or GCC, not
Octave.

Having Octave compile and run cleanly with mingw is a separate issue,
and doesn't really solve the problem for Cgywin users.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: ITP: octave-2.1.71

James R. Phillips-3
In reply to this post by James R. Phillips-3


--- Christopher Faylor  wrote:

> >--- "John W. Eaton" <[hidden email]> wrote:
> >
> >>
> >>Having Octave compile and run cleanly with mingw is a separate issue,
> >>and doesn't really solve the problem for Cgywin users.
>
> Actually, it isn't a separate issue at all.  DW2 exception handling is
> an issue common to both mingw and cygwin.  It seems likely that any
> solution which addressed the problem on mingw would also work for cygwin.
>
> cgf
>

I think what John meant to say is, running under mingw is a separate _bag_ of
issues.  Within this bag, among the issues, is this one issue we are discussing
(DW2 exception handling), which may in fact be a common issue.  David Bateman
on the octave maintainers list is working on all the issues in the mingw bag.
If he solves this for one, perhaps it'll be solved for both.

As a cygwin packager, I can't do much do address this, other than bring the
maintainers into the discussion.  I have been using octave compiled for cygwin
(local package) steadily for a year, and anecdotally, the performance issues
haven't kept me from getting real work done.

I will admit that I haven't compiled a working octave package with cygwin gcc
3.4.4-1.  I think there may be a bag of issues there as well.  I reverted back
to gcc 3.3.3 to compile octave 2.1.71.

This fact (must use gcc 3.3.3) might have to be noted as a build-depends in the
octavexxx.README.

Reply | Threaded
Open this post in threaded view
|

Re: ITP: octave-2.1.71

Gerrit P. Haase
James R. Phillips wrote:

> I will admit that I haven't compiled a working octave package with cygwin gcc
> 3.4.4-1.  I think there may be a bag of issues there as well.  I reverted back
> to gcc 3.3.3 to compile octave 2.1.71.

Please send your observations about problems with (Cygwin) gcc-3.4.4.


Gerrit
--
=^..^=

Reply | Threaded
Open this post in threaded view
|

Re: ITP: octave-2.1.71

James R. Phillips-3


--- "Gerrit P. Haase"  wrote:

> James R. Phillips wrote:
>
> > I will admit that I haven't compiled a working octave package with cygwin
> gcc
> > 3.4.4-1.  I think there may be a bag of issues there as well.  I reverted
> back
> > to gcc 3.3.3 to compile octave 2.1.71.
>
> Please send your observations about problems with (Cygwin) gcc-3.4.4.
>
>

OK, now that I have what looks like a working package with gcc 3.3.3, I
compiled with gcc 3.4.4.  It segfaults and dumps core at startup.  Um, it is
linked with unrecompiled lapack dll's (they were also compiled with gcc 3.3.3).
 But that per se shouldn't be an issue, I don't think.

So, how can I help you?  Use gdb in some fashion?  The binary is, of course,
stripped.

Jim Phillips

Reply | Threaded
Open this post in threaded view
|

Re: ITP: octave-2.1.71

Gerrit P. Haase
James R. Phillips wrote:
> OK, now that I have what looks like a working package with gcc 3.3.3, I
> compiled with gcc 3.4.4.  It segfaults and dumps core at startup.  Um, it is
> linked with unrecompiled lapack dll's (they were also compiled with gcc 3.3.3).
>  But that per se shouldn't be an issue, I don't think.
>
> So, how can I help you?  Use gdb in some fashion?  The binary is, of course,
> stripped.

We need to know what is the problem, so building with debugging turned
on is needed.  Also try different grades of optimization, what do you
use now, e.g. -O3?  Does it work with -O2 then, and so on.  There are
several bugs in the optimizer, i.e. the unit-at-a-time stuff is breaking
a lot of code, however this is not a bug, this is by design;)
If it is a problem with the optimizer we will figure out which flag
breaks the binary and report a bug.


Gerrit

Reply | Threaded
Open this post in threaded view
|

Re: ITP: octave-2.1.71

Andy Adler
On Mon, 4 Jul 2005, Gerrit P. Haase wrote:

> James R. Phillips wrote:
> > OK, now that I have what looks like a working package with gcc 3.3.3, I
> > compiled with gcc 3.4.4.  It segfaults and dumps core at startup.  Um, it is
> > linked with unrecompiled lapack dll's (they were also compiled with gcc 3.3.3).
> >  But that per se shouldn't be an issue, I don't think.
> >
> > So, how can I help you?  Use gdb in some fashion?  The binary is, of course,
> > stripped.
>
> We need to know what is the problem, so building with debugging turned
> on is needed.  Also try different grades of optimization, what do you
> use now, e.g. -O3?  Does it work with -O2 then, and so on.  There are
> several bugs in the optimizer, i.e. the unit-at-a-time stuff is breaking
> a lot of code, however this is not a bug, this is by design;)
> If it is a problem with the optimizer we will figure out which flag
> breaks the binary and report a bug.


This is the same issue as my question two weeks ago.

http://www.octave.org/mailing-lists/octave-maintainers/2005/577

It seems that gcc-3.4 is at fault here, since all recent
2.1.x and 2.9.x versions give the same errors.

When not stripped, the octave binary gives
   # make install
   # octave
   warning: : Unrecognized variable construct `$
   ... [ many more ] ...
   warning: kpathsea: variable `O' references itself (eventually)
   ... [ many more ] ...
   Aborted (core dumped)

Andy
--
Andy Adler <[hidden email]> 1(613)562-5800x6218


Reply | Threaded
Open this post in threaded view
|

Re: ITP: octave-2.1.71

David Bateman-3
Andy Adler wrote:

>On Mon, 4 Jul 2005, Gerrit P. Haase wrote:
>
>  
>
>>James R. Phillips wrote:
>>    
>>
>>>OK, now that I have what looks like a working package with gcc 3.3.3, I
>>>compiled with gcc 3.4.4.  It segfaults and dumps core at startup.  Um, it is
>>>linked with unrecompiled lapack dll's (they were also compiled with gcc 3.3.3).
>>> But that per se shouldn't be an issue, I don't think.
>>>
>>>So, how can I help you?  Use gdb in some fashion?  The binary is, of course,
>>>stripped.
>>>      
>>>
>>We need to know what is the problem, so building with debugging turned
>>on is needed.  Also try different grades of optimization, what do you
>>use now, e.g. -O3?  Does it work with -O2 then, and so on.  There are
>>several bugs in the optimizer, i.e. the unit-at-a-time stuff is breaking
>>a lot of code, however this is not a bug, this is by design;)
>>If it is a problem with the optimizer we will figure out which flag
>>breaks the binary and report a bug.
>>    
>>
>
>
>This is the same issue as my question two weeks ago.
>
>http://www.octave.org/mailing-lists/octave-maintainers/2005/577
>
>It seems that gcc-3.4 is at fault here, since all recent
>2.1.x and 2.9.x versions give the same errors.
>
>When not stripped, the octave binary gives
>   # make install
>   # octave
>   warning: : Unrecognized variable construct `$
>   ... [ many more ] ...
>   warning: kpathsea: variable `O' references itself (eventually)
>   ... [ many more ] ...
>   Aborted (core dumped)
>
>  
>
Interestingly in my builds with mingw current with g++ v3.4.2 I don't
see this problem. I see plenty of other problems (permission problems
with popen, problems handling interrupts, problems with the rxvt
terminal, readline, etc), but not that one... So it seems to problem is
specific to cygwin and not in the common code for mingw/cygwin in v3.4.2.

Regards
David

--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary