From bug-request at octave dot org Tue Oct 5 18:41:19 2004 Subject: Re: Make V2.1.60 under gcc 3.3.3 and gcc 3.4.1 fail (Cygwin) From: "Yadin Goldschmidt" To: bug at octave dot org Date: Tue, 5 Oct 2004 19:30:20 -0400 Actually I found on the net gcc 3.2 (see Berkley ptolemey II page) and it works well with cygwin 1.5.11 (the most recent) and octave compiles out of the box. The slowing problem then disappears. wrote in message news:41594DB4 dot 28119 dot 1064057 at localhost dot dot dot > Am 27 Sep 2004 um 16:00 hat David Bateman geschrieben: > >> According to Fabian at isas-berlin dot de (on 09/27/04): >> > Last week, I've already reported failure of successful >> > compilation of Octave V2.1.59 on a Cygwin System. See >> > . >> > >> > In that approach, I have used compiler versions >> > gcc (GCC) 3.2 20020927 (prerelease) >> > g++ (GCC) 3.2 20020927 (prerelease) . >> > >> > Your replies told me, that gcc version 3.2 might be too old. >> > So I made a completely NEW installation of Cygwin last week, >> > updating it to Cygwin Version 1.5.19 ( 2004-Sep-5 Release ). >> >> In fact you should use g++ 3.2 and not newer versions... GCC changed >> the exception handler for cygwin in 3.3 to use setjmp/longjmp and this >> has bene the source of major slowups for octave. Revert to your 3.2 >> compiler..... > > Indeed, a tremendous amount of warnings e.g. > dbleSCHUR.h:63: warning: variable 'this' might be clobbered by `longjmp' > or `vfork' > Array.h: In member function `int AEPBALANCE::init(const Matrix&, const > std::string&)': > Array.h:219: warning: variable 'this' might be clobbered by `longjmp' or > `vfork' > appeared while compiling. > > A look at tells me, that official Cygwin > mirrors > usually distribute (only) one version previous to the current one. > According to > the current Cygwin Version 1.5.19 includes compiler package > gcc-core-3.4.1-1 and gcc-g++-3.4.1-1 > wheras the 2nd currently available (previous) compiler version > gcc-core-3.3.3-3 and gcc-g++-3.3.3-3 , > i.e. official distribution of any Cygwin GCC V3.2.x has already been > stopped. > > It might be possible to find an 'old' gcc 3.2.x version somewhere > on the net, but I'm afraid, that it will not run without compatibility > problems along with the current Cygwin 1.5.19 (2004-Sep-5 Release) > libraries or other packages. > >> Ok, this is telling me that the file DOCSTRINGS wasn't created correctly, >> or at all. The first character in DOCSTRINGS is supposed to be the ascii >> character 31 (\037) that delimits help for the various functions. If it >> isn't you get this message... > > I see. Thanks. > >> I suspect if you rm the DOCSTRINGS file in scripts and rebuild teh >> problem >> will go away.. > > This was not enough remove the problem. > > In also had to reinstall 'scripts/DOCSTRINGS' from the source > distribution. > > Then changing line (B-org) in 'scripts/Makefile': > > DOCSTRINGS: gethelp$(BUILD_EXEEXT) mkdoc $(ALL_M_FILES) > $(srcdir)/mkdoc $(srcdir) > $ at dot t ( A ) > mv $ at dot t $@ (B-org) > to something like > mv $ at dot t $@.UNUSED (B-mod) > > prevents the original DOCSTRINGS file from beeing > overwritten to an empty file, because DOCSTRINGS.t is > created as an empty file as a result of line (A). > > After this modification, the compilation of Octave-2.1.60 > finished successful under Cygwin GCC 3.3.3 as well as > 'make install' did. As a consequence of my hack, > maybe my scripts documentation isn't up-to-date, but > I don't care to much about the moment. > > Nethertheless, the reason for failure of > $(srcdir)/mkdoc $(srcdir) > $ at dot t ( A ) > producing an empty file under Cygwin is a mystery. > I figured out, that 'sed' is called by 'mkdoc'. > So the problem might result from Cygwin-'sed' ? > ( I use Cygwin GNU sed version 4.1.2 ) > Eventually connected to a Windows EOL problem ? > ( Now, I've installed Cygwin in UNIX mode, > i.e. NOT anymore in DOS text mode ) > > > A final question. > What do yo mean by >> major slowups for octave. > Which features of Octave are predominantly affected ? Everything ? > > Small check of my new V2.1.60 (Cygwin GCC 3.3.3 ) on > Intel Pentium (R)4, CPU 1500 MHz, 250MB RAM : > octave:1> A=randn(1000); tic; B = eig(A); toc, ans= 38.4 sec > doesn't look too bad for me calulating eigenvalues of > an 1000x1000 matrix A with 1 million elements. > > On the other hand, loops like > octave:2> Z=0; tic; for k=1:1e5, Z++; end, toc, ans = 11.2 > sec > octave:3> Z=0; k=0; tic; while ++k<=1e5, Z++; end, toc, ans = 16.6 sec > look a bit slow. > > > Rolf Fabian > > > > ------------------------------------------------------------- > Octave is freely available under the terms of the GNU GPL. > > Octave's home on the web: http://www.octave.org > How to fund new projects: http://www.octave.org/funding.html > Subscription information: http://www.octave.org/archive.html > ------------------------------------------------------------- > > ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------