[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: hurd_20050119-3_hurd-i386.changes ACCEPTED



On Sat, Apr 16, 2005 at 11:32:11PM +0200, Michael Banck wrote:
> On Sat, Apr 16, 2005 at 07:18:02AM -0400, Debian Installer wrote:
> > Accepted:
> > hurd-dbg_20050119-3_hurd-i386.deb
> >   to pool/main/h/hurd/hurd-dbg_20050119-3_hurd-i386.deb

Permissions are not set up correctly:
#v+
-rw-r--r--  1 root root  122723 Apr 16 02:28 /lib/debug/bin/ps
-rw-r--r--  1 root root  473212 Apr 16 02:27 /lib/debug/hurd/ext2fs
-rw-r--r--  1 root root 4919809 Feb  5 21:45 /lib/debug/libhurduser-2.3.2.so
-rw-r--r--  1 root root   51930 Apr 16 02:28 /lib/debug/sbin/halt
-rw-r--r--  1 root root   52307 Apr 16 02:26 /lib/debug/usr/lib/hurd/console/generic_speaker.so.0.3
#v-

(Is it correct to have the executabled installed in /lib/debug/?)

The shipped executables are not executable for me:
#v+
GNU gdb 6.3-debian
[...]
This GDB was configured as "i386-gnu"...
(gdb) r
Starting program: /lib/debug/hurd/ext2fs
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.

Program received signal EXC_BAD_ACCESS, Could not access memory.
_start () at ../sysdeps/i386/elf/start.S:47
47      ../sysdeps/i386/elf/start.S: No such file or directory.
        in ../sysdeps/i386/elf/start.S
Current language:  auto; currently asm
#v-

#v+
/lib/debug/hurd/ext2fs:        ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
/lib/debug/hurd/ext2fs.static: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped
/hurd/ext2fs:                  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Hurd 0.0.0, dynamically linked (uses shared libs), stripped
/hurd/ext2fs.static:           ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Hurd 0.0.0, statically linked, stripped
#v-

> I'm quite short of time right now, so I'd appreciate if somebody could
> test hurd-dbg and see whether it just works[tm] with gdb for getting
> backtraces of calls to hurd library routines.

Using 'LD_LIBRARY_PATH=/lib/debug gdb ...', that's working fine so far.


Regards,
 Thomas



Reply to: