Your message dated Mon, 04 May 2020 21:48:37 +
with message-id
and subject line Bug#953654: fixed in glibc 2.30-5
has caused the Debian Bug report #953654,
regarding libc6-dbg should be renamed (or at least Provide:) libc6-dbgsym
to be marked as done.
This means that you claim
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc
Commits:
af69bb20 by Aurelien Jarno at 2020-05-04T00:39:06+02:00
debian/control.in/libc: add a Provides: libc6-dbgsym to the libc6-dbg package.
Closes: #953654.
- - - - -
3 changed files:
- debian/changelog
- debian
On Fri 2020-03-13 17:22:30 +0100, Aurelien Jarno wrote:
> The reason is that all *-dbgsym packages need to go the debug archive,
> not the main archive.
Thanks, this is the piece of information that i was missing. Where is
it documented that all *-dbgsym packages need to go to the debug
archive?
r only get the confirmation that the package
> > shall not be renamed to libc6-dbgsym.
>
> Thanks for the reportback. Is there some policy about what kinds of
> package may be named *-dbgsym generally that renaming libc6-dbg would
> violate? comparing the file lists and (lack of) maintscripts
e
> shall not be renamed to libc6-dbgsym.
Thanks for the reportback. Is there some policy about what kinds of
package may be named *-dbgsym generally that renaming libc6-dbg would
violate? comparing the file lists and (lack of) maintscripts between
libc6-dbg and (as a random example) libglib
On 2020-03-11 20:31, Daniel Kahn Gillmor wrote:
> On Wed 2020-03-11 21:42:43 +0100, Aurelien Jarno wrote:
> >> Every other debug symbol package in debian is named $foo-dbgsym. libc6
> >> seems to be the exception.
> >
> > Well libc6-dbg is not a standard dbgsym
On Wed 2020-03-11 21:42:43 +0100, Aurelien Jarno wrote:
>> Every other debug symbol package in debian is named $foo-dbgsym. libc6
>> seems to be the exception.
>
> Well libc6-dbg is not a standard dbgsym package:
> - It is a dependency for other packages
> - It is a bu
On 2020-03-11 15:33, Daniel Kahn Gillmor wrote:
> Package: libc6-dbg
> Version: 2.29-10
>
> Every other debug symbol package in debian is named $foo-dbgsym. libc6
> seems to be the exception.
Well libc6-dbg is not a standard dbgsym package:
- It is a dependency for
Package: libc6-dbg
Version: 2.29-10
Every other debug symbol package in debian is named $foo-dbgsym. libc6
seems to be the exception.
Can we please rename this package (along with a transitional package to
help folks upgrade from libc6-dbg) and set up an appropriate Provides:
at least
Your message dated Tue, 12 Dec 2017 21:19:16 +
with message-id <e1eorxm-0006qk...@fasolo.debian.org>
and subject line Bug#520680: fixed in glibc 2.25-4
has caused the Debian Bug report #520680,
regarding libc6-dbg: Debug symbols not broken up by runtime package
to be marked a
ules.d/debhelper.mk: revert the logic to build
libc6-dbg. Only fill it with files from the main libc and optimized flavours.
Other debugging symbols are available in the dbgsym packages. Closes: #520680.
---
debian/changelog| 4
debian/rules| 19 ---
could not be found.
I am using a memory usage checker, valgrind, and
hit into a problem of symbols of ld.so not found.
Exactly speaking it is not ld.so, but /lib64/ld-2.17.so,
and eventually /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
Although I installed libc6-dbg package, the
debug symbols for ld
Hi,
I am using libc6-dbg libraries to debug into library source code. The
library path is /usr/lib/debug.
glibc-source code path is /usr/src/debug/glibc-2.7. I am using gdb to
debug a small application and put a break point on pthread_create function.
I tried to step into pthread_create
Package: libc6-dbg
Version: 2.11.2-2
Severity: important
Hi,
I'd like to point out that there is zero documentation telling you what
libc6-dbg
is supposed to be useful for. The only thing that it installs in /usr/share/doc
are the changelogs that are bytewise identical to those in libc6
Your message dated Wed, 01 Sep 2010 17:51:02 +0200
with message-id 4c7e7666.1090...@aurel32.net
and subject line Re: Bug#595161: libc6-dbg: zero documentation
has caused the Debian Bug report #595161,
regarding libc6-dbg: zero documentation
to be marked as done.
This means that you claim
severity 595161 wishlist
retitle 595161 dh_strip should add a README.Debian file explaining how to use
the -dbg package
thanks
On Wed, Sep 01, 2010 at 05:51:02PM +0200, Aurelien Jarno wrote:
Thomas Themel a écrit :
Package: libc6-dbg
Version: 2.11.2-2
Severity: important
Hi,
I'd
Processing commands for cont...@bugs.debian.org:
severity 595161 wishlist
Bug #595161 [libc6-dbg] libc6-dbg: zero documentation
Severity set to 'wishlist' from 'important'
retitle 595161 dh_strip should add a README.Debian file explaining how to use
the -dbg package
Bug #595161 [libc6-dbg
Aurelien Jarno writes:
Thomas Themel a écrit :
Package: libc6-dbg
Version: 2.11.2-2
Severity: important
Hi,
I'd like to point out that there is zero documentation telling you what l=
ibc6-dbg
is supposed to be useful for. The only thing that it installs in /usr/sha
Processing commands for cont...@bugs.debian.org:
severity 520680 wishlist
Bug#520680: libc6-dbg: Debug symbols not broken up by runtime package
Severity set to `wishlist' from `normal'
tag 520680 + wontfix
Bug#520680: libc6-dbg: Debug symbols not broken up by runtime package
There were no tags
severity 520680 wishlist
tag 520680 + wontfix
thanks
On Sat, Mar 21, 2009 at 05:33:44PM -0400, Samuel Bronson wrote:
Package: libc6-dbg
Version: 2.7-15
Severity: normal
It looks like the symbols for all three of libc6, libc6-amd64, and
libc6-i686 are included in this package. Combined
On Sat, Apr 25, 2009 at 4:12 AM, Aurelien Jarno aurel...@aurel32.net wrote:
Yes, debugging packages in Debian are all using the same layout: one per
source package. A lot of them are a lot bigger than libc6-dbg.
Wouldn't it be better to split the symbols for libc6-foo into a
seperate -foo
On Sat, Apr 25, 2009 at 11:10:02AM -0400, Samuel Bronson wrote:
On Sat, Apr 25, 2009 at 4:12 AM, Aurelien Jarno aurel...@aurel32.net wrote:
Yes, debugging packages in Debian are all using the same layout: one per
source package. A lot of them are a lot bigger than libc6-dbg.
Wouldn't
Package: libc6-dbg
Version: 2.7-15
Severity: normal
It looks like the symbols for all three of libc6, libc6-amd64, and
libc6-i686 are included in this package. Combined with the fixing of
#516516, this results (well, will result, for me) in a quite large
package, parts of which may be quite
in Perl_runops_standard ()
#12 0x080ac6a0 in perl_run ()
#13 0x08063ddd in main ()
Thanks for the backtrace. Unfortunately there is not enough debugging
symbols for the libc6 part, as it is partly stripped.
It should be possible to get a backtrace with the current libc6-dbg,
however the easiest way to get more
in Perl_runops_standard ()
#12 0x080ac6a0 in perl_run ()
#13 0x08063ddd in main ()
Thanks for the backtrace. Unfortunately there is not enough debugging
symbols for the libc6 part, as it is partly stripped.
It should be possible to get a backtrace with the current libc6-dbg,
however the easiest way
New Thread 0xf649ab90 (LWP 5637)]
[Graphics
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf7d3c6b0 (LWP 5631)]
0xf6ed1e70 in ?? ()
(gdb) bt
#0 0xf6ed1e70 in ?? ()
#1 0xf6fe21a2 in IA__g_slice_alloc (mem_size=36) at
/tmp/buildd/glib2.0-2.18.4/glib/gslice.c:423
#2
Your message dated Wed, 18 Feb 2009 06:02:40 +
with message-id e1lzfw4-00066k...@ries.debian.org
and subject line Bug#513882: fixed in glibc 2.9-1
has caused the Debian Bug report #513882,
regarding libc6-dbg: no debugging symbols for nscd
to be marked as done.
This means that you claim
Package: libc6-dbg
Version: 2.7-18
Severity: normal
Hello,
Because of a problem with nscd (see bug #513635), I was willing to get a
backtrace of it. So I installed libc6-dbg, and tried to attach gdb to a
running nscd.
Unfortunatenly, symbols seem to be missing from
/usr/lib/debug/usr/sbin
On Fri, Jan 23, 2009 at 10:27:47PM +0100, Jörg Sommer wrote:
Hi,
is it correct that the package ships files in /usr/lib/debug?
% dpkg -L libc6-dbg S '\_/usr/lib/debug/_!d; \_/debug/.*/_d'
/usr/lib/debug/lib64
/usr/lib/debug/ld-2.7.so
/usr/lib/debug/libanl-2.7.so
/usr/lib/debug
Hi Aurelien,
Aurelien Jarno schrieb am Sat 24. Jan, 09:09 (+0100):
On Fri, Jan 23, 2009 at 10:27:47PM +0100, Jörg Sommer wrote:
is it correct that the package ships files in /usr/lib/debug?
% dpkg -L libc6-dbg S '\_/usr/lib/debug/_!d; \_/debug/.*/_d'
/usr/lib/debug/lib64
/usr/lib
Hi,
is it correct that the package ships files in /usr/lib/debug?
% dpkg -L libc6-dbg S '\_/usr/lib/debug/_!d; \_/debug/.*/_d'
/usr/lib/debug/lib64
/usr/lib/debug/ld-2.7.so
/usr/lib/debug/libanl-2.7.so
/usr/lib/debug/libBrokenLocale-2.7.so
/usr/lib/debug/libc-2.7.so
I ask, because gdb tells me
Package: libc6-dbg
Version: 2.7-13
Severity: normal
In the following code the return value of gethostbyname_r() is 0,
but *h_errno is 3, what violates documentation.
---
struct hostent host;
struct hostent *hostp;
int herr;
char ghbn_buf[1024*1024+1];
int nh;
hostp=host;
nh=gethostbyname_r
On Thu, 2008-07-24 at 17:45 -0400, Daniel Jacobowitz wrote:
I believe symbols for libc are deliberately not shipped, just enough
to backtrace. So GDB is likely behaving as expected.
In that case, this bug (gdb shows no debug info for libc6/libc6-i386
with libc6-dbg installed) is wontfix. I
.6.
Same happens when I make a symlink to libc-2.7.so. Reinstalling
libc6-i686 and libc6-dbg doesn't seem to help either.
Sorry, there's no concrete information in this bug report. What
exactly happens that you believe is a bug?
I believe symbols for libc are deliberately not shipped, just
Aurelien Jarno a écrit :
Paul Wise a écrit :
Package: libc6-dbg
Version: 2.7-12
Severity: wishlist
libc6-dbg doesn't contain debug symbols for /lib/i686/cmov/libc.so.6 and
It does, see /usr/lib/debug/lib/i686/cmov/libc-2.7.so
other stuff from libc6-i686. It does contain some
/usr/lib/debug/lib/libc-2.7.so to /usr/lib/debug/lib/libc.so.6.
Same happens when I make a symlink to libc-2.7.so. Reinstalling
libc6-i686 and libc6-dbg doesn't seem to help either.
I guess I should reassign this to gdb?
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description
the libc.so.6 symbols when I purge libc6-i686
and copy /usr/lib/debug/lib/libc-2.7.so to /usr/lib/debug/lib/libc.so.6.
Same happens when I make a symlink to libc-2.7.so. Reinstalling
libc6-i686 and libc6-dbg doesn't seem to help either.
I guess I should reassign this to gdb?
I think that's
Processing commands for [EMAIL PROTECTED]:
reassign 489252 gdb
Bug#489252: libc6-dbg: doesn't contain debug symbols for
/lib/i686/cmov/libc.so.6
Bug reassigned from package `libc6-dbg' to `gdb'.
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking
Paul Wise a écrit :
Package: libc6-dbg
Version: 2.7-12
Severity: wishlist
libc6-dbg doesn't contain debug symbols for /lib/i686/cmov/libc.so.6 and
It does, see /usr/lib/debug/lib/i686/cmov/libc-2.7.so
other stuff from libc6-i686. It does contain some of the debug symbols
though
Package: libc6-dbg
Version: 2.7-12
Severity: wishlist
libc6-dbg doesn't contain debug symbols for /lib/i686/cmov/libc.so.6 and
other stuff from libc6-i686. It does contain some of the debug symbols
though, but not all of them and unfortunately not the i686 libc ones.
$ dpkg -L libc6-dbg | grep
administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: libc6-dbg
Version: 2.3.6.ds1-13etch2
The dynamic loader shipped in libc6-dbg doesn't have the executable bit set.
This means you can't specify it to ld as the dynamic loader, which in turn
means that you can't get source
Package: libc6-dbg
Version: 2.3.6.ds1-13etch2
The dynamic loader shipped in libc6-dbg doesn't have the executable bit set.
This means you can't specify it to ld as the dynamic loader, which in turn
means that you can't get source line information in gdb for crashes inside
the dynamic loader
On Thu, Aug 30, 2007 at 12:45:54AM +, Junichi Uekawa wrote:
Hi,
I'm still seeing that oprofile cannot use libc6-dbg. Anyone seeing the same
problem?
it's an issue with oprofile that needs to be rebuilt and have a
versionned dependency on recent binutils. There is an open RC bug about
Hi,
I'm still seeing that oprofile cannot use libc6-dbg. Anyone seeing the same
problem?
oprofile (opreport -l) gives the following warnings:
warning: /lib/libc-2.6.1.so is not in a usable binary format.
warning: /lib/libdl-2.6.1.so is not in a usable binary format.
warning: /lib/libm-2.6.1.so
Package: libc6-dbg
Version: 2.3.6.ds1-13
While trying to debug a threaded program using the libc6-dbg package, I
ran into a completely different behavior then when using the normal
libc6. After some searching I discovered that the default threading
library when using the libc6-dbg package
Your message dated Fri, 10 Aug 2007 16:50:41 +0200
with message-id [EMAIL PROTECTED]
and subject line Bug#437122: Linuxthreads instead of NPTL in libc6-dbg package
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt
Package: libc6-dbg
Version: 2.3.6.ds1-13
Severity: minor
The package libc6-dbg provides a useless shlibs file. In case it's
generated by dh_makeshlibs you might just need to add -X/usr/lib/debug
to its call to avoid this.
Cheers,
-- System Information:
Debian Release: 4.0
APT prefers proposed
Your message dated Sun, 22 Apr 2007 23:20:18 +0200
with message-id [EMAIL PROTECTED]
and subject line Bug#319275: libc6-dbg: unusable debug information files in
/usr/lib/debug/lib
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt
administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: libc6-dbg
Version: 2.3.6.ds1-8
Severity: normal
Edited highlights of a conversation on IRC with Daniel Jacobowitz (drow):
Igloo I have the impression that I should be able to use gdb to step
into libc functions if I set
administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: libc6-dbg
Version: 2.3.6.ds1-8
Severity: normal
Edited highlights of a conversation on IRC with Daniel Jacobowitz (drow):
Igloo I have the impression that I should be able to use gdb to step
into libc functions if I
administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: libc6-dbg
Version: 2.3.6.ds1-8
Severity: normal
Edited highlights of a conversation on IRC with Daniel Jacobowitz (drow):
Igloo I have the impression that I should be able to use gdb to step
into libc functions if I
administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: libc6-dbg
Version: 2.3.6.ds1-8
Severity: normal
Edited highlights of a conversation on IRC with Daniel Jacobowitz (drow):
Igloo I have the impression that I should be able to use gdb to step
into libc functions if I
Package: libc6-dbg
Version: 2.3.6.ds1-8
Severity: normal
Edited highlights of a conversation on IRC with Daniel Jacobowitz (drow):
Igloo I have the impression that I should be able to use gdb to step
into libc functions if I set LD_LIBRARY_PATH to /usr/lib/debug, but
it doesn't seem
administrator
(administrator, Debian Bugs database)
---BeginMessage---
Package: libc6-dbg
Version: 2.3.6.ds1-8
Severity: normal
Tags: patch
I've had this sitting on my hard drive for six months but never committed
it, and now I no longer consider myself a glibc committer.
Someone reported
Package: libc6-dbg
Version: 2.3.6.ds1-8
Severity: normal
Tags: patch
I've had this sitting on my hard drive for six months but never committed
it, and now I no longer consider myself a glibc committer.
Someone reported that there were useless sections in the separate debuginfo
files in /usr/lib
Package: libc6-dbg
Version: 2.3.6.ds1-4
opreport seems to be looking at the file (from strace):
open(/lib/tls/i686/cmov/libc-2.3.6.so, O_RDONLY) = 4
stat64(/lib/tls/i686/cmov/libc-2.3.6.so, {st_mode=S_IFREG|0755,
st_size=1241580, ...}) = 0
open(/lib/tls/i686/cmov/libc-2.3.6.so, O_RDONLY
==6517== Conditional jump or move depends on uninitialised value(s)
==6517==at 0x4010E1E: (within /lib/ld-2.3.5.so)
==6517==by 0x419FACF: (within /lib/tls/libc-2.3.5.so)
==6517==by 0x400B056: (within /lib/ld-2.3.5.so)
==6517==by 0x41A048A: _dl_open (in /lib/tls/libc-2.3.5.so)
trace of what was at fault. I got a good list
with all the symbols from inside python and from inside the
libxml2/libxslt libraries.
Unfortunately, I was then stupid and installed libc6-dbg in order to
get more info.
Now I get *no* python or libxml2/libxslt symbols in the stack
traces.
What
python and from inside the
libxml2/libxslt libraries.
Unfortunately, I was then stupid and installed libc6-dbg in order to
get more info.
Now I get *no* python or libxml2/libxslt symbols in the stack
traces.
If I set LD_LIBRARY_PATH to the debug libraries I do get some libc
symbols... but still
Your message dated Fri, 29 Jul 2005 20:57:42 +0900
with message-id [EMAIL PROTECTED]
and subject line Bug#257032: add some doc or README file to
/usr/share/doc/libc6-dbg explaining best way to use this package
has caused the attached Bug report to be marked as done.
This means that you claim
Package: libc6-dbg
Version: 2.3.2.ds1-22
Severity: normal
Because files in /usr/lib/debug/lib lack all debug sections other than
.debug_frame, gdb fails to acquire debug information automatically
(See 15.2 Debugging Information in Separate of gdb.info).
IMHO, the package should have correct
On Thu, Jul 21, 2005 at 06:04:37AM +0900, YAEGASHI Takeshi wrote:
Because files in /usr/lib/debug/lib lack all debug sections other than
.debug_frame, gdb fails to acquire debug information automatically
(See 15.2 Debugging Information in Separate of gdb.info).
IMHO, the package should have
for the package libc6-dbg. I used it for a
little while, and the principal limitation is that we can't debug
inside
the macros. So I would like to know if you planed to do an another
package
with the debugging symbols for the macros, I mean the gcc's options :
- -gdwarf-2 -g3
It's good
At Tue, 3 Aug 2004 13:17:54 -0700,
Jeff Bailey wrote:
On Tue, Aug 03, 2004 at 01:48:34PM -0400, Daniel Jacobowitz wrote:
- -gdwarf-2 -g3
It's good idea for me. I don't know we can use DWARF2 level3 on all
architectures, though.
Daniel, how about adding this option? If it's
On Fri, Jul 23, 2004 at 04:53:54PM +0900, GOTO Masanori wrote:
Hi,
At Mon, 19 Jul 2004 15:32:34 +0200 (CEST),
Fabien Carrion wrote:
I got a little suggestion for the package libc6-dbg. I used it for a
little while, and the principal limitation is that we can't debug inside
the macros
On Tue, Aug 03, 2004 at 01:48:34PM -0400, Daniel Jacobowitz wrote:
- -gdwarf-2 -g3
It's good idea for me. I don't know we can use DWARF2 level3 on all
architectures, though.
Daniel, how about adding this option? If it's easy to add simply this
option, I welcome to use it.
Selon Daniel Jacobowitz [EMAIL PROTECTED]:
On Fri, Jul 23, 2004 at 04:53:54PM +0900, GOTO Masanori wrote:
Hi,
At Mon, 19 Jul 2004 15:32:34 +0200 (CEST),
Fabien Carrion wrote:
I got a little suggestion for the package libc6-dbg. I used it for a
little while, and the principal
Hi,
At Mon, 19 Jul 2004 15:32:34 +0200 (CEST),
Fabien Carrion wrote:
I got a little suggestion for the package libc6-dbg. I used it for a
little while, and the principal limitation is that we can't debug inside
the macros. So I would like to know if you planed to do an another package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I got a little suggestion for the package libc6-dbg. I used it for a
little while, and the principal limitation is that we can't debug inside
the macros. So I would like to know if you planed to do an another package
with the debugging symbols
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I got a little suggestion for the package libc6-dbg. I used it for a
little while, and the principal limitation is that we can't debug inside
the macros. So I would like to know if you planed to do an another package
with the debugging symbols
Package: libc6-dbg
Version: 2.3.2.ds1-13
Severity: wishlist
after installing this package no info is provided on how to use it.
I have seen people tempted to replace libc6 files with libc6-dbg in the
most dartiest way by moving files with mv.
So I suggest adding some doc file to package
At Mon, 28 Jun 2004 15:21:39 +0200,
txemi wrote:
after installing this package no info is provided on how to use it.
I have seen people tempted to replace libc6 files with libc6-dbg in the
most dartiest way by moving files with mv.
So I suggest adding some doc file to package suggesting how
Package: libc6-dbg
Version: 2.3.2.ds1-13
Severity: wishlist
after installing this package no info is provided on how to use it.
I have seen people tempted to replace libc6 files with libc6-dbg in the
most dartiest way by moving files with mv.
So I suggest adding some doc file to package
At Mon, 28 Jun 2004 15:21:39 +0200,
txemi wrote:
after installing this package no info is provided on how to use it.
I have seen people tempted to replace libc6 files with libc6-dbg in the
most dartiest way by moving files with mv.
So I suggest adding some doc file to package suggesting how
Package: libc6-dbg
Version: 2.3.2.ds1-13
Severity: wishlist
After installing this package no info is provided on how to use it.
I have seen people tempted to replace libc6 files with libc6-dbg in the
most dirtiest way by moving files with mv.
So I suggest adding some doc file to package (/usr
At Tue, 29 Jun 2004 12:50:49 +0200,
Jose Miguel Martinez wrote:
After installing this package no info is provided on how to use it.
I have seen people tempted to replace libc6 files with libc6-dbg in the
most dirtiest way by moving files with mv.
So I suggest adding some doc file to package
Package: libc6-dbg
Version: 2.3.2.ds1-13
Severity: wishlist
After installing this package no info is provided on how to use it.
I have seen people tempted to replace libc6 files with libc6-dbg in the
most dirtiest way by moving files with mv.
So I suggest adding some doc file to package
(/usr
At Tue, 29 Jun 2004 12:50:49 +0200,
Jose Miguel Martinez wrote:
After installing this package no info is provided on how to use it.
I have seen people tempted to replace libc6 files with libc6-dbg in the
most dirtiest way by moving files with mv.
So I suggest adding some doc file to package
: 1.0
To: [EMAIL PROTECTED]
Subject: libc6-dbg seems to have no debugging infos in libc-2.3.1.so
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-2.5 required=5.0
tests=NOSPAM_INC
: 1.0
To: [EMAIL PROTECTED]
Subject: libc6-dbg seems to have no debugging infos in libc-2.3.1.so
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-2.5 required=5.0
tests=NOSPAM_INC
Package: libc6-dbg
Version: 2.3.1-3
Severity: important
As the title says, it seems that the /usr/lib/debug/libc-2.3.1.so file
installed by the libc6-dbg package
does not contain debugging infos...
Am I right, or the xxx-dbg packages are intended to be used in
conjunction with the source
Package: libc6-dbg
Version: 2.3.1-3
Severity: important
As the title says, it seems that the /usr/lib/debug/libc-2.3.1.so file
installed by the libc6-dbg package
does not contain debugging infos...
Am I right, or the xxx-dbg packages are intended to be used in
conjunction with the source
Bug Tracking System [EMAIL PROTECTED]
Subject: libc6-dbg: dangling symlink for libthread_db
X-Reportbug-Version: 0.48
X-Mailer: reportbug 0.48
Date: Mon, 17 Jan 2000 12:37:51 +0100
Message-Id: [EMAIL PROTECTED]
Sender: laurent bonnaud [EMAIL PROTECTED]
Package: libc6-dbg
Version: 2.1.2-11
Severity
Package: libc6-dbg
Version: 2.1.2-11
Severity: normal
Hi,
here is the dangling symlink:
/usr/lib/debug/libthread_db.so.1 - libthread_db-1.0.so
-- System Information
Debian Release: potato
Architecture: i386
Kernel: Linux picpoul 2.2.14 #1 SMP Mon Jan 10 12:40:16 CET 2000 i686
Versions
Your message dated Tue, 21 Sep 1999 21:14:29 -0700
with message-id [EMAIL PROTECTED]
and subject line please consider splitting libc6-dbg and libc6-prof
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case
85 matches
Mail list logo
