Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
* John W. Eaton [EMAIL PROTECTED] [2005-09-14 02:07]: On 10-Sep-2005, Rafael Laboissiere wrote: | John, could you please confirm that this would fix the bug? Looking at the code, I think it will avoid the problem. Should we then file a bug report against the libc6 package requesting the application of the patch? -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 15-Sep-2005, Rafael Laboissiere wrote: | * John W. Eaton [EMAIL PROTECTED] [2005-09-14 02:07]: | | On 10-Sep-2005, Rafael Laboissiere wrote: | | | John, could you please confirm that this would fix the bug? | | Looking at the code, I think it will avoid the problem. | | Should we then file a bug report against the libc6 package requesting the | application of the patch? Yes, unless there will be a new release of glibc very soon. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 10-Sep-2005, Rafael Laboissiere wrote: | John, could you please confirm that this would fix the bug? Looking at the code, I think it will avoid the problem. Thanks, jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On Fri, Sep 09, 2005 at 05:08:21PM -0400, John W. Eaton wrote: On 9-Sep-2005, Laurent Bonnaud wrote: | Is libstdc++ also completely compatible? Have there been absolutely | no changes that could affect layout of class members? | | This question is no longer a concern since my tests have shown that g++ | 3.4 is worse than g++ 4.0. But unless we are absolutely sure that everything is compatible from one release to another, Yes, we are. See Matthias Klose's announcements regarding the C++ ABI transition for etch. In the old days, the I think Octave was configured with something like CC=gcc-4.0 CXX=g++-4.0 F77=g77-4.0 so that these names would be put into the mkoctfile script. That way, when someone later ran mkoctfile, they would be sure to get the same version of the compiler that was used to build the Octave binary they were using. Yes, I would prefer to not have to fix the compiler versions, but unless we know that they are compatible, I see no other option. g++ is going to point to a compiler with an ABI compatible to that of g++-4.0 for the length of the etch release cycle. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
* John W. Eaton [EMAIL PROTECTED] [2005-09-09 13:22]: On 9-Sep-2005, Laurent Bonnaud wrote: | Too bad :. Did you submit bugs to the gcc or Debian BTS (I looked | rapidly and did not find a relevant bug) ? No, sorry, I didn't. It seems to be a glibc bug. According to: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160759 the bug was already fixed by 2005-07-10. Indeed, the libc/ChangeLog at: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/ChangeLog?rev=1.9521content-type=text/x-cvsweb-markupcvsroot=glibc has the following entry: 2005-07-07 Ulrich Drepper [EMAIL PROTECTED] * sysdeps/generic/s_ctanh.c (__ctanh): Handle case of zero den better. * sysdeps/generic/s_ctanhf.c (__ctanhf): Likewise. * sysdeps/generic/s_ctanhl.c (__ctanhl): Likewise. * sysdeps/generic/s_ctan.c (__ctan): Likewise. * sysdeps/generic/s_ctanf.c (__ctanf): Likewise. * sysdeps/generic/s_ctanl.c (__ctanl): Likewise. Looking at the diff in the sources we see that there is a better treatment of the case where the denominator is equal to 0.0: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/generic/s_ctanh.c.diff?r1=1.2r2=1.3cvsroot=glibcf=h John, could you please confirm that this would fix the bug? -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 7-Sep-2005, Laurent Bonnaud wrote: | octave needs to be recompiled with g++ 4.0 and a newer libhdf5: The last time I tried compiling Octave with g++ 4.0 (actually 4.0.1), Octave failed several of its tests. So maybe g++ 4.0 is not quite ready yet? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
The last time I tried compiling Octave with g++ 4.0 (actually 4.0.1), Octave failed several of its tests. So maybe g++ 4.0 is not quite ready yet? Too bad :. Did you submit bugs to the gcc or Debian BTS (I looked rapidly and did not find a relevant bug) ? If yes, could you please provide bug numbers ? 4.0.2 RC1 should be out this week-end. Hopefully we'll soon have updated Debian packages to test octave with... g++ 3.4 could also be used as a fallback since it is ABI-compatible with g++ 4.0. I am currently trying an octave package rebuild with the latest g++ 3.4 and 4.0 available in Debian. Is the test suite integrated in the package build ? -- Laurent Bonnaud. http://www.lis.inpg.fr/pages_perso/bonnaud/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On ven, 2005-09-09 at 16:21 +0200, Laurent Bonnaud wrote: I am currently trying an octave package rebuild with the latest g++ 3.4 and 4.0 available in Debian. Is the test suite integrated in the package build ? It seems so. During the build with g++ 4.0 I get only 2 failures out of 1200 test cases (see below). Isn't it better to have a package with a few bugs (and appropriate user warnings) rather than no package at all ? In the mean time, I have put my packages here: http://www.lis.inpg.fr/pages_perso/bonnaud/octave/ -- Laurent Bonnaud. http://www.lis.inpg.fr/pages_perso/bonnaud/ $ g++ -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c ++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6) $ fakeroot apt-get -b source octave2.1 [...] /usr/bin/make check make[1]: Entering directory `/data/bonnaud/octave2.1-2.1.71' /usr/bin/make -f octMakefile check make[2]: Entering directory `/data/bonnaud/octave2.1-2.1.71' /usr/bin/make -C test check make[3]: Entering directory `/data/bonnaud/octave2.1-2.1.71/test' WARNING: Couldn't find tool init file Test Run By bonnaud on Fri Sep 9 16:56:41 2005 Native configuration is i686-pc-linux-gnu === octave tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using ./config/unix.exp as tool-and-target-specific interface file. Running ./octave.test/args/args.exp ... Running ./octave.test/arith/arith.exp ... FAIL: octave.test/arith/coth-1.m Running ./octave.test/audio/audio.exp ... Running ./octave.test/contin/contin.exp ... Running ./octave.test/control/control.exp ... Running ./octave.test/diffeq/diffeq.exp ... Running ./octave.test/error/error.exp ... Running ./octave.test/eval-catch/eval-catch.exp ... Running ./octave.test/eval/eval.exp ... Running ./octave.test/for/for.exp ... Running ./octave.test/global/global.exp ... Running ./octave.test/if/if.exp ... Running ./octave.test/image/image.exp ... Running ./octave.test/index-wfi-f/index.exp ... Running ./octave.test/index-wfi-t/index.exp ... Running ./octave.test/infnan/infnan.exp ... Running ./octave.test/io/io.exp ... Running ./octave.test/linalg/linalg.exp ... Running ./octave.test/logical-wfi-f/logical-wfi-f.exp ... Running ./octave.test/logical-wfi-t/logical-wfi-t.exp ... Running ./octave.test/matrix/matrix.exp ... Running ./octave.test/nonlin/nonlin.exp ... Running ./octave.test/number/number.exp ... Running ./octave.test/optim/optim.exp ... Running ./octave.test/plot/plot.exp ... Running ./octave.test/poly/poly.exp ... Running ./octave.test/prefer/prefer.exp ... Running ./octave.test/quad/quad.exp ... Running ./octave.test/recursion/recursion.exp ... Running ./octave.test/return/return.exp ... Running ./octave.test/set/set.exp ... Running ./octave.test/signal/signal.exp ... Running ./octave.test/stats/stats.exp ... Running ./octave.test/string/string.exp ... Running ./octave.test/struct/struct.exp ... Running ./octave.test/switch/switch.exp ... Running ./octave.test/system/system.exp ... FAIL: octave.test/system/tilde_expand-1.m Running ./octave.test/transpose/transpose.exp ... Running ./octave.test/try/try.exp ... Running ./octave.test/unwind/unwind.exp ... Running ./octave.test/while/while.exp ... === octave Summary === # of expected passes1198 # of unexpected failures2 ../src/octave version 2.1.71 (i486-pc-linux-gnu). Copyright (C) 2005 John W. Eaton. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or FITNESS FOR A PARTICULAR PURPOSE. Additional information about Octave is available at http://www.octave.org. Please contribute if you find this software useful. For more information, visit http://www.octave.org/help-wanted.html Report bugs to [EMAIL PROTECTED] (but first, please read http://www.octave.org/bugs.html to learn how to write a helpful report). make[3]: *** [check] Error 1 make[3]: Leaving directory `/data/bonnaud/octave2.1-2.1.71/test' make[2]: *** [check] Error 2 make[2]: Leaving directory `/data/bonnaud/octave2.1-2.1.71' make[1]: *** [check] Error 2 make[1]: Leaving directory `/data/bonnaud/octave2.1-2.1.71' make: [check-stamp] Error 2 (ignored) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On ven, 2005-09-09 at 16:21 +0200, Laurent Bonnaud wrote: I am currently trying an octave package rebuild with the latest g++ 3.4 and 4.0 available in Debian. Here is the build with g++-3.4. It is worse than with g++-4.0 (6 failures instead of 2). $ g++ -v Reading specs from /usr/lib/gcc/i486-linux-gnu/3.4.5/specs Configured with: ../src/configure -v --enable-languages=c,c ++,f77,pascal,objc,ada --prefix=/usr --libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug i486-linux-gnu Thread model: posix gcc version 3.4.5 20050821 (prerelease) (Debian 3.4.4-8) $ fakeroot apt-get -b source octave2.1 [...] /usr/bin/make check make[1]: Entering directory `/data/bonnaud/octave2.1-2.1.71' /usr/bin/make -f octMakefile check make[2]: Entering directory `/data/bonnaud/octave2.1-2.1.71' /usr/bin/make -C test check make[3]: Entering directory `/data/bonnaud/octave2.1-2.1.71/test' WARNING: Couldn't find tool init file Test Run By bonnaud on Fri Sep 9 18:36:05 2005 Native configuration is i686-pc-linux-gnu === octave tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using ./config/unix.exp as tool-and-target-specific interface file. Running ./octave.test/args/args.exp ... Running ./octave.test/arith/arith.exp ... FAIL: octave.test/arith/coth-1.m Running ./octave.test/audio/audio.exp ... Running ./octave.test/contin/contin.exp ... Running ./octave.test/control/control.exp ... Running ./octave.test/diffeq/diffeq.exp ... FAIL: octave.test/diffeq/dassl-1.m FAIL: octave.test/diffeq/dassl-2.m Running ./octave.test/error/error.exp ... Running ./octave.test/eval-catch/eval-catch.exp ... Running ./octave.test/eval/eval.exp ... Running ./octave.test/for/for.exp ... Running ./octave.test/global/global.exp ... Running ./octave.test/if/if.exp ... Running ./octave.test/image/image.exp ... Running ./octave.test/index-wfi-f/index.exp ... Running ./octave.test/index-wfi-t/index.exp ... Running ./octave.test/infnan/infnan.exp ... Running ./octave.test/io/io.exp ... Running ./octave.test/linalg/linalg.exp ... Running ./octave.test/logical-wfi-f/logical-wfi-f.exp ... Running ./octave.test/logical-wfi-t/logical-wfi-t.exp ... Running ./octave.test/matrix/matrix.exp ... Running ./octave.test/nonlin/nonlin.exp ... Running ./octave.test/number/number.exp ... Running ./octave.test/optim/optim.exp ... Running ./octave.test/plot/plot.exp ... Running ./octave.test/poly/poly.exp ... Running ./octave.test/prefer/prefer.exp ... Running ./octave.test/quad/quad.exp ... FAIL: octave.test/quad/quad-1.m FAIL: octave.test/quad/quad-2.m Running ./octave.test/recursion/recursion.exp ... Running ./octave.test/return/return.exp ... Running ./octave.test/set/set.exp ... Running ./octave.test/signal/signal.exp ... Running ./octave.test/stats/stats.exp ... Running ./octave.test/string/string.exp ... Running ./octave.test/struct/struct.exp ... Running ./octave.test/switch/switch.exp ... Running ./octave.test/system/system.exp ... FAIL: octave.test/system/tilde_expand-1.m Running ./octave.test/transpose/transpose.exp ... Running ./octave.test/try/try.exp ... Running ./octave.test/unwind/unwind.exp ... Running ./octave.test/while/while.exp ... === octave Summary === # of expected passes1194 # of unexpected failures6 ../src/octave version 2.1.71 (i486-pc-linux-gnu). Copyright (C) 2005 John W. Eaton. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or FITNESS FOR A PARTICULAR PURPOSE. Additional information about Octave is available at http://www.octave.org. Please contribute if you find this software useful. For more information, visit http://www.octave.org/help-wanted.html Report bugs to [EMAIL PROTECTED] (but first, please read http://www.octave.org/bugs.html to learn how to write a helpful report). make[3]: *** [check] Error 1 make[3]: Leaving directory `/data/bonnaud/octave2.1-2.1.71/test' make[2]: *** [check] Error 2 make[2]: Leaving directory `/data/bonnaud/octave2.1-2.1.71' make[1]: *** [check] Error 2 make[1]: Leaving directory `/data/bonnaud/octave2.1-2.1.71' make: [check-stamp] Error 2 (ignored) -- Laurent Bonnaud. http://www.lis.inpg.fr/pages_perso/bonnaud/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 9-Sep-2005, Laurent Bonnaud wrote: | Too bad :. Did you submit bugs to the gcc or Debian BTS (I looked | rapidly and did not find a relevant bug) ? No, sorry, I didn't. | g++ 3.4 could also be used as a fallback since it is ABI-compatible with | g++ 4.0. Is libstdc++ also completely compatible? Have there been absolutely no changes that could affect layout of class members? jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
| Too bad :. Did you submit bugs to the gcc or Debian BTS (I looked | rapidly and did not find a relevant bug) ? No, sorry, I didn't. I guess it would be time consuming to isolate the failure and produce a small and self-contained test case of bad code generation. | g++ 3.4 could also be used as a fallback since it is ABI-compatible with | g++ 4.0. Is libstdc++ also completely compatible? Have there been absolutely no changes that could affect layout of class members? This question is no longer a concern since my tests have shown that g++ 3.4 is worse than g++ 4.0. -- Laurent Bonnaud. http://www.lis.inpg.fr/pages_perso/bonnaud/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 9-Sep-2005, Laurent Bonnaud wrote: | Is libstdc++ also completely compatible? Have there been absolutely | no changes that could affect layout of class members? | | This question is no longer a concern since my tests have shown that g++ | 3.4 is worse than g++ 4.0. But unless we are absolutely sure that everything is compatible from one release to another, it does matter. Suppose the Octave package is compiled with 4.0 (for example) and the dependencies are set for g++ = 4.0 then later someone installs 4.1. Then if there are incompatibilities (a change in the layout of some data members in a standard class, for example) then there can be problems when an Octave user builds a dynamically linked function using mkoctfile, because mkoctfile is only asking for g++ and the user gets g++-4.1, not g++-4.0 In the old days, the I think Octave was configured with something like CC=gcc-4.0 CXX=g++-4.0 F77=g77-4.0 so that these names would be put into the mkoctfile script. That way, when someone later ran mkoctfile, they would be sure to get the same version of the compiler that was used to build the Octave binary they were using. Yes, I would prefer to not have to fix the compiler versions, but unless we know that they are compatible, I see no other option. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327027: [Pkg-octave-devel] Bug#327027: octave2.1: not installable in sid
On 9-Sep-2005, Laurent Bonnaud wrote:
| Here is the build with g++-3.4. It is worse than with g++-4.0 (6
| failures instead of 2).
Odd. My results were:
3.3: all tests pass
3.4: all tests pass
4.0: 1 failed (FAIL: octave.test/arith/coth-1.m)
My system is Debian testing, updated to the latest packages just
before running my tests. I built Octave 2.1.71 (downloaded from the
Octave ftp site) using 3.3, 3.4, and 4.0, with the following commands:
tar zxf octave-2.1.71.tar.gz
top=`pwd`
for v in 3.3 3.4
do
mkdir $top/$v
cd $top/$v
## since there is no g77-4.0, I used the default g77 (3.4) when
## building with gcc/g++ 4.0
if [ $v = 4.0 ]; then G77=g77; else G77=g77-$v; fi
../octave-2.1.71/configure --enable-shared --disable-static CC=gcc-$v
CXX=g++-$v F77=$G77
make all check
done
The failed test is:
x = [pi/2*i, 3*pi/2*i];
v = [0, 0];
all (abs (coth (x) - v) sqrt (eps))
Running this by hand (and looking at what is actually produced by coth
instead of just the final result) shows
octave:4 coth(x)
ans =
NaN - NaNi NaN - NaNi
At least it is NaN, which will show up in obvious ways later on in a
calculation, instead of just some incorrect numerical result. But
still, I would prefer that this bug be fixed before Octave packages
built with gcc 4.0 are distributed.
Octave's coth function is just a simple
function w = coth (z)
if (nargin != 1)
usage (coth (z));
endif
w = 1 ./ tanh (z);
endfunction
but tanh is a built-in function, and it is returning
octave:7 tanh (x)
ans =
NaN + Infi NaN + Infi
for the same X as above.
The 4.0 complex header has
// 26.2.8/15 tanh(__z): Returns the hyperbolic tangent of __z.
templatetypename _Tp
inline complex_Tp
__complex_tanh(const complex_Tp __z)
{ return std::sinh(__z) / std::cosh(__z); }
#if _GLIBCXX_USE_C99_COMPLEX
inline __complex__ float
__complex_tanh(__complex__ float __z) { return __builtin_ctanhf(__z); }
inline __complex__ double
__complex_tanh(__complex__ double __z) { return __builtin_ctanh(__z); }
inline __complex__ long double
__complex_tanh(const __complex__ long double __z)
{ return __builtin_ctanhl(__z); }
templatetypename _Tp
inline complex_Tp
tanh(const complex_Tp __z) { return __complex_tanh(__z.__rep()); }
#else
templatetypename _Tp
inline complex_Tp
tanh(const complex_Tp __z) { return __complex_tanh(__z); }
#endif
while the 3.3 complex header has
templatetypename _Tp
inline complex_Tp
tanh(const complex_Tp __z)
{
return sinh(__z) / cosh(__z);
}
so my guess is the bug is in the __builtin_ctanh code.
Here is a simpler test case:
#include cmath
#include iostream
#include complex
int
main (void)
{
std::cout std::tanh (std::complexdouble (0, M_PI/2)) std::endl;
std::cout std::tanh (std::complexdouble (0, 3*M_PI/2)) std::endl;
return 0;
}
I think this should produce (0, inf) in both cases. With 3.3, it is
still not right, as it produces
(0,1.63318e+16)
(0,5.44393e+15)
but at least it does not give NaN.
Or, is the C math library standard written so that tanh is required to
give (nan, inf) here?
Thanks,
jwe
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
