Bug#676800: [Pkg-octave-devel] Bug#676800: octave-java: completely breaks octave

2012-06-20 Thread John W. Eaton 
On 20-Jun-2012, Sébastien Villemot wrote:

| John W. Eaton j...@octave.org writes:
| 
|  I'd like to help debug this problem but I need some help.
| 
| Thanks for volunteering!
| 
|  I need to be able to install a debug version of Octave (preferably the
|  current development sources) and build the Java package also with
|  debugging symbols.  I'm using Debian testing.  What packages do I need
|  to install?  After doing
| 
|pkg install java-1.2.8.tar.gz
| 
|  apparently successfully, I'm seeing
| 
|octave javaclasspath
|warning: timestamp on file 
/usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so is in the future
|error: java_invoke: 
/usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so: failed to load: 
/usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so: cannot open shared 
object file: No such file or directory
|error: called from:
|error:   /home/jwe/octave/java-1.2.8/javaclasspath.m at line 49, column 14
| 
| You need this patch (incorporated in the octave-java package):
| 
|  
http://anonscm.debian.org/gitweb/?p=pkg-octave/octave-java.git;a=blob;f=debian/patches/libjvm.patch;h=cc847293d00ae09ac74e8eca833dbafdd48918a2;hb=19a7fdc2264cb0166f5324677bf2615252fda8e3
| 
| Also, /usr/lib/jvm/default-java points to OpenJDK 6 on my Debian sid
| system. If you want to select OpenJDK 7, you need to set the JAVA_HOME
| variable to:
| 
|  export JAVA_HOME = /usr/lib/jvm/java-7-openjdk-amd64
| 
| (this is done in debian/rules of the octave-java package).

Thanks.  With that, I'm able to build the java package.  Running
Octave with valgrind and executing javaclasspath at the Octave prompt,
I see a lot of messages, starting with:

  ==29404== Warning: set address range perms: large range [0x393a7000, 
0x1371a7000) (defined)
  ==29404== Warning: set address range perms: large range [0x393a7000, 
0x1371a7000) (noaccess)
  ==29404== Warning: set address range perms: large range [0x393a7000, 
0x1371a7000) (defined)
  ==29404== Warning: set address range perms: large range [0x1371a7000, 
0x234fa7000) (defined)
  ==29404== Warning: set address range perms: large range [0x234fa7000, 
0x332da7000) (defined)
  ==29404== Warning: set address range perms: large range [0x41036a000, 
0x50e16a000) (defined)
  ==29404== Warning: set address range perms: large range [0x50e16a000, 
0x60bf6a000) (defined)
  ==29404== Warning: set address range perms: large range [0x60bf6a000, 
0x709d6a000) (defined)
  ==29404== Warning: set address range perms: large range [0x393a7000, 
0x1371a7000) (noaccess)
  ==29404== Warning: set address range perms: large range [0x1371a7000, 
0x234fa7000) (noaccess)
  ==29404== Warning: set address range perms: large range [0x234fa7000, 
0x332da7000) (noaccess)
  ==29404== Warning: set address range perms: large range [0x41036a000, 
0x50e16a000) (noaccess)
  ==29404== Warning: set address range perms: large range [0x50e16a000, 
0x60bf6a000) (noaccess)
  ==29404== Warning: set address range perms: large range [0x60bf6a000, 
0x70220) (noaccess)
  ==29404== Warning: set address range perms: large range [0x393a7000, 
0x1371b7000) (defined)
  ==29404== Warning: set address range perms: large range [0x393a7000, 
0x1371b7000) (noaccess)
  ==29404== Warning: set address range perms: large range [0x393a7000, 
0x1371c) (defined)
  ==29404== Invalid write of size 4
  ==29404==at 0x163212BD: ???
  ==29404==by 0x16311437: ???
  ==29404==by 0x1554C68D: JavaCalls::call_helper(JavaValue*, methodHandle*, 
JavaCallArguments*, Thread*) (in 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
  ==29404==by 0x1554C134: JavaCalls::call(JavaValue*, methodHandle, 
JavaCallArguments*, Thread*) (in 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
  ==29404==by 0x1550ECA0: 
instanceKlass::call_class_initializer_impl(instanceKlassHandle, Thread*) (in 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
  ==29404==by 0x1550ED1C: instanceKlass::call_class_initializer(Thread*) 
(in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
  ==29404==by 0x1550EEF0: 
instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
  ==29404==by 0x1550F40A: instanceKlass::initialize(Thread*) (in 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
  ==29404==by 0x1550F17F: 
instanceKlass::initialize_impl(instanceKlassHandle, Thread*) (in 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
  ==29404==by 0x1550F40A: instanceKlass::initialize(Thread*) (in 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
  ==29404==by 0x1582E6F5: Threads::create_vm(JavaVMInitArgs*, bool*) (in 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
  ==29404==by 0x15569D67: JNI_CreateJavaVM (in 
/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
  ==29404==  Address 0x7feffd960

Bug#676800: [Pkg-octave-devel] Bug#676800: octave-java: completely breaks octave

2012-06-20 Thread John W. Eaton 
On 20-Jun-2012, Sébastien Villemot wrote:

| Looks like these valgrind errors are generated by the JVM and not by the
| java package. They are probably not a cause of concern.
| 
| I don't know how to generate a difference in the valgrind logs, and I
| don't have one between OpenJDK 6 and 7.
| 
| The only clear manifestation of the problem is the crashes that I
| experience with octave-java compiled against Octave, as reported
| initially in this bug.
| 
| Are you able to replicate the crash?

No, I haven't seen a crash yet.

| On sid, install both octave-io and
| octave-java, and octave should crash at runtime.

Sorry, I've never been able to keep track of what sid or wheezy or
whatever means.

I stay fairly current with the testing distribution, whatever that is,
on an amd64 system.

You'll have to tell me precisely what to install and what commands to
run to reproduce the crash.

jwe



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#676800: [Pkg-octave-devel] Bug#676800: octave-java: completely breaks octave

2012-06-19 Thread John W. Eaton 
On  9-Jun-2012, Sébastien Villemot wrote:

| Package: octave-java
| Version: 1.2.8-4
| Severity: grave
| Tags: sid
| 
| This version of octave-java completely breaks octave.
| 
| For example, if octave-io is also installed, octave miserably fails at launch
| time:
| 
| octave: lex.ll :2420 : void handle_number():  L'assertion « nread == 1 » a 
échoué.
| panic: Abandon -- stopping myself...
| Abandon
| 
| Various other kinds of strange breakage happens (e.g. numerical errors). It
| looks like a memory corruption problem.
| 
| Since downgrading to octave-java 1.2.8-3 solves the issue, the cause of the
| problem is clearly the switch from OpenJDK 6 to 7.
| 
| This needs to be investigated with the openjdk-7 maintainers.

I'd like to help debug this problem but I need some help.

I need to be able to install a debug version of Octave (preferably the
current development sources) and build the Java package also with
debugging symbols.  I'm using Debian testing.  What packages do I need
to install?  After doing

  pkg install java-1.2.8.tar.gz

apparently successfully, I'm seeing

  octave javaclasspath
  warning: timestamp on file 
/usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so is in the future
  error: java_invoke: /usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so: 
failed to load: /usr/lib/jvm/default-java/jre/lib/amd64/client/libjvm.so: 
cannot open shared object file: No such file or directory
  error: called from:
  error:   /home/jwe/octave/java-1.2.8/javaclasspath.m at line 49, column 14

I have the following packages installed:

  $ dpkg -l '*openjdk*' | grep ^ii
  ii  openjdk-6-dbg: 6b24-1.11.1-6  Java runtime based on OpenJDK (debugging sym
  ii  openjdk-6-jdk: 6b24-1.11.1-6  OpenJDK Development Kit (JDK)
  ii  openjdk-6-jre: 6b24-1.11.1-6  OpenJDK Java runtime, using Hotspot JIT
  ii  openjdk-6-jre- 6b24-1.11.1-6  OpenJDK Java runtime, using Hotspot JIT (hea
  ii  openjdk-6-jre- 6b24-1.11.1-6  OpenJDK Java runtime (architecture independe
  ii  openjdk-7-jdk: 7~u3-2.1.1~pre OpenJDK Development Kit (JDK)
  ii  openjdk-7-jre: 7~u3-2.1.1~pre OpenJDK Java runtime, using Hotspot JIT
  ii  openjdk-7-jre- 7~u3-2.1.1~pre OpenJDK Java runtime, using Hotspot JIT (hea
  ii  openjdk-7-jre- 7~u3-2.1.1~pre OpenJDK Java runtime (architecture independe

  $ dpkg -l '*default-j*' | grep ^ii
  ii  default-jdk1:1.6-47   Standard Java or Java compatible Development
  ii  default-jre1:1.6-47   Standard Java or Java compatible Runtime
  ii  default-jre-he 1:1.6-47   Standard Java or Java compatible Runtime (he

What am I missing, or what is misconfigured that I don't have
libjvm.so in the /usr/lib/jvm/default-java/jre/lib/amd64/client
directory?

jwe



--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: trivial fix

2011-11-01 Thread John W. Eaton 
Hi,

Did you see the following message from me?  I think I found the reason
that libranlib.la is not being built, and a relatively simple fix.

jwe


On 25-Oct-2011, John W. Eaton wrote:

| On 24-Oct-2011, John W. Eaton wrote:
| 
| | On 24-Oct-2011, Thomas Weber wrote:
| | 
| | | On Thu, Sep 01, 2011 at 09:03:57PM +0200, Thomas Weber wrote:
| | |  On Tue, Aug 23, 2011 at 12:24:17PM -0400, John W. Eaton wrote:
| | |   If you don't want to change octlibdir, then you can change the lines
| | |   like
| | |   
| | | octlib_LTLIBRARIES = liboctave.la
| | |   
| | |   in the Makefile.am files to be
| | |   
| | | lib_LTLIBRARIES = liboctave.la
| | |   
| | |   instead.  It's the octlib (or lib) prefix that is used to generate the
| | |   variable that determines the installation directory. 
| | | 
| | | I did the change above, but the build fails almost always (almost = in a
| | | clean chroot). It builds reliable in my normal work directory, which is
| | | strange (I already looked at timestamp issues, but I do not think that
| | | that is the problem). It always fails when linking in libcruft/ with the
| | | error message:
| | | 
| | | libtool: link: cannot find the library `libranlib.la' or unhandled
| | | argument `libranlib.la'
| | | 
| | | I've put a log file of the build at
| | | http://people.debian.org/~tweber/octave.log.bz2
| | | 
| | | The commands effectively run are:
| | |   automake --foreign --verbose
| | |   ./configure --build=x86_64-linux-gnu --prefix=/usr 
| | |   make -j1
| | | 
| | | Do you have any ideas?
| | 
| | I can't reproduce the problem, but I'm not sure I'm doing exactly the
| | same thing as you.
| | 
| | Can you please give me step-by-step instructions for how to download
| | exactly the Debian package files and what to do with them to try to
| | generate the package?  Jordi gave me that info a few days ago and with
| | what he showed me, I was able to generate the error you mention
| | above.  But now I can't find his instructions.
| 
| OK, Jordi gave me the instructions and I can reproduce the problem.
| 
| When libcruft/Makefile.am contains
| 
|   octlib_LTLIBRARIES = libcruft.la
|   noinst_LTLIBRARIES = libranlib.la
| 
| The generated Makefile.in file contains
| 
|   LTLIBRARIES = $(noinst_LTLIBRARIES) $(octlib_LTLIBRARIES)
|   ...
|   all-am: Makefile $(LTLIBRARIES) $(HEADERS)
| 
| and when it contains
| 
|   lib_LTLIBRARIES = libcruft.la
|   noinst_LTLIBRARIES = libranlib.la
| 
| LTLIBRARIES is defined to be
| 
|   LTLIBRARIES = $(lib_LTLIBRARIES) $(noinst_LTLIBRARIES)
| 
| So apparently these variables are sorted alphabetically when creating
| the LTLIBRARIES variable.  Then Make is building these libraries in
| the order they are listed, so the latter fails, because libcruft.la
| depends on libranlib.la, but it is not built yet.
| 
| I think automake is supposed to be using the libcruft_la_LIBADD
| variable to generate the dependency list for libcruft.la, but it
| doesn't seem to be doing that.
| 
| The quick fix appears to be adding libranlib.la to the
| libcruft_la_DEPENDENCIES variable, so change the line
| 
|   libcruft_la_DEPENDENCIES = cruft.def
| 
| in libcruft/Makefile.am to be
| 
|   libcruft_la_DEPENDENCIES = cruft.def libranlib.la
| 
| instead.
| 
| jwe
| 
| 
| 
| ___
| Pkg-octave-devel mailing list
| pkg-octave-de...@lists.alioth.debian.org
| http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-octave-devel



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: trivial fix

2011-10-25 Thread John W. Eaton 
On 24-Oct-2011, John W. Eaton wrote:

| On 24-Oct-2011, Thomas Weber wrote:
| 
| | On Thu, Sep 01, 2011 at 09:03:57PM +0200, Thomas Weber wrote:
| |  On Tue, Aug 23, 2011 at 12:24:17PM -0400, John W. Eaton wrote:
| |   If you don't want to change octlibdir, then you can change the lines
| |   like
| |   
| | octlib_LTLIBRARIES = liboctave.la
| |   
| |   in the Makefile.am files to be
| |   
| | lib_LTLIBRARIES = liboctave.la
| |   
| |   instead.  It's the octlib (or lib) prefix that is used to generate the
| |   variable that determines the installation directory. 
| | 
| | I did the change above, but the build fails almost always (almost = in a
| | clean chroot). It builds reliable in my normal work directory, which is
| | strange (I already looked at timestamp issues, but I do not think that
| | that is the problem). It always fails when linking in libcruft/ with the
| | error message:
| | 
| | libtool: link: cannot find the library `libranlib.la' or unhandled
| | argument `libranlib.la'
| | 
| | I've put a log file of the build at
| | http://people.debian.org/~tweber/octave.log.bz2
| | 
| | The commands effectively run are:
| | automake --foreign --verbose
| | ./configure --build=x86_64-linux-gnu --prefix=/usr 
| | make -j1
| | 
| | Do you have any ideas?
| 
| I can't reproduce the problem, but I'm not sure I'm doing exactly the
| same thing as you.
| 
| Can you please give me step-by-step instructions for how to download
| exactly the Debian package files and what to do with them to try to
| generate the package?  Jordi gave me that info a few days ago and with
| what he showed me, I was able to generate the error you mention
| above.  But now I can't find his instructions.

OK, Jordi gave me the instructions and I can reproduce the problem.

When libcruft/Makefile.am contains

  octlib_LTLIBRARIES = libcruft.la
  noinst_LTLIBRARIES = libranlib.la

The generated Makefile.in file contains

  LTLIBRARIES = $(noinst_LTLIBRARIES) $(octlib_LTLIBRARIES)
  ...
  all-am: Makefile $(LTLIBRARIES) $(HEADERS)

and when it contains

  lib_LTLIBRARIES = libcruft.la
  noinst_LTLIBRARIES = libranlib.la

LTLIBRARIES is defined to be

  LTLIBRARIES = $(lib_LTLIBRARIES) $(noinst_LTLIBRARIES)

So apparently these variables are sorted alphabetically when creating
the LTLIBRARIES variable.  Then Make is building these libraries in
the order they are listed, so the latter fails, because libcruft.la
depends on libranlib.la, but it is not built yet.

I think automake is supposed to be using the libcruft_la_LIBADD
variable to generate the dependency list for libcruft.la, but it
doesn't seem to be doing that.

The quick fix appears to be adding libranlib.la to the
libcruft_la_DEPENDENCIES variable, so change the line

  libcruft_la_DEPENDENCIES = cruft.def

in libcruft/Makefile.am to be

  libcruft_la_DEPENDENCIES = cruft.def libranlib.la

instead.

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: trivial fix

2011-10-24 Thread John W. Eaton 
On 24-Oct-2011, Thomas Weber wrote:

| On Thu, Sep 01, 2011 at 09:03:57PM +0200, Thomas Weber wrote:
|  On Tue, Aug 23, 2011 at 12:24:17PM -0400, John W. Eaton wrote:
|   If you don't want to change octlibdir, then you can change the lines
|   like
|   
| octlib_LTLIBRARIES = liboctave.la
|   
|   in the Makefile.am files to be
|   
| lib_LTLIBRARIES = liboctave.la
|   
|   instead.  It's the octlib (or lib) prefix that is used to generate the
|   variable that determines the installation directory. 
| 
| I did the change above, but the build fails almost always (almost = in a
| clean chroot). It builds reliable in my normal work directory, which is
| strange (I already looked at timestamp issues, but I do not think that
| that is the problem). It always fails when linking in libcruft/ with the
| error message:
| 
| libtool: link: cannot find the library `libranlib.la' or unhandled
| argument `libranlib.la'
| 
| I've put a log file of the build at
| http://people.debian.org/~tweber/octave.log.bz2
| 
| The commands effectively run are:
|   automake --foreign --verbose
|   ./configure --build=x86_64-linux-gnu --prefix=/usr 
|   make -j1
| 
| Do you have any ideas?

I can't reproduce the problem, but I'm not sure I'm doing exactly the
same thing as you.

Can you please give me step-by-step instructions for how to download
exactly the Debian package files and what to do with them to try to
generate the package?  Jordi gave me that info a few days ago and with
what he showed me, I was able to generate the error you mention
above.  But now I can't find his instructions.

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: Bug#637787: trivial fix

2011-09-01 Thread John W. Eaton 
On  1-Sep-2011, Thomas Weber wrote:

| On Tue, Aug 23, 2011 at 12:24:17PM -0400, John W. Eaton wrote:
| 
|  Is the current problem that the libraries are placed in a directory
|  that has a version number in the name, or does dpkg-shlibeps not find
|  files in subdirectories of /usr/lib at all?
| 
| That's a good question; I'm not really sure. 
| I don't think however, that the version should be in the installation
| path - what happens when 3.4.3 comes around?
| You should take my words on this with a grain of salt, though. I'm new
| to it myself.

I agree that if the shared libraries contain proper version
information, then the package version number should not be a part of
the name of the library directory.  I asked about whether the
libraries could go in a subdirectory because I think it would be
better to have them installed in /usr/lib/octave instead of /usr/lib.
Looking at /usr/lib on my Debian system, there seem to be a number of
other packages that use subdirectories for library files, so maybe it
is OK?

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: Bug#637787: trivial fix

2011-08-23 Thread John W. Eaton 
On 23-Aug-2011, Thomas Weber wrote:

| On Mon, Aug 22, 2011 at 02:28:54PM -0400, John W. Eaton wrote:
|  On 19-Aug-2011, Thomas Weber wrote:
|  
|  | The problem is that dpkg-shlibdeps doesn't like the fact that Octave
|  | uses normal SONAMEs for its libraries now, but ships them in a private
|  | path (so dpkg-shlibdeps doesn't find them and aborts).
|  | So, I'm reading through far too many books/tutorials about libtool and
|  | friends now just so that the libraries end up under /usr/lib.
|  
|  Octave's Makefile.am files have lines like
|  
|octlib_LTLIBRARIES = liboctave.la
|octlib_LTLIBRARIES = liboctinterp.la
|  
|  so these files are installed in $(octlibdir) and the default
|  definition of octlibdir is set in configure.ac to be
|  
|'$(libdir)/octave/$(version)'
|  
|  You are of course free to redefine this to be '$(libdir)' instead, and
|  I think that will cause the libraries to be installed into /usr/lib if
|  you set $(prefix) to be /usr.
| 
| Yes, but I don't want to change $(octlibdir), because other software
| might use that for specific libraries. Also, I need to get a better
| understanding of libtool, autoconf and friends anyway.

If you don't want to change octlibdir, then you can change the lines
like

  octlib_LTLIBRARIES = liboctave.la

in the Makefile.am files to be

  lib_LTLIBRARIES = liboctave.la

instead.  It's the octlib (or lib) prefix that is used to generate the
variable that determines the installation directory. 

Maybe we should change the Octave sources to install the Octave
libraries in $libdir instead of $octlibdir?  Or would $pkglibdir be
better?  That is predefined by automake, so writing

  pkglib_LTLIBRARIES = liboctave.la

should cause liboctave to be installed in $(libdir)/@PACKAGE@ (with
octave substituted for @PACKAGE@ by configure.

Is the current problem that the libraries are placed in a directory
that has a version number in the name, or does dpkg-shlibeps not find
files in subdirectories of /usr/lib at all?

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#637787: [Pkg-octave-devel] Bug#637787: Bug#637787: Bug#637787: trivial fix

2011-08-22 Thread John W. Eaton 
On 19-Aug-2011, Thomas Weber wrote:

| The problem is that dpkg-shlibdeps doesn't like the fact that Octave
| uses normal SONAMEs for its libraries now, but ships them in a private
| path (so dpkg-shlibdeps doesn't find them and aborts).
| So, I'm reading through far too many books/tutorials about libtool and
| friends now just so that the libraries end up under /usr/lib.

Octave's Makefile.am files have lines like

  octlib_LTLIBRARIES = liboctave.la
  octlib_LTLIBRARIES = liboctinterp.la

so these files are installed in $(octlibdir) and the default
definition of octlibdir is set in configure.ac to be

  '$(libdir)/octave/$(version)'

You are of course free to redefine this to be '$(libdir)' instead, and
I think that will cause the libraries to be installed into /usr/lib if
you set $(prefix) to be /usr.

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#567962: [Pkg-octave-devel] Bug#567962: Bug#567962: needs to be rebuilt against libhdf5-1.8.4

2010-02-01 Thread John W. Eaton 
On  1-Feb-2010, Thomas Weber wrote:

| On Mon, Feb 01, 2010 at 03:59:25PM +0100, Bas Zoetekouw wrote:
|  Hi!
|  
|   octave-specfun is currently uninstallable in sid, as it depends on
|   libhdf5-1.8.3, while octave3.2 depends on libhdf5-1.8.4.
|   Please rebuild octave-specfun against libhdf5-1.8.4.
|  
|  Actually, on further inspection, it seems that there is no need at all
|  to link against libhdf (and zlib, and libfftw3, and libcurses5, etc).
|  The package itself doesn't use these symbols, so it shouldn't be linked
|  against them.
|  This seems to be an issue for all octave packages, BTW.
| 
| Yes. mkoctfile (used to build these files) links them against all
| libraries that Octave itself uses. I think this has changed in
| upstream's development version, though.

No, it hasn't changed.  All .oct files depend on liboctinterp, which
depends on liboctave and a number of other libraries, and liboctave
depends on libcruft and a number of other libraries.  So ultimately, a
.oct file is linked with everything taht Octave is linked with.  I
don't see that it matters whether this is done directly or
indirectly, and it seems to be that some systems cannot do the linking
indirectly, so the dependencies are all listed when the .oct file is
linked.

If you have a better solution that is platform neutral and fits
within the automake+libtool framework, then please start a thread on
the maintain...@octave.org list.

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

2009-06-17 Thread John W. Eaton 
On 16-Jun-2009, Rafael Laboissiere wrote:

| * Rafael Laboissiere raf...@debian.org [2009-06-15 21:55]:
| 
|  * John W. Eaton j...@jweaton.org [2009-06-15 13:25]:
|  
|   On 15-Jun-2009, Rafael Laboissiere wrote:
|   
|   | Anyway, it is funny to see how long this bug lived in the code and was
|   | just awakened by the crappy mips/mipsel architecture...
|   
|   Also strange that it didn't show up until now, even on mips.  Maybe a
|   compiler change?
|  
|  Probably.
|  
|  Anyway, these differences on floating point representation/manipulation
|  among the architectures make me kinda nervous.
| 
| I am wondering whether we could add a regression test like the following
| to data.cc (or wherever):
| 
| /*
| %!test
| %! format short
| %! for r = [0, Inf -Inf, NaN]
| %! for i = [0, Inf -Inf, NaN]
| %! complex (r, i)
| %! endfor
| %! endfor
| */
| 
| Yes, the 'complex (r, i)' would lack the semicolon, just to exercise the
| code in pr-output.cc.

Are you sure you would want this?  It won't tell you if the printing
is correct without manual inspection, and will clutter the output from
running make check with

src/pr-output.cc ...ans =  0 + 0i
  ans =0 + Infi
  ans =0 - Infi
  ans =0 + NaNi
  ans = Inf +   0i
  ans = Inf + Infi
  ans = Inf - Infi
  ans = Inf + NaNi
  ans = -Inf +   0i
  ans = -Inf + Infi
  ans = -Inf - Infi
  ans = -Inf + NaNi
  ans = NaN +   0i
  ans = NaN + Infi
  ans = NaN - Infi
  ans = NaN + NaNi
   PASS1/1   

Is there another way to test this without printing the output to the
sreen?  Maybe use fdisp to put the output in a file and then compare
the contents of the file to some expected value?

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

2009-06-15 Thread John W. Eaton 
On 15-Jun-2009, Rafael Laboissiere wrote:

| Attached below is a patch for pr-output.cc that makes Octave work as
| expected for 'complex(NaN,0)' on mips (and amd64 as well, FWIW).  The
| package is being built right now on mips and on amd64 and, if everything
| goes well on both arches, I will upload to unstable a new version of the
| package, octave3.2_3.2.0-2, containing the patch.
| 
| I am rushing with this because everything else is being held by this bug,
| like the upload of the new octave-forge packages.
| 
| -- 
| Rafael
| 
| --
| --- a/pr-output.cc2009-06-15 08:48:48.0 +0200
| +++ b/pr-output.cc2009-06-15 11:28:58.0 +0200
| @@ -852,10 +852,12 @@
|double i_abs = ip  0.0 ? -ip : ip;
|  
|int r_x = r_abs == 0.0
| -? 0 : static_castint (floor (log10 (r_abs) + 1.0));
| +? 0 : ((xisinf (rp) || xisnan (rp))
| +? INT_MIN : static_castint (floor (log10 (r_abs) + 1.0)));
|  
|int i_x = i_abs == 0.0
| -? 0 : static_castint (floor (log10 (i_abs) + 1.0));
| +? 0 : ((xisinf (ip) || xisnan (ip))
| +? INT_MIN : static_castint (floor (log10 (i_abs) + 1.0)));
|  
|int x_max, x_min;

To be consistent with what is done int set_format (double, ...), I
think this should be

diff --git a/src/pr-output.cc b/src/pr-output.cc
--- a/src/pr-output.cc
+++ b/src/pr-output.cc
@@ -851,10 +851,10 @@
   double r_abs = rp  0.0 ? -rp : rp;
   double i_abs = ip  0.0 ? -ip : ip;
 
-  int r_x = r_abs == 0.0
+  int r_x = (xisinf (rp) || xisnan (rp) || xr_abs == 0.0)
 ? 0 : static_castint (floor (log10 (r_abs) + 1.0));
 
-  int i_x = i_abs == 0.0
+  int i_x = (xisinf (ip) || xisnan (ip) || i_abs == 0.0)
 ? 0 : static_castint (floor (log10 (i_abs) + 1.0));
 
   int x_max, x_min;


Does that work for you?  Similar changes may be needed in other
functions in case all the elements of a matrix are NaN, for example.

jwe




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

2009-06-15 Thread John W. Eaton 
On 15-Jun-2009, Rafael Laboissiere wrote:

| Anyway, it is funny to see how long this bug lived in the code and was
| just awakened by the crappy mips/mipsel architecture...

Also strange that it didn't show up until now, even on mips.  Maybe a
compiler change?

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

2009-06-12 Thread John W. Eaton 
On 11-Jun-2009, Rafael Laboissiere wrote:

| * John W. Eaton j...@octave.org [2009-06-11 15:42]:
| 
|  Did you compile the simpler program with the same options used to
|  build Octave?
| 
| Probably not.
| 
|  Can you run Octave under gdb and find where it hangs, either by
|  running
|  
|log2 (complex (0, inf))
|  
|  and interrupting it when the hang happens and getting a stack trace,
|  or by stepping through the log2 function (and the functions it calls)
|  to find where it hangs?
| 
| When I run it through ./run-octave -g, the command above does not hang,
| but gives immediately this, even when I set a breakpoint at log2:

How did you set the  breakpoint?  You'll need to set it in Flog2 to
stop in Octave's log2 function (the one that is callable from Octave
scripts).

| octave:1 log2 (complex (0, inf))
| 
| Program received signal SIGBUS, Bus error.
| [Switching to Thread 0x2aad4d80 (LWP 11231)]
| 0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, 
std::char_traitschar  ::_M_insert_floatdouble () from 
/usr/lib/libstdc++.so.6
| 
| Here is the stack:
| 
| (gdb) bt
| #0  0x2e17ae24 in std::num_putchar, std::ostreambuf_iteratorchar, 
std::char_traitschar  ::_M_insert_floatdouble () from 
/usr/lib/libstdc++.so.6
| #1  0x2e17b048 in std::num_putchar, std::ostreambuf_iteratorchar, 
std::char_traitschar  ::do_put () from /usr/lib/libstdc++.so.6
| #2  0x2e18fd44 in std::ostream::_M_insertdouble () from 
/usr/lib/libstdc++.so.6
| #3  0x2b04e65c in operator (o...@0x4328b0, pff=value optimized out)
| at /usr/include/c++/4.3/ostream:214
| #4  0x2b054160 in pr_any_float (fmt=0x2bac0d40, o...@0x4328b0, 
d=2.2661800709135971, fw=0)
| at pr-output.cc:1394
| #5  0x2b055ca4 in pr_complex (o...@0x4328b0, c=value optimized out, 
| r_fw=value optimized out, i_fw=0, scale=value optimized out) at 
pr-output.cc:1412
| #6  0x2b057a98 in octave_print_internal (o...@0x4328b0, c...@0x455cc8) at 
pr-output.cc:1958

Can you move to this frame and examine the value of C?

So there is some problem printing the value?  Maybe log2 is returning
some invalid value.

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

2009-06-11 Thread John W. Eaton 
On 11-Jun-2009, Rafael Laboissiere wrote:

| * Rafael Laboissiere raf...@debian.org [2009-06-11 16:07]:
| 
|  * Rafael Laboissiere raf...@debian.org [2009-06-11 01:08]:
|  
|   * Peter De Schrijver p...@debian.org [2009-06-10 19:40]:
|   
|Package: octave3.2
|Version: 3.2.0-1
|Severity: serious
|
|There was an error while trying to autobuild your package:
|
| Automatic build of octave3.2_3.2.0-1 on mayr by sbuild/mips 99.999
| Build started at 20090607-1015
|   
|   Thanks, we are already aware of it.  It also heppens on mipsel.
|   
|   I am currently investigating the problem using mahler.debian.org.
|  
|  I got the culprit.  The test of data.cc never returns because the code below
|  makes Octave 3.2.0 on mips (at least on mahler.debian.org) hangs forever:
|  
|  log2(complex(0,Inf))
| 
| FWIW, the following works:
| 
| octave:1 complex(0,Inf)
| ans = 0 + Infi

The log2 function is defined in src/data.cc.  The relevant part is

  if (args.length () == 1)
{
  if (nargout  2)
retval(0) = args(0).log2 ();

which ultimately dispatches to

  Complex
  xlog2 (const Complex x)
  {
  #if defined (M_LN2)
static double ln2 = M_LN2;
  #else
static double ln2 = log (2);
  #endif

return std::log (x) / ln2;
  }

So first, can you determine precisely where Octave is actually
hannging?  Does the following program work, or does it also hang in
the same way?

  #include cmath
  #include complex
  #include iostream

  typedef std::complexdouble Complex;

  Complex
  xlog2 (const Complex x)
  {
  #if defined (M_LN2)
static double ln2 = M_LN2;
  #else
static double ln2 = log (2);
  #endif

return std::log (x) / ln2;
  }

  int
  main (void)
  {
std::complexdouble inf_i (0.0, 1.0/0.0);
std::cerr  inf_i  std::endl;
std::complexdouble result = xlog2 (inf_i);
std::cerr  result  std::endl;
return 0;
  }

I expect this program to print:

  (0,inf)
  (inf,2.26618)

but if it hangs, then I think the problem is in the C++ or C library
functions, not Octave.

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#532656: [Pkg-octave-devel] Bug#532656: Bug#532656: Bug#532656: Bug#532656: Bug#532656: octave3.2_3.2.0-1(mips/unstable): FTBFS on mips. Segfault in regression test.

2009-06-11 Thread John W. Eaton 
On 11-Jun-2009, Rafael Laboissiere wrote:

| * John W. Eaton j...@bevo.che.wisc.edu [2009-06-11 11:27]:
| 
|  So first, can you determine precisely where Octave is actually
|  hannging?  Does the following program work, or does it also hang in
|  the same way?
|  
|#include cmath
|#include complex
|#include iostream
|  
|typedef std::complexdouble Complex;
|  
|Complex
|xlog2 (const Complex x)
|{
|#if defined (M_LN2)
|  static double ln2 = M_LN2;
|#else
|  static double ln2 = log (2);
|#endif
|  
|  return std::log (x) / ln2;
|}
|  
|int
|main (void)
|{
|  std::complexdouble inf_i (0.0, 1.0/0.0);
|  std::cerr  inf_i  std::endl;
|  std::complexdouble result = xlog2 (inf_i);
|  std::cerr  result  std::endl;
|  return 0;
|}
|  
|  I expect this program to print:
|  
|(0,inf)
|(inf,2.26618)
|  
|  but if it hangs, then I think the problem is in the C++ or C library
|  functions, not Octave.
| 
| No, it does not hang, but produces the following:
| 
| (0,inf)
| (nan,nan)
| 
| On my Debian sid chroot on amd64, it produces:
| 
| (0,inf)
| (inf,nan)

Did you compile the simpler program with the same options used to
build Octave?

Can you run Octave under gdb and find where it hangs, either by
running

  log2 (complex (0, inf))

and interrupting it when the hang happens and getting a stack trace,
or by stepping through the log2 function (and the functions it calls)
to find where it hangs?

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#525113: [Pkg-octave-devel] Bug#525113: Bug#525113: Bug#525113: Inconsistant complex matrix multiplication

2009-04-22 Thread John W. Eaton 
On 23-Apr-2009, Rafael Laboissiere wrote:

| * Thomas Weber thomas.weber.m...@gmail.com [2009-04-22 23:04]:
| 
|  On Wed, Apr 22, 2009 at 12:01:19PM +0200, Laurent Mazet wrote:
|   Package: octave3.0
|   Version: 1:3.0.1-7
|   Arch: i386
|   Severity: grave
|  
|   Hi,
|  
|   I've just realized that I can multiply a real 2x2 matrix by a complex 
vector.
|  
|  Uh, yes. Why shouldn't this work? Or in other words, how do you
|  distinguish the real matrix from a complex matrix with its complex
|  coefficients being zero
|  
|  [ 1, 2; 3,4] is the same as [1+0i, 2+0i; 3+0i, 4+0i], isn't it?
| 
| I think Laurent meant I've just realized that I CANNOT multiply [...]

And the multiplication appeared to work, but gave the wrong answer.  I
don't remember this bug, but I can't duplicate it now on my system.
If it wasn't a bug that was fixed in Octave, then I'd guess it was a
BLAS bug?  Octave just uses BLAS to perform these mutliplications.

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#523042: [Pkg-octave-devel] Bug#523042: octave3.0: loading a datafile skips every second line

2009-04-08 Thread John W. Eaton 
On  9-Apr-2009, Drew Parsons wrote:

| Hi Rafael, thanks for the forthcoming fix to the problem.
| 
| About the severity, I appreciate you need to get the new version across
| to testing but I don't think I could justify it with this bug.

I agree that we should limit the spread of 3.0.4 as much as possible.
3.0.5 is now available (there is just one patch applied to 3.0.4 to
fix this bug) so it would seem to me that it is better to generate the
3.0.5 package and upload that instead, and do whatever we can to keep
3.0.4 from being used by anyone.

Thanks,

jwe



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#418503: [Pkg-octave-devel] Bug#418503: octave2.9: Must not enter testing

2007-04-10 Thread John W. Eaton 
On 10-Apr-2007, Thomas Weber wrote:

| Package: octave2.9
| Version: 2.9.10-4
| Severity: grave
| Justification: renders package unusable
| 
| Octave 2.9.10 doesn't play well with the current octave2.9-forge packages in
| Debian, so it shouldn't enter testing in the current state. 

I think this is unfortunate since Octave is useful on its own without
Octave Forge and I think 2.9.10 is much better than 2.9.9.  Also, for
those who must have some or all of Octave Forge, there is now a way to
install it using Octave's pkg function.

jwe


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#356194: [Pkg-octave-devel] Bug#356194: octave2.9: Octave-2.9.4 - random crashes

2006-03-10 Thread John W. Eaton 
On 10-Mar-2006, LUK ShunTim wrote:

| I'm experiencing random crashes of octave 2.9.4 on a debian/sid box. I
| apt-get the source and rebuild with debug on and here is the backtrace.
| 
| backtrace
| 
| $ gdb octave
| GNU gdb 6.4-debian
| Copyright 2005 Free Software Foundation, Inc.
| GDB is free software, covered by the GNU General Public License, and you are
| welcome to change it and/or distribute copies of it under certain
| conditions.
| Type show copying to see the conditions.
| There is absolutely no warranty for GDB.  Type show warranty for details.
| This GDB was configured as i486-linux-gnu...(no debugging symbols found)
| Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1.
| 
| (gdb) run
| Starting program: /usr/bin/octave
| (no debugging symbols found)
| (no debugging symbols found)
| (no debugging symbols found)
| (no debugging symbols found)
| (no debugging symbols found)
| (no debugging symbols found)
| (no debugging symbols found)
| (no debugging symbols found)
| (no debugging symbols found)

If you rebuilt with debugging enabled, then what happened to the
symbols?  Were they stripped at some point?

| #1  0xb7b3b38d in octave_builtin::do_multi_index_op ()
|from /usr/lib/octave-2.9.4/liboctinterp.so

With debugging symbols, I'd expect more info about the arguments.

In any case, if it is truly a random crash that you can't reproduce,
then the first thing I would check would be your system's memory.

OTOH, if it is always crashing in the same place, then can you try to
find some recipe for the failure?

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

2005-09-15 Thread John W. Eaton 
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

2005-09-14 Thread John W. Eaton 
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

2005-09-09 Thread John W. Eaton 
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

2005-09-09 Thread John W. Eaton 
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

2005-09-09 Thread John W. Eaton 
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

2005-09-09 Thread John W. Eaton 
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]