Re: Help configuring an HIL mouse on an HP 715.
On Saturday 17 May 2003 01:22 am, Jaime Ash wrote: I have a 715 with the same configuration (HIL Adapter) too. Yes, it should work and both are used as HIL devices. Anyway, please send me your dmesg output and I can take a look. What version of the kernel are you using in that machine? I'm running the 2.4.20 kernel from parisc-CVS-head. Helge
gcc fails to build using binutils-2.14.90.0.1
binutils-2.13.90.0.18 works ok. See http://buildd.debian.org/fetch.php?pkg=gcc-3.3ver=1%3A3.3ds9-2arch=hppastamp=1053264270file=logas=raw: ./xgcc -B./ -B/usr/hppa-linux/bin/ -isystem /usr/hppa-linux/include -isystem /usr/hppa-linux/sys-include -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -DELF=1 -DLINUX=1 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -DL_mulI -xassembler-with-cpp -c ../../src/gcc/config/pa/milli64.S -o libgcc/./_mulI.o ../../src/gcc/config/pa/milli64.S: Assembler messages: ../../src/gcc/config/pa/milli64.S:1779: Error: Undefined .EXPORT/.IMPORT argument (ignored): ../../src/gcc/config/pa/milli64.S:1779: Error: Undefined .EXPORT/.IMPORT argument (ignored): millicode make[5]: *** [libgcc/./_mulI.o] Error 1
Re: [parisc-linux] gcc fails to build using binutils-2.14.90.0.1
binutils-2.13.90.0.18 works ok. See http://buildd.debian.org/fetch.php?pkg=gcc-3.3ver=1%3A3.3ds9-2arch=hppastamp=1053264270file=logas=raw: ./xgcc -B./ -B/usr/hppa-linux/bin/ -isystem /usr/hppa-linux/include -isystem /usr/hppa-linux/sys-include -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -DELF=1 -DLINUX=1 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/config -I../../src/gcc/../include -DL_mulI -xassembler-with-cpp -c ../../src/gcc/config/pa/milli64.S -o libgcc/./_mulI.o ../../src/gcc/config/pa/milli64.S: Assembler messages: ../../src/gcc/config/pa/milli64.S:1779: Error: Undefined .EXPORT/.IMPORT argument (ignored): ../../src/gcc/config/pa/milli64.S:1779: Error: Undefined .EXPORT/.IMPORT argument (ignored): millicode make[5]: *** [libgcc/./_mulI.o] Error 1 Did you part this to the binutils list? A change has mucked up the assembler's processing of .export. Alan Modra would probably know what's happened. I've also noted that there are some new fails in the visibility tests in a recent cvs version of binutils. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: Octave 2.1 is segfaulting on hppa
In reference to a message from Dirk Eddelbuettel, dated May 13: Anew octave2.1_2.1.48 with debugging symbols is in ~edd on paer, could someone please install it? I can't convince octave to ignore its rpath so its looking at the non-debug version in /usr/lib/octave-2.1.48. Or else if there is a gdb trick, I'd take that too. LD_LIBRARY_PATH=... gdb fails as well. that's because octave uses rpath... sigh anyway, i suspect this is one of the many c++ bugs that has been fixed in g++-3.3. i tried to build octave with g++3.3 but it dies with some other error. can you try to get your package to build with g++-3.3 (any arch) and then we can see if that works better on hppa? with 3.2, it dies in #0 0x400c4098 in symbols_of_data() () #1 0x4031f3e0 in install_builtin_variables () at builtins.cc:849 #2 0x4031f730 in install_builtins() () at builtins.cc:961 #3 0x4030fd5c in octave_main (argc=114294784, argv=0x0, embedded=0) at octave.cc:408 #4 0x41738bd0 in __libc_start_main () from /lib/libc.so.6 #5 0x000105cc in _start () in symbols_of_data, the definition of some of the floating point constants is causing it to segfault. i'm not very sure why yet. HTH, randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
Re: Octave 2.1 is segfaulting on hppa
On Sun, May 18, 2003 at 02:03:28PM -0700, Randolph Chung wrote:
In reference to a message from Dirk Eddelbuettel, dated May 13:
Anew octave2.1_2.1.48 with debugging symbols is in ~edd on paer, could
someone please install it? I can't convince octave to ignore its rpath
so its looking at the non-debug version in /usr/lib/octave-2.1.48. Or
else if there is a gdb trick, I'd take that too. LD_LIBRARY_PATH=... gdb
fails as well.
that's because octave uses rpath... sigh
I know. John Eaton and I feel that rpath is justified as only Octave will
call the .so libraries built by/for Octave, and there is really no reason to
involve ldd. Use of rpath is a configure-time option, but I think it is
reasoable to use it on Debian.
anyway, i suspect this is one of the many c++ bugs that has been fixed
in g++-3.3. i tried to build octave with g++3.3 but it dies with some
other error. can you try to get your package to build with g++-3.3 (any
arch) and then we can see if that works better on hppa?
with 3.2, it dies in
#0 0x400c4098 in symbols_of_data() ()
#1 0x4031f3e0 in install_builtin_variables () at builtins.cc:849
#2 0x4031f730 in install_builtins() () at builtins.cc:961
#3 0x4030fd5c in octave_main (argc=114294784, argv=0x0, embedded=0)
at octave.cc:408
#4 0x41738bd0 in __libc_start_main () from /lib/libc.so.6
#5 0x000105cc in _start ()
in symbols_of_data, the definition of some of the floating point
constants is causing it to segfault. i'm not very sure why yet.
I got this (using the debug-symbol version finally installed by Martin)
which points to the STL, as least as I see it:
[EMAIL PROTECTED]:~$ dchroot sid
Executing shell in chroot: /org/paer.debian.org/chroot/sid
[EMAIL PROTECTED]:~$ gdb /usr/bin/octave2.1
GNU gdb 5.3-debian
Copyright 2002 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 hppa-linux...
(gdb) r
Starting program: /usr/bin/octave2.1
Program received signal SIGSEGV, Segmentation fault.
0x400c4698 in symbols_of_data() () at
/usr/include/c++/3.2/bits/stl_alloc.h:664
664 allocator() throw() {}
Current language: auto; currently c++
(gdb) s
p0x417ec850 in write () from /lib/libc.so.6
(gdb) l
659
660 templatetypename _Tp1
661 struct rebind
662 { typedef allocator_Tp1 other; };
663
664 allocator() throw() {}
665 allocator(const allocator) throw() {}
666 templatetypename _Tp1
667 allocator(const allocator_Tp1) throw() {}
668 ~allocator() throw() {}
Dirk
--
Don't drink and derive. Alcohol and analysis don't mix.
Re: Bug#193804: octave: Octave segfaults at start
severity 193804 normal
thanks
On Mon, May 19, 2003 at 01:45:43AM +0300, Harri Haataja wrote:
Package: octave
Version: 2.1.48-2
Severity: grave
Justification: renders package unusable
I decided to try octave on a hppa box (the only debian in the house
so far, I'm afraid). It segfaults at the beginning.
The bug is known, and currently reassigned to binutils. I may need to
reassign it to the g++ libs:
[EMAIL PROTECTED]:~$ gdb /usr/bin/octave2.1
GNU gdb 5.3-debian
Copyright 2002 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 hppa-linux...
(gdb) r
Starting program: /usr/bin/octave2.1
Program received signal SIGSEGV, Segmentation fault.
0x400c4698 in symbols_of_data() () at
/usr/include/c++/3.2/bits/stl_alloc.h:664
664 allocator() throw() {}
Current language: auto; currently c++
(gdb) s
p0x417ec850 in write () from /lib/libc.so.6
(gdb) l
659
660 templatetypename _Tp1
661 struct rebind
662 { typedef allocator_Tp1 other; };
663
664 allocator() throw() {}
665 allocator(const allocator) throw() {}
666 templatetypename _Tp1
667 allocator(const allocator_Tp1) throw() {}
668 ~allocator() throw() {}
(gdb) q
This is AFAICT not an octave bug as octave works fine on half a dozen other
platforms, 32 bit and 64 bit.
Dirk
Just now vim has also started to do that, so I'm not sure if there's
something else wrong in that box but it could be coincidence.
I am running unstable anyway :)
[EMAIL PROTECTED] nice gdb octave
GNU gdb 5.3-debian
Copyright 2002 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 hppa-linux...(no debugging symbols found)...
(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)...(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)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x400c4608 in symbols_of_data() () from /usr/lib/octave-2.1.48/liboctinterp.so
#0 0x400c4608 in symbols_of_data() ()
from /usr/lib/octave-2.1.48/liboctinterp.so
#1 0x403207c4 in octave_main () from /usr/lib/octave-2.1.48/liboctinterp.so
#2 0x40320b14 in install_builtins() ()
from /usr/lib/octave-2.1.48/liboctinterp.so
#3 0x40311140 in octave_main () from /usr/lib/octave-2.1.48/liboctinterp.so
#4 0x41735bd0 in __libc_start_main () from /lib/libc.so.6
#5 0x000105cc in _start ()
-- System Information:
Debian Release: testing/unstable
Architecture: hppa
Kernel: Linux phanuel 2.4.19-32 #1 Fri Nov 22 23:27:00 MST 2002 parisc
Locale: LANG=C, LC_CTYPE=C
Versions of packages octave depends on:
ii octave2.1 2.1.48-2 The GNU Octave language for
numeri
-- no debconf information
--
Don't drink and derive. Alcohol and analysis don't mix.
