Bug#576720: [ia64] gdb FTBFS and freezes / reboots the machine
On Tue, Apr 06, 2010 at 08:44:13PM +0200, Andreas Barth wrote: Package: gdb Version: 7.1-1 Severity: serious Hi, on trying to build gdb, the buildd freezes (mundy) or gets rebooted (alkman). This package was tried 3 times on mundy and 1 time on alkman. The log files ends with (please note that this may not be the last real line - the machine gets rebooted): Do you think this is a bug in GDB? It sounds like the kernel is broken. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561924: gdb: FTBFS on kfreebsd-amd64 with 8.x kernel headers
On Wed, Feb 03, 2010 at 09:20:23AM +0100, Petr Salinger wrote: They have been removed somehere during 8.0 development, it started with 80, the 8.0 release have 800107. I did'n know the exact version, so please change the check to #if (__FreeBSD_version 800075) (__FreeBSD_kernel_version 800075) So the issue is checking __FreeBSD_version and not __FreeBSD_kernel_version? Does normal FreeBSD define both? Please, do you have some hints how to teach gdb, that on GNU/kFreeBSD is thread handling the same as in linuxthreads (pre-NPTL) implementation (#550361). Sorry, I don't know how to do that. You'd need to bring in linux-thread-db.c and bits of linux-nat.c somehow. I doubt it's really the same at the level GDB sees it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561924: gdb: FTBFS on kfreebsd-amd64 with 8.x kernel headers
On Mon, Dec 21, 2009 at 01:12:35PM +0100, Petr Salinger wrote:
Hi,
the current version fails to build on GNU/kFreeBSD with 8.x kernel
headers.
The FreeBSD 8.0 kernel does not have segment registers in pcb anymore.
To solve current FTBFS please just use patch bellow.
Sorry for the inconvenience.
In GDB 7.0.1, where this bug was just re-reported, GDB says:
#if (__FreeBSD_version 800075)
regcache_raw_supply (regcache, AMD64_DS_REGNUM, pcb-pcb_ds);
regcache_raw_supply (regcache, AMD64_ES_REGNUM, pcb-pcb_es);
regcache_raw_supply (regcache, AMD64_FS_REGNUM, pcb-pcb_fs);
regcache_raw_supply (regcache, AMD64_GS_REGNUM, pcb-pcb_gs);
#endif
Is that the wrong version? The patch was:
2008-10-16 Steven G. Kargl ka...@gcc.gnu.org (tiny patch)
* amd64fbsd-nat.c (amd64fbsd_supply_pcb): Conditionally compile in
support for pcb-pcb_{fs,ds,es,gs} on FreeBSD older than 8.0.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536992: gdb: FTBFS: make[3]: *** No rule to make target `install'. Stop.
On Tue, Jul 14, 2009 at 09:00:51AM -0400, Lucas Nussbaum wrote: Relevant part: make[2]: Entering directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir' /bin/sh /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/mkinstalldirs /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr mkdir -p -- /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr make[3]: Entering directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir/bfd' make[3]: *** No rule to make target `install'. Stop. make[3]: Leaving directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir/bfd' make[2]: *** [install-bfd] Error 2 This doesn't make sense. There's an install target in that Makefile.in, but no install-bfd target. There's no sign in the build log of rerunning automake, either. Is this reproducible in some way that the build directory survives? FWIW, I built the packages on amd64, in a pbuilder chroot. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536992: gdb: FTBFS: make[3]: *** No rule to make target `install'. Stop.
On Tue, Jul 14, 2009 at 11:50:47AM -0400, Lucas Nussbaum wrote: On 14/07/09 at 10:47 -0400, Daniel Jacobowitz wrote: On Tue, Jul 14, 2009 at 09:00:51AM -0400, Lucas Nussbaum wrote: Relevant part: make[2]: Entering directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir' /bin/sh /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/mkinstalldirs /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr mkdir -p -- /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr /build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/debian/tmp/usr make[3]: Entering directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir/bfd' make[3]: *** No rule to make target `install'. Stop. make[3]: Leaving directory `/build/user-gdb_6.8.50.20090628-1-amd64-0rTyY4/gdb-6.8.50.20090628/objdir/bfd' make[2]: *** [install-bfd] Error 2 This doesn't make sense. There's an install target in that Makefile.in, but no install-bfd target. There's no sign in the build log of rerunning automake, either. Is this reproducible in some way that the build directory survives? Yes, I've just reproduced it in a clean chroot with dpkg-buildpackage. I've tar'ed the build dir, but it's quite big (101 MB). Do you want me to upload it somewhere for you? Sure - do you have somewhere you could put it? people.d.o? FWIW, I built the packages on amd64, in a pbuilder chroot. Have you tried again today? I built and uploaded -3 last night, using a freshly updated pbuilder chroot, and using the same source tarball. I can try it again today. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536992: gdb: FTBFS: make[3]: *** No rule to make target `install'. Stop.
On Tue, Jul 14, 2009 at 07:27:47PM +0200, Stéphane Glondu wrote: Same problem as #537011: gdb builds successfully after downgrading cdbs to 0.4.56. FWIW, I'm pretty sure the build I did this morning used CDBS 0.4.57... I'm not sure, though, I wish it was easier to save trees after pdebuild. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509873: [libgdb-dev] Re: [libgdb-dev] Undefined symbols in libgdb.a
On Thu, Jun 11, 2009 at 11:33:01PM +0200, Mazen NEIFER wrote: Any news about this bug? Could you please provide an estimation about when it could get solved? I'm trying to find time to work on it. I'll do it as soon as I can, or anyone is welcome to submit a patch. I believe the planned fix is already described in the bug log. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518452: All programs segfault when running under gdb
On Fri, Mar 06, 2009 at 03:38:44AM -0500, Bryan Donlan wrote: (gdb) run Starting program: /bin/true (no debugging symbols found) (no debugging symbols found) Program received signal SIGTRAP, Trace/breakpoint trap. 0xf7f8bba8 in ?? () (gdb) cont Continuing. There is no plausible way that this is a GDB bug. It's going to be a problem with your kernel. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509873: [libgdb-dev] Re : Use libiberty.a and libexpat.a
On Wed, Feb 04, 2009 at 05:26:00PM +, marcos.mar...@sonae.com wrote: Hi there, Any updates on this issue? Not yet, sorry. I think the best solution would be to add the contents of libiberty.a to libgdb.a at the end of the GDB build. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509873: [libgdb-dev] Re : Use libiberty.a and libexpat.a
On Tue, Dec 30, 2008 at 12:25:45AM +0100, Mazen NEIFER wrote: Package: libgdb-dev Version: 6.8-3 --- Please enter the report below this line. --- /usr/lib/libgdb.a(exec.o): In function `generic_skip_trampoline_code': (.text+0x0): multiple definition of `generic_skip_trampoline_code' /usr/lib/libgdb.a(arch-utils.o):(.text+0x0): first defined here How are you linking the library to cause this error? --whole-archive? I'm using FPC which produces the attached linker script. Oh right, this was fixed upstream but the fix may not be in Debian yet. #include foo.c instead of foo.h. /usr/lib/libgdb.a(gdbtypes.o):(.data+0x50): undefined reference to `floatformat_ibm_long_double' You need -liberty. I could not find this function in libiberty.a Version skew - that libiberty.a is from an older version of binutils than this version of GDB. The function is in GDB's version of libiberty. I have no idea what to do about that. I don't want to have multiple versions of libiberty installed... I will think about it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509873: [libgdb-dev] Unresolved symbols
On Sat, Dec 27, 2008 at 12:18:50PM +0100, Mazen NEIFER wrote: After installing binutils-dev package the following error is got : It is a static library; it has no way to indicate its dependencies. /usr/lib/libgdb.a(exec.o): In function `generic_skip_trampoline_code': (.text+0x0): multiple definition of `generic_skip_trampoline_code' /usr/lib/libgdb.a(arch-utils.o):(.text+0x0): first defined here How are you linking the library to cause this error? --whole-archive? /usr/local/src/fpcbuild-2.2.3/build/fpc-2.2.3/fpcsrc/packages/gdbint/units/i386-linux/gdbint.o: In function `GDBINT_INITLIBGDB': gdbint.pp:(.text+0x1666): undefined reference to `error_init' This is not related to libgdb. /usr/lib/libgdb.a(gdbtypes.o):(.data+0x50): undefined reference to `floatformat_ibm_long_double' You need -liberty. (.text+0x69e): undefined reference to `XML_SetParamEntityParsing' Also -lexpat. Soon you'll need Python, too. I'll update the dependencies if I can find where to pull libiberty from. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#485955: gdb: completely fails to detect frames
On Sun, Jun 22, 2008 at 07:30:59PM -0400, James Y Knight wrote: Could this be the same bug as: https://bugzilla.novell.com/show_bug.cgi?id=390722 and https://bugs.launchpad.net/ubuntu/hardy/+source/gdb/+bug/111869 ? (with patch available) No, it's not related. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 06:19:35PM +0200, Pierre Habouzit wrote: Is a shared library involved? No, the symbol is local, visibility hidden. Normally, when this happens, there is a symbol in the ELF symbol table (.symtab) for the hidden symbol. That symbol is missing in your case. I don't know why it worked pre-6.7, but this is not a well-supported case in GDB. It expects there to be ELF symbols for all functions. Fortunately, an optimized code improvement added to GDB HEAD after 6.8 fixes your testcase again. In the mean time, I suggest you use 6.7, use HEAD, or arrange not to strip a subset of ELF symbols. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
severity 485955 normal thanks On Thu, Jun 12, 2008 at 05:41:02PM +0200, Pierre Habouzit wrote: Since the 6.8 releases, gdb totally fails to detect stack frames correctly, whereas the lenny version (6.7.1-2 atm) works fine. My architecture is amd64, but I've seen the same issues on i386 FWIW. I've seen no evidence this bug affects anyone else and the package is clearly not unusable. Downgrading. The code is C, with quite a few inlines, changing the gcc debug levels (-g/-g3/-ggdb3) or even building with -O0 -fno-inline doesn't change a damn thing. This renders gdb mostly unusable because it's totally unable to dump useful backtraces (with source files and files lineno's) on segfaults. Can you provide a test case? Or even an example session? I can't read your mind... -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 06:11:28PM +0200, Pierre Habouzit wrote: #0 sms_emi_ack_5X (out=0x1b1dc88, msg=0x7fff637d97e0) at lib-inet/sms-emi.c:230 #1 0x00404973 in ?? () With gdb from etch: (gdb) bt #0 sms_emi_ack_5X (out=0x110dc88, msg=0x7fff73230240) at lib-inet/sms-emi.c:230 #1 0x00404973 in smsc_emi_on_query (we=0x110dbe0, msg=0x7fff73230240) at simulator/smsc/emi_smsc.c:232 Note, same address. Is a shared library involved? Does list smsc_emi_on_query do anything? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 06:19:35PM +0200, Pierre Habouzit wrote: sid: (gdb) list smsc_emi_on_query No line number known for smsc_emi_on_query. (gdb) b smsc_emi_on_query Breakpoint 1 at 0x404520 The debug readers were not able to parse this function's debug info. Is there any chance you can reproduce this with a smaller piece of code that you can share? I don't need source, just linked executable. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485955: gdb: completely fails to detect frames
On Thu, Jun 12, 2008 at 06:47:03PM +0200, Pierre Habouzit wrote: (gdb) b smsc_emi_on_query During symbol reading, DW_AT_name missing from DW_TAG_base_type. During symbol reading, unsupported tag: 'DW_TAG_const_type'. Breakpoint 1 at 0x404520 These complaints are not relevant to your error. Also, the testsuite is still running but I already saw those failures: See the log in /usr/share/doc/gdb for typical failures. Does readelf -wi complain about the file containing one of your 'invisible' functions? What does the DW_TAG_subprogram look like for smsc_emi_on_query? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477863: gdb: adjust build-dependency (gcj not built on alpha, arm, hppa and hurd-i386)
tags 477863 + pending thanks GDB only depends on gcj to run the Java testsuite. I've dropped it for the mentioned arches. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478734: g++-4.2: refuses to compile valid C++ syntax
severity 478734 normal thanks On Wed, Apr 30, 2008 at 11:55:19AM -0500, Jason Kraftcheck wrote: Severity: grave This is not grave, g++ is perfectly usable for other code. I emmits the following error message: bug.cc: In function 'int main()': bug.cc:6: error: no matching function for call to 'std::vectorint, std::allocatorint ::swap(std::vectorint, std::allocatorint )' /usr/include/c++/4.2/bits/stl_vector.h:728: note: candidates are: void std::vector_Tp, _Alloc::swap(std::vector_Tp, _Alloc) [with _Tp = int, _Alloc = std::allocatorint] I'm pretty sure GCC is correct to refuse this. The result of a cast is an rvalue, so you can not take a reference to it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433273: FTBFS: Versioned Build-Depends on linux-kernel-headers
On Sat, Mar 08, 2008 at 03:14:03AM -0800, Steve Langasek wrote: Hi Dan, I've prepared a zero-day NMU for this RC bug as part of the ongoing bug squashing party. While I'm at it, I've applied the patch from bug #379708, which has been well-tested in Ubuntu for some time and brings the bogl package completely back in sync between Debian and Ubuntu. Please find the diff attached. The NMU will be uploaded to incoming shortly. Thank you! All things considered, I'm going to change the bogl RFA to an O. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466807: not installed with base system
On Thu, Feb 21, 2008 at 05:07:06PM -0600, William Pitcock wrote: Because perl requires locales to run correctly, and locales is not marked essential, so debootstrap does not pull it in as part of the base system. locales is not essential. Clear the locale settings from your environment and perl will shut up. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453202: gdb: FTBFS: make[4]: Nothing to be done for `info-am'.
On Tue, Nov 27, 2007 at 09:02:43PM +0100, Lucas Nussbaum wrote: make[3]: *** [info-recursive] Error 1 Hmm: WARNING: `makeinfo' is missing on your system. You should only need it if you modified a `.texi' or `.texinfo' file, or any other file indirectly affecting the aspect of the manual. The spurious call might also be the consequence of using a buggy `make' (AIX, DU, IRIX). You might want to install the `Texinfo' package or the `GNU make' package. Grab either from any GNU archive site. make[4]: *** [bfd.info] Error 1 And: checking for makeinfo... /build/user/gdb-6.6.dfsg.90.20070912/missing makeinfo --split-size=500 configure: WARNING: *** Makeinfo is missing. Info documentation will not be built. But: Setting up texinfo (4.11.dfsg.1-2) ... Right. This is caused by a bug in GDB prior to 6.7.1, which had a bad regular expression for the texinfo version. It will be fixed in the next upload. Thanks! -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442346: gdb: GDB unable to debug F90-program
close 442346 fixed 442346 6.6.dfsg-3 merge 442346 425838 tags 442346 + lenny thanks On Sat, Sep 15, 2007 at 01:21:59PM +0200, Marcus Lundblad wrote: This GDB was configured as x86_64-linux-gnu...BFD: /home/marcus/prg/partalg/baltic/dist: don't know how to handle OS specific section `.gnu.hash' [0x6ff6] /home/marcus/prg/partalg/baltic/dist: not in executable format: This is fixed in the GDB in unstable. I'm trying to get a new one into testing. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428655: closed by Pierre Habouzit [EMAIL PROTECTED] (Re: Bug#428655: libc6: preinst check makes upgrading old libc6 versions impossible)
On Wed, Jun 13, 2007 at 02:44:25PM +0200, David Purdy wrote: I could add another hack.. like disable that libc6 check You don't want to do that. It's there for a reason; if you override the check, absolutely nothing will run. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425838: gdb refuses all c binaries on amd64 platform
On Thu, May 24, 2007 at 01:38:18PM +0200, Folkert van Heusden wrote: Package: gdb Version: 6.4.90.dfsg-1 Severity: grave Justification: renders package unusable On the AMD64 release of Debian-testing (running on an Intel E6600 platform), gdb refuses all binaries: Binutils added an incompatible format change. That version of binutils made it to testing before the GDB update; try grabbing GDB from unstable. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423631: segfaulting gdb on ia64
On Tue, May 22, 2007 at 06:00:20AM -0600, Matthew Wilcox wrote: I hit the same problem as the buildd and Kurt. Since I need something more recent than gdb 6.5 in order to handle current ia64 executables, I tried to run it anyway. It's not pretty: If you have some time to look at this, could you try building a CVS checkout of GDB on ia64? Maybe that will work better. /home/willy/debian/gdb/gdb-6.6.dfsg/gdb/libunwind-frame.c:272: internal-error: libunwind_frame_prev_register: Assertion `regnum = 0' failed. That's very strange... -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423631: segfaulting gdb on ia64
On Tue, May 22, 2007 at 08:12:07AM -0600, Matthew Wilcox wrote: Much better: Interesting. I don't suppose you want to look into this? /home/willy/debian/gdb/gdb-6.6.dfsg/gdb/libunwind-frame.c:272: internal-error: libunwind_frame_prev_register: Assertion `regnum = 0' failed. IIRC there's a configure option you have to specify to use libunwind; maybe that's what's broken. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422971: gcc-4.1: FTBFS on arm: Error: junk at end of line, first unrecognized character is `, '
On Wed, May 09, 2007 at 09:52:26AM +0200, Matthias Klose wrote: clone 422971 -1 reassign 422971 binutils thanks This patch is applied now for some time (originally taken from the Fedora branch); the binutils from the trunk doesn't accept this code anymore. It never should have. The assembler does not like this line, which is added by debian/patches/note-gnu-stack.dpatch: .section .note.GNU-stack,,@progbits .section .note.GNU-stack,,%progbits @ is an ARM comment marker. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
On Wed, May 09, 2007 at 12:48:17AM +0100, James Troup wrote: (1) seems the most obvious, since h-s=both doesn't have any significant disadvantage (small amount of wasted space?) but does have the advantages of h-s=gnu. However it will require bin-only NMUs of any packages rebuilt with h-s=gnu gcc that d-i uses. I would recommend this. --hash-style=gnu is very new; I doubt readelf is the only tool that isn't ready for it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421790: gcc-4.1: Dynamic symbol information missing in stripped libraries
On Thu, May 03, 2007 at 07:36:59PM +0200, Kurt Roeckx wrote: From the -5 changelog: * Link using --hash-style=gnu/both. It seems to only generate a gnu hash now. Looking at the difference in sections between -4 and -5, .hash got replaced by a .gnu.hash section. I assumed from the changelog that it would be using both, but that doesn't seem to be the case. I think it's just a bug in readelf that it can't deal with the gnu hash. IIRC it was fixed recently upstream. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393023: PAGE_SIZE export
On Fri, Jan 12, 2007 at 11:30:22AM +0100, Martin Mares wrote: Please revert this patch and leave the decision to upstream maintainers. This bug is assigned to bogl. I assume from your message you meant to reach the linux-kernel-headers maintainers - try debian-glibc instead. Also upstream kernels do not export PAGE_SIZE for various architectures. For instance ia64. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404801: Kill -9 on gdb processs results in a kernel krash.
On Thu, Dec 28, 2006 at 11:53:06AM +0100, Håkan Larsson wrote: Package: gdb Version: 6.3-6 Severity: critical Justification: breaks the whole system We are currently running our program with gdb inside a screen. Every night we restart it by running kill -9 on both the screen and gdb pids. This results in a kernel crash. A screenshot from the console output can be found here: http://www.streamingemotions.se/console.jpg Sorry, I didn't see this message. This is not a GDB bug. Kernel crashes are always kernel bugs. Are you using a Debian packaged kernel? If so I will reassign it to the kernel (I suspect this is fixed in the kernels in etch). -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401482: gdb: Failed to read a valid object file image from memory
severity 401482 important thanks This is hardly RC. GDB seems to work for lots of people. I'm happy to help with bug reports, but please don't abuse severity. On Sun, Dec 03, 2006 at 11:15:53PM +, Sam Morris wrote: GDB always reports that it Failed to read a valid object file image from memory when executing a program. This seems to make back traces useless (they come out as in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400965) and breakpoints often unworkable (they are often not triggered). You need to give me a recipe or a small test case demonstrating this problem, so that I can try to reproduce it. I suspect I won't be able to without switching to the Debian ia32 kernels; I only run 64-bit kernels at home. The object file in memory is the kernel's virtual DSO (vDSO). -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396817: PowerPC timeout on washngo
On Fri, Nov 17, 2006 at 09:20:37AM -0600, John Goerzen wrote: Hi Dan, I received bug #396817 reporting that washngo failed to build on powerpc due to an inactivity timeout. I believe that the package actually could take a very long time to build on powerpc, and would appreciate it if you could raise the timeout. Doubling or triping it would probably not be unreasonable. You'd have to ask Ryan Murray. Do you happen to know what speed of CPU and how much RAM the machine has? It's a dual 500mhz G4 with only 320MB RAM + 512MB swap. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396973: gdb: can not debug any program linked with pthread.
On Fri, Nov 03, 2006 at 07:29:59PM -0500, Nick Lewycky wrote: Severity: grave Justification: renders package unusable Obviously not for everyone; it passes the testsuite during package build. I can only assume that either your C library or kernel has somehow gotten broken. Could you run strace -o strace.log gdb ./simple, run the program to the error, and send me that log? Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.1 Does this mean you're running a 32-bit installation and a 64-bit kernel? Did you build the kernel yourself? -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396973: gdb: can not debug any program linked with pthread.
On Fri, Nov 03, 2006 at 08:05:32PM -0500, Nick Lewycky wrote: Attached. Here's the exact session I ran: ptrace(0x19 /* PTRACE_??? */, 29003, 0xc, 0xff888354) = -1 EINVAL (Invalid argument) Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.1 Does this mean you're running a 32-bit installation and a 64-bit kernel? Did you build the kernel yourself? Yes and yes. It completely didn't occur to me until just now, but this was the right question. A 32-bit GDB will not work on threaded programs on a 64-bit kernel; it's just broken. I believe the problem is a ptrace operation that is not properly emulated by the 32-bit compatibility layer. I'm afraid this is a kernel bug. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394418: [Pkg-mono-group] Bug#394418: question for ARM porters: incomplete arm v3 support in etch?
On Sat, Oct 28, 2006 at 04:27:33PM +0200, Mirco Bauer wrote: We can see here, that the same upstream version and same debian revision, show different results between netwinder model and cats model: it builds on cats and fails on netwinder (see 1.1.18-3 and 1.1.17.1-4). As said I am not a porter, so I don't know the difference between cats and netwinder, but AFAIK cats is v4l and netwinder is v3l. Upstream tests and only has access to arm v5l and can't reproduce this problem, as seen in the upstream bugreport. I am pretty sure that's not right; netwinder is a StrongARM, which is architecture version 4. Very very little is really armv3 any more. Of course, as far as I can tell, cats boards are also StrongARM... maybe someone who knows for sure will correct me if I got that wrong. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393023: diff for 0.1.18-1.5 NMU
On Fri, Oct 20, 2006 at 05:12:02PM -0400, Joey Hess wrote: I note that I've made the last 4 nmus and that this package seems to need a new maintainer. Yes. Someone promised to adopt it, but never had time for an upload, so I filed an RFA. Probably ought to be adjusted to an O at this point. Thank you for taking care of this. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394381: gdb: FTBFS, indirectly uses PAGE_SIZE
On Fri, Oct 20, 2006 at 03:03:53PM -0600, Troy Heber wrote: gdb contains bfd, and bfd uses NBPG defined in sys/user.h. However, that is just a redefinition of PAGE_SIZE which is no longer defined to user space becasue of #ifdef __KERNEL__, See #393023. Using PAGE_SIZE directly from a user space application is broken because systems now can have variable PAGE_SIZE. The problem is that the clobbered PAGE_SIZE but didn't audit for its dependencies. I might be wrong, but I think that this is a bug in glibc; I understand why it can't provide PAGE_SIZE, but it ought to provide NBPG if it's going to bother to provide struct user (a purely legacy format) at all. It seems like a hideous hack to have to try to compile NBPG in autoconf. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388052: mplayer-nogui: mplayer segfaults (ld at fault)
On Tue, Sep 19, 2006 at 10:24:34AM +0200, Josselin Mouette wrote: warning: Can't read pathname for load map: Input/output error. warning: .dynamic section for /usr/lib/libasound.so.2 is not at the expected address warning: difference appears to be caused by prelink, adjusting expectations Two things here: 1. Are you using prelink? If you are, that may be a prelink bug. 2. Otherwise, the I/O error can be caused by a hardware or filesystem problem. You should read the dmesg output to look for error messages there. Actually, this particular I/O error has nothing to do with hardware; it has to do with the kernel's virtual DSO page, if I remember right. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386267: FTBFS: sysutil.c:604: error: assignment of read-only member '__in'
CC'ing new maintainer.
On Thu, Sep 07, 2006 at 06:44:36PM +0200, Martin Michlmayr wrote:
* Martin Michlmayr [EMAIL PROTECTED] [2006-09-06 13:34]:
gcc -c sysutil.c -g -O2 -Wall -W -Wshadow -idirafter dummyinc
sysutil.c: In function 'vsf_sysutil_wait_exited_normally':
{
- return WIFEXITED(p_waitret-exit_status);
+ return WIFEXITED((struct vsf_sysutil_wait_retval
*)p_waitret-exit_status);
}
Dan, maybe you have some time to look at this issue more deeply.
Here's a smal testcase:
struct rx_length_info
{
unsigned short tag;
};
void f(void)
{
const struct rx_length_info *length_info;
__typeof__ (*(length_info-tag)) __v = *(length_info-tag);
}
pinskia pointed out that it works with the following change:
- __typeof__ (*(length_info-tag)) __v;
- __v = *(length_info-tag);
+ __typeof__ (*(length_info-tag)) __v = *(length_info-tag);
/usr/include/stdlib.h defines:
# define
__WAIT_INT(status)
(__extension__ ({ union { __typeof(status) __in; int __i; } __u; \
__u.__in = (status); __u.__i; }))
Is there some way this could be rewritten so applications don't need
to cast the const away?
I don't know. You might be able to use a union initializer in the same
way.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383976: unable to upgrade package libc6
On Tue, Aug 22, 2006 at 03:56:13PM +0200, Aurelien Jarno wrote:
I now have a more precise idea of the problem. The following command
produce a segfault:
LD_ASSUME_KERNEL=2.4.1 LD_PRELOAD=/usr/lib/libaoss.so /bin/bash -x /bin/egrep
where /bin/grep contains:
#!/bin/sh
exec grep -E ${1+$@}
Note that without LD_ASSUME_KERNEL=2.4.1 (ie using nptl instead of
linuxthreads) or using dash instead of bash, the problem goes out.
gdb returns nothing, so I don't really know where is the problem and how
to debug it.
Can you get a core dump? Alternatively, inserting gdbserver before
/bin/bash and using remote debugging sometimes helps; it perturbs the
process less than gdb does. But only if the parent process is the one
you need to debug.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383976: unable to upgrade package libc6
On Wed, Aug 23, 2006 at 01:08:07AM +0200, Aurelien Jarno wrote: 20:39 aurel32 To fix the problem: 20:39 aurel32 - I don't understand why __ functions are diverted in alsa-oss, maybe this is not necessary??? Or you could call a version of open which always binds locally (I suspect __libc_open would work, I'm not sure). BTW, it would be nice if you can sync smp.h from linuxthreads with the one from NPTL in upstream CVS. I'll keep that in mind, thanks. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378393: diff for 1.4.4.cvs20060709-2.1 NMU
On Tue, Jul 25, 2006 at 02:31:52PM +0200, Julien Danjou wrote: Package: dejagnu Version: 1.4.4.cvs20060709-2 Severity: normal Tags: patch Hi, Attached is the diff for my dejagnu 1.4.4.cvs20060709-2.1 NMU. Thanks, I've merged this in my local tree. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212522: Ridiculous pedantry vs. ignorance of the law
One-sided rant snipped. While you're at it, not thread-breaking would be appreciated. On Sat, Apr 01, 2006 at 04:56:40PM -0500, Nathanael Nerode wrote: Summary: If you put a statement in the file, with the FSF's blessing, which says This file is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Then there's no more problem and you can just ship the file. So just go do that, OK? As far as I can tell, this would make the manual unacceptably licensed. Doesn't it need an explicit statement of dual licensing? I couldn't find sample wording anywhere, so I wrote my own; that might be a good candidate to add to your page about this issue. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355129: Intent to NMU
On Sat, Apr 15, 2006 at 02:30:08PM -0300, Margarita Manterola wrote: I intend to NMU ncurses to fix this bug. I'm attaching the full diff file, and the corresponding interdiff. Thanks. I left this sit too long, because there was nothing in the bug report that explained why it was a problem. Why did this bug matter? Obviously it did not cause a failure to build from source. Ah - for cross builds? I'll merge the fix into the next maintainer upload. In the future, if you're going to bother to send a message of intent, then it would be polite to send it more than a few hours before I get a message from dinstall. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360666: joe now crashes with HOME set
Package: joe Version: 3.3-3 Severity: grave Justification: renders package unusable The changelog says this release fixed a bug which caused Joe to crash at startup if HOME was unset. Well, now it crashes if HOME is set; a NULL pointer is passed to sprintf where the home directory is obviously wanted. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-rc1 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages joe depends on: ii libc6 2.3.6-4GNU C Library: Shared libraries an ii libncurses5 5.5-1 Shared libraries for terminal hand joe recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360666: joe now crashes with HOME set
On Tue, Apr 04, 2006 at 01:22:33AM +0200, Josip Rodin wrote:
On Mon, Apr 03, 2006 at 06:51:39PM -0400, Daniel Jacobowitz wrote:
Package: joe
Version: 3.3-3
Severity: grave
Justification: renders package unusable
The changelog says this release fixed a bug which caused Joe to crash at
startup if HOME was unset. Well, now it crashes if HOME is set; a NULL
pointer is passed to sprintf where the home directory is obviously wanted.
What? I can't reproduce that on my poor old normal sarge system.
Can you please point me to the exact point in code where this breaks for you?
It may be something catastrophic that has gone wrong in the amd64
archive rebuild? It definitely did not happen with my previously
installed 3.3-2, this afternoon. I switched to the http.us.debian.org
archive today and upgraded to 3.3-3 and it exploded.
However, I can rebuild from source and reproduce it. Ah, I see.
1300p = (unsigned char *)getenv(HOME);
1301f = 0;
1302if (p) {
1303joe_snprintf_2((char
*)buf,sizeof(buf),%s/.joe/charmaps/%s,p,name);
1304f = fopen((char *)buf,r);
1305}
We're at line 1303 and p == NULL.
charmap.c: In function 'find_charmap':
charmap.c:1300: warning: cast to pointer from integer of different size
If you want to use getenv, please, please, please, include its
prototype. It looks like HAVE_STDLIB_H has not gotten set, presumably
because nothing has bothered to include autoconf.h before testing it.
If you include config.h first, this works. I saw similar warnings when
building termcap.c and i18n.c. i18n.c is also missing config.h, but
adding it does not fix the warnings.
termcap.c: In function 'jgetstr':
termcap.c:414: warning: cast to pointer from integer of different size
termcap.c: In function 'texec':
termcap.c:519: warning: cast to pointer from integer of different size
i18n.c: In function 'joe_towupper':
i18n.c:2723: warning: cast to pointer from integer of different size
i18n.c:2724: warning: cast to pointer from integer of different size
i18n.c: In function 'joe_towlower':
i18n.c:3517: warning: cast to pointer from integer of different size
i18n.c:3518: warning: cast to pointer from integer of different size
So, there are probably other problems lurking.
There's some good warnings in -Wall for this... but the result of
compiling joe with -Wall is not confidence-inspiring.
--
Daniel Jacobowitz
CodeSourcery
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212522: Time to remove the GDB manual
On Thu, Mar 30, 2006 at 10:07:02PM -0500, Nathanael Nerode wrote: I assume you're referring to observer.h etc.? This actually indicates a nasty licensing mistake upstream. I don't have any reason to believe that there is a problem here. observer.texi does not have an explicit license, GFDL or otherwise. The intent to use it under both is quite clear. It's just a complication for the build process. Barring that, you'll have to write a replacement for observer.h, and you'll have to write it without referring to the manual. Have fun. :-P I can write it off the top of my head and with my eyes closed, but I am not about to do that, unless the ridiculous pedantry of debian-legal forces me to. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212522: Time to remove the GDB manual
On Sun, Mar 26, 2006 at 02:39:50PM -0800, Steve Langasek wrote: Hi Dan, On Fri, Mar 24, 2006 at 09:48:58AM -0500, Daniel Jacobowitz wrote: On Sun, Mar 12, 2006 at 06:26:15PM -0500, Nathanael Nerode wrote: There has been absolutely no progress. It's March. The manual still contains invariant sections upstream and in Debian. Documentation with invariant sections was reaffirmed as non-free in the most recent GR. Time to remove the manual. Yes, sadly, it is. I'll do this with the next upload (shouldn't be too long). By any chance, do you have any plans to upload the manual to non-free? That's part of why it's taken so long. As a daily GDB developer, having an installed copy of this manual is absolutely essential to me. It means separating it out of the GDB build system, though. Also, I've just remembered that an important part of GDB is in fact built from the manual... I'm not entirely sure what to do about that. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212522: Time to remove the GDB manual
On Sun, Mar 12, 2006 at 06:26:15PM -0500, Nathanael Nerode wrote: There has been absolutely no progress. It's March. The manual still contains invariant sections upstream and in Debian. Documentation with invariant sections was reaffirmed as non-free in the most recent GR. Time to remove the manual. Yes, sadly, it is. I'll do this with the next upload (shouldn't be too long). -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356628: glibc_2.3.999-1(hppa/experimental): FTBFS: missing files
On Mon, Mar 13, 2006 at 01:59:43AM +0100, Frank Lichtenheld wrote: | checking sysdep dirs... configure: error: The hppa is not supported. | make: *** [/build/buildd/glibc-2.3.999/stamp-dir/configure_libc] Error 1 | ** This suggests we need an --enable-add-ons=ports for all the targets in ports (or for all targets - it's harmless). -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310713: valgrind noise from mlview
Package: mlview Version: 0.7.1-1 Followup-For: Bug #310713 This may be a similar problem, I'm not sure. Load this trivial XML file in mlview, agree to load the DTD, and then try to click on anything in the element view. [EMAIL PROTECTED]:/space/fsf/target-registers/xml% cat gdb-target.dtd !ELEMENT feature (description?, (reg)*) !ATTLIST feature nameID #REQUIRED base-regnum CDATA #IMPLIED !ELEMENT reg EMPTY [EMAIL PROTECTED]:/space/fsf/target-registers/xml% cat simple.xml ?xml version=1.0 encoding=UTF-8 standalone=no ? !DOCTYPE feature SYSTEM gdb-target.dtd feature name=feature-foo reg/ /feature ==10359== Invalid free() / delete / delete[] ==10359==at 0x4A1B5B3: free (vg_replace_malloc.c:235) ==10359==by 0x7791C5F: xmlValidGetValidElementsChildren (in /usr/lib/libmlview.so.7.0.0) ==10359==by 0x77BFFFB: mlview_parsing_utils_build_element_name_completion_list (in /usr/lib/libmlview.so.7.0.0) ==10359==by 0x77DF105: mlview_completion_table_select_node (in /usr/lib/libmlview.so.7.0.0) ==10359==by 0x779A835: (within /usr/lib/libmlview.so.7.0.0) ==10359==by 0x72A34BF: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.800.6) ==10359==by 0x72B20C1: (within /usr/lib/libgobject-2.0.so.0.800.6) ==10359==by 0x72B359B: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.800.6) ==10359==by 0x72B3952: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.800.6) ==10359==by 0x77BA30D: mlview_xml_document_select_node (in /usr/lib/libmlview.so.7.0.0) ==10359==by 0x77D27C6: mlview_tree_editor_select_node (in /usr/lib/libmlview.so.7.0.0) ==10359==by 0x77C503D: (within /usr/lib/libmlview.so.7.0.0) ==10359== Address 0xAE5EB9C is 132 bytes inside a block of size 1,040 alloc'd ==10359==at 0x4A1AA16: malloc (vg_replace_malloc.c:149) ==10359==by 0x678A453: (within /usr/lib/libxml2.so.2.6.23) ==10359==by 0x678ABCC: xmlDictLookup (in /usr/lib/libxml2.so.2.6.23) ==10359==by 0x66D8EDC: (within /usr/lib/libxml2.so.2.6.23) ==10359==by 0x66E9987: xmlParseChunk (in /usr/lib/libxml2.so.2.6.23) ==10359==by 0x77BE72F: (within /usr/lib/libmlview.so.7.0.0) ==10359==by 0x77BF879: mlview_parsing_utils_load_xml_file_with_dtd_interactive (in /usr/lib/libmlview.so.7.0.0) ==10359==by 0x77B8DC1: mlview_xml_document_open_with_dtd_interactive (in /usr/lib/libmlview.so.7.0.0) ==10359==by 0x77A2AEB: mlview_editor_load_xml_file_with_dtd (in /usr/lib/libmlview.so.7.0.0) ==10359==by 0x401243: main (in /usr/bin/mlv) -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-rc1 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages mlview depends on: ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-01.10.3-1 The ATK accessibility toolkit ii libbonobo2-0 2.10.1-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.10.1-2 The Bonobo UI library ii libc6 2.3.5-12.1GNU C Library: Shared libraries an ii libeel2-2 2.12.2-3 Eazel Extensions Library (for GNOM ii libgail-common 1.8.8-1 GNOME Accessibility Implementation ii libgail17 1.8.8-1 GNOME Accessibility Implementation ii libgconf2-42.12.1-8 GNOME configuration database syste ii libglade2-01:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.8.6-1 The GLib library of C routines ii libgnome2-02.12.0.1-5The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.12.0-2 A powerful object-oriented display ii libgnomeui-0 2.12.0-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.12.2-5 GNOME virtual file-system (runtime ii libgtk2.0-02.8.10-1 The GTK+ graphical user interface ii libice66.9.0.dfsg.1-4Inter-Client Exchange library ii liborbit2 1:2.12.4-1libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.10.2-1 Layout and rendering of internatio ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsm6 6.9.0.dfsg.1-4X Window System Session Management ii libxml22.6.23.dfsg.1-0.1 GNOME XML library ii libxslt1.1 1.1.15-2 XSLT processing library - runtime ii xlibs 6.9.0.dfsg.1-4X Window System client libraries m ii zlib1g 1:1.2.3-9 compression library - runtime mlview recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL
Bug#317082: Not just a dpkg bug
On Fri, Jan 20, 2006 at 11:57:28AM +0300, Nikita V. Youshchenko wrote: I sometimes have to work with MontaVista toolchains. They to provide cross-ldd tool that just implements the same library-searching logic for non-native binaries as dynamic libker implements for native ones. I don't know if this thing is free etc, but it could be easilly implemented from scratch if we decide we need one. It's not generally available; it was a fairly substantial patch to the prelinker. There are other ways to do it. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317082: Not just a dpkg bug
On Wed, Jan 18, 2006 at 08:00:55PM -0800, Russ Allbery wrote: Frank Lichtenheld [EMAIL PROTECTED] writes: This isn't quite true I think. The current dpkg-shlibdeps code works like this: 1) use ldd binary to find the paths to the linked libraries 2) use objdump -p binary to actually check which of this libraries are listed as NEEDED (Are there cases where ldd lists libraries that are not NEEDED?) Yes. ldd will list all shared libraries pulled in by a binary, regardless of whether they're NEEDED by the binary itself or just NEEDED by one of the shared libraries it uses. For example: And also LD_PRELOAD'd libraries, et cetera (which may include fakeroot). -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212522: GDB documentation
For the record, I am holding off on this in hopes of progress; if no progress materializes by March, I will remove the manual (see Andreas Barth's post to d-d-a today). -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344148: X.org crashes on my computer with latest libc6 update
On Wed, Dec 21, 2005 at 08:44:59AM +0100, Nicolas DEGAND wrote: Le Mercredi 21 Décembre 2005 02:52, Daniel Jacobowitz a écrit : On Tue, Dec 20, 2005 at 01:19:20PM +0100, Nicolas DEGAND wrote: Package: libc6 Version: 2.3.5-8.1 Severity: grave X.org do not start at launch after upgrading to libc6 2.3.5-9 (see following xorg.log output). After downgrading to libc6 2.3.5-8.1, it works agains (II) XINPUT: Adding extended input device Configured Mouse (type: MOUSE) (II) XINPUT: Adding extended input device Generic Keyboard (type: KEYBOARD) (II) XINPUT: Adding extended input device NVIDIA Event Handler (type: Other) (II) Configured Mouse: ps2EnableDataReporting: succeeded Warning: font renderer for .pcf already registered at priority 0 Warning: font renderer for .pcf.Z already registered at priority 0 Warning: font renderer for .pcf.gz already registered at priority 0 Warning: font renderer for .snf already registered at priority 0 Warning: font renderer for .snf.Z already registered at priority 0 Warning: font renderer for .snf.gz already registered at priority 0 Warning: font renderer for .bdf already registered at priority 0 Warning: font renderer for .bdf.Z already registered at priority 0 Warning: font renderer for .bdf.gz already registered at priority 0 Warning: font renderer for .pmf already registered at priority 0 Could not init font path element unix/:7100, removing from list! That output doesn't tell us anything. Does it crash? Yes. That's the last line of the xorg log. Then I recommend you attach GDB and get a backtrace. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344148: X.org crashes on my computer with latest libc6 update
On Tue, Dec 20, 2005 at 01:19:20PM +0100, Nicolas DEGAND wrote: Package: libc6 Version: 2.3.5-8.1 Severity: grave X.org do not start at launch after upgrading to libc6 2.3.5-9 (see following xorg.log output). After downgrading to libc6 2.3.5-8.1, it works agains (II) XINPUT: Adding extended input device Configured Mouse (type: MOUSE) (II) XINPUT: Adding extended input device Generic Keyboard (type: KEYBOARD) (II) XINPUT: Adding extended input device NVIDIA Event Handler (type: Other) (II) Configured Mouse: ps2EnableDataReporting: succeeded Warning: font renderer for .pcf already registered at priority 0 Warning: font renderer for .pcf.Z already registered at priority 0 Warning: font renderer for .pcf.gz already registered at priority 0 Warning: font renderer for .snf already registered at priority 0 Warning: font renderer for .snf.Z already registered at priority 0 Warning: font renderer for .snf.gz already registered at priority 0 Warning: font renderer for .bdf already registered at priority 0 Warning: font renderer for .bdf.Z already registered at priority 0 Warning: font renderer for .bdf.gz already registered at priority 0 Warning: font renderer for .pmf already registered at priority 0 Could not init font path element unix/:7100, removing from list! That output doesn't tell us anything. Does it crash? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341514: libc6-sparc64: All 64-bit binaries fail to execute.
On Wed, Nov 30, 2005 at 08:14:43PM -0800, David S. Miller wrote: Package: libc6-sparc64 Version: 2.3.5-8 Severity: normal There are some critical things missing in the sparc64 TLS support code in the current debian glibc tree, for example none of the TLS relcation support is in sysdeps/sparc/sparc64/dl-machine.h, and therefore so no binary linked against 64-bit libc can execute. Not even /lib64/libc.so.6 --version will work, it will fail because the dynamic linker doesn't understand the TLS relocations present in the /libc64/libc.so.64 binary. If this sparc TLS support has been backported, this back has missed significant chunks of the necessary changes and now all 64-bit binaries fail to execute on the system. This is a known problem. It was _not_ backported; rather, binutils was updated to one which supported sparc64 TLS, and glibc's configury automatically started enabling it. An upload to fix this has been waiting on a pile of failures to build, also because of the new binutils. Sorry. I would suggest trying to execute a Hello World program, post-build, to avoid major errors like this. There is no way that any of the testsuite executed properly. Perhaps it was built successfully, but none of the programs linking against libc could have executed properly due to this bug. We run the testsuite. Sparc64 is a special case, however, because we can't assume that the buildd can run sparc64 binaries - in practice it can, of course, I'm sure we could do better than we do. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339415: FTBFS: Redefinitions of __divdi3, __moddi3, __udivdi32, and __umoddi3
reassign 339415 binutils
thanks
On Tue, Nov 15, 2005 at 10:32:54AM -0800, Matt Kraai wrote:
Package: glibc
Version: 2.3.5-8
Severity: serious
pbuilder fails to build glibc in an unstable chroot on i386:
gcc-4.0 ../sysdeps/wordsize-32/divdi3.c -c -std=gnu99 -O2 -Wall -Winline
-Wstrict-prototypes -Wwrite-strings -fstrict-aliasing -g -pipe
-mpreferred-stack-boundary=4 -fPIC-I../include -I.
-I/tmp/buildd/glibc-2.3.5/build-tree/i386-libc/csu -I.. -I../libio
-I/tmp/buildd/glibc-2.3.5/build-tree/i386-libc -I../sysdeps/i386/elf
-I../libidn/sysdeps/unix -I../linuxthreads/sysdeps/unix/sysv/linux/i386
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread
-I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv
-I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/i386
-I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux
-I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman
-I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv
-I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix
-I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386
-I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96
-I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32
-I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic
-nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.0.3/include -isystem
/tmp/buildd/glibc-2.3.5/debian/include -D_LIBC_REENTRANT -include
../include/libc-symbols.h -DPIC -DSHARED -DHAVE_INITFINI -o
/tmp/buildd/glibc-2.3.5/build-tree/i386-libc/csu/divdi3.os -MD -MP -MF
/tmp/buildd/glibc-2.3.5/build-tree/i386-libc/csu/divdi3.os.dt -MT
/tmp/buildd/glibc-2.3.5/build-tree/i386-libc/csu/divdi3.os
../sysdeps/wordsize-32/divdi3.c: In function '__moddi3':
../sysdeps/wordsize-32/divdi3.c:312: warning: pointer targets in passing
argument 3 of '__udivmoddi4' differ in signedness
{standard input}: Assembler messages:
{standard input}:416: Error: symbol `__divdi3' is already defined
{standard input}:504: Error: symbol `__moddi3' is already defined
{standard input}:608: Error: symbol `__udivdi3' is already defined
{standard input}:642: Error: symbol `__umoddi3' is already defined
This bug was both worked around in the glibc CVS and fixed in binutils.
It was only present in binutils HEAD for a week or two.
--
Daniel Jacobowitz
CodeSourcery, LLC
Bug#339415: Processed: Re: Bug#339415: FTBFS: Redefinitions of __divdi3, __moddi3, __udivdi32, and __umoddi3
On Sun, Nov 20, 2005 at 07:17:40PM +, James Troup wrote: reassign 339415 glibc thanks Daniel Jacobowitz [EMAIL PROTECTED] writes: This bug was both worked around in the glibc CVS and fixed in binutils. It was only present in binutils HEAD for a week or two. [AFAIK (and based in no small part on the conversation I had with you?)] We already have a new enough binutils to fix this; it's glibc which needs patched now. In that case this bug can probably be closed. Matt filed the original report on 2005-11-15, and you uploaded a package with the fix two days later :-) Jeff's ubuntu-new-binutils patch is for that same issue, but shouldn't be necessary with the fixed binutils, unless I've totally misunderstood. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335821: glibc: ftbfs [sparc] tls-macros.h:735:3: error: #error No support for this architecture so far.
On Sat, Nov 12, 2005 at 06:26:13PM +0100, Aurelien Jarno wrote: Hi, Please find attached a dpatch file to fix this bug. The code is taken from upstream CVS. I still don't see why previous version of the glibc were built successfully, the tls support was probably broken for them. I worked out before why this used to work, but I foolishly didn't write it down. It was complicated and took me a couple hours to work out :-) Ah, yes: * Merge makefile patch from Goswin Brederlow [EMAIL PROTECTED] to fail earlier if builds fail (but omit the bit for make -k check) (Closes: #325460). I believe we just failed to detect the error. Which didn't matter since this header is included only in testcases. I'm committing your patch to SVN. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336317: initramfs-tools: MD doesn't get started
Package: initramfs-tools Version: 0.37 Followup-For: Bug #336317 I'm encountering the same problem, I think. I've got LVM running on top of RAID-1. When I get dropped to a busybox prompt, USB isn't loaded yet (could we do this _before_ messing with the root FS, please?) so I can't poke around. But it looks like dm-mod was loaded and none of the md bits were. So I would guess that something is wrong with the prereqs mechanism... maybe. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-rc5 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages initramfs-tools depends on: ii busybox 1:1.01-3 Tiny utilities for small and embed ii cpio 2.6-8 GNU cpio -- a program to manage ar ii klibc-utils 1.1.1-2small statically-linked utilities ii mklibs-copy 0.1.18 Shared library reduction script ii udev 0.071-1/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336577: linux-kernel-headers: linux/sem.h broken on mips, mipsel
On Mon, Oct 31, 2005 at 10:45:55AM +0100, Matej Vela wrote: Package: linux-kernel-headers Version: 2.6.13+0rc3-2 Severity: serious Justification: causes an FTBFS for dctc and dcgui Including linux/sem.h results in the following error on mips and mipsel: casals.debian.org$ echo '#include linux/sem.h' | cpp /dev/null In file included from /usr/include/asm/atomic.h:26, from /usr/include/linux/sem.h:5, from stdin:1: /usr/include/asm/cpu-features.h:15:35: error: cpu-feature-overrides.h: No such file or directory Why are you using this header from userspace? In general it's the wrong choice. The only advantage over the userspace header is that it provides union semun; but POSIX is quite clear that it is the application's responsibility to provide that type. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336577: linux-kernel-headers: linux/sem.h broken on mips, mipsel
On Mon, Oct 31, 2005 at 05:51:45PM +0100, Matej Vela wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: On Mon, Oct 31, 2005 at 10:45:55AM +0100, Matej Vela wrote: Including linux/sem.h results in the following error on mips and mipsel: [...] Why are you using this header from userspace? In general it's the wrong choice. The only advantage over the userspace header is that it provides union semun; but POSIX is quite clear that it is the application's responsibility to provide that type. For SEMVMX. And you're right, sysconf(_SC_SEM_VALUE_MAX) would be a better choice, but it isn't implemented... Another solution would be to call semctl(..., SEM_INFO, arg) and use arg.__buf-semvmx, but that seemed unportable and inelegant (given that, as you note, the caller must also define union semun). If the fix is non-trivial, feel free to downgrade this to wishlist, and I'll change dctc and dcgui to use _POSIX_SEM_VALUE_MAX. In general, most of these headers are not intended or supported for userspace use; so the correct thing to do is either to use the POSIX equivalents, or else to copy the bits you need from some particular version of the kernel headers. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335821: glibc: ftbfs [sparc] tls-macros.h:735:3: error: #error No support for this architecture so far.
On Tue, Oct 25, 2005 at 07:09:00PM -0700, Blars Blarson wrote: Package: glibc Version: 2.3.5-7 Severity: serious Justification: no longer builds from source glibc failed to build on a sparc buildd, duplicated on my sparc pbuilder. Yes... I have not quite figured out why this did not happen in the past, but it's pretty obvious why it happens now. We need to add sparc64 support to tls-macros.h and then it seems likely that will be enough to fix it. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334709: libc6 2.3.5-7: FTBFS on i386 - forced unwind support is required
On Wed, Oct 19, 2005 at 01:55:14PM +0200, Henry Jensen wrote: Package: libc6 Version: 2.3.5-7 Severity: serious The build of libc6 on i386 in a fresh sid chroot fails. I build the packages with nice -19 dpkg-buildpackage -rfakeroot -uc -us The build fails with the following error: Binutils bug, temporary. Install amd64-libs to work around the problem or add /lib64 and /usr/lib64 to your ld.so.conf. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334603: Linking problem with amd64 port (not able to run 32bit SW, not finding /lib/ld-linux.so.2)
On Wed, Oct 19, 2005 at 01:51:19AM +0200, Klaus Ethgen wrote: Package: libc6 Version: 2.3.5-6 Severity: critical Tags: testing I just updated from AMD64 port of sarge to AMD64 port of etch. Now no 32bit application can be stared anymore. ldd gives the following error: /usr/bin/ldd: line 171: /lib/ld-linux.so.2: Datei oder Verzeichnis nicht gefunden ldd: /lib/ld-linux.so.2 exited with unknown exit code (127) Maybe this is a result of the patch noticed in 325226 but I'm not sure. In fact ther is no ld-linux.so.2. libc6 doesn't provide 32 bit libraries on amd64 (yet). Do you have ia32-libs installed? Maybe your upgrade removed it. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 10:28:27PM +, Joel Soete wrote: Aurelien Jarno wrote: [...] Oh yes, BTW, I have seen that glibc does not built anymore on hppa. It seems the new binutils does not accept some assembly instructions. Currently I am doing my tests with binutils 2.16.1. It has to be fixed before uploading a new glibc, but unfortunately I don't speak hppa assembly. Is there some build log somewhere (I have a look at http://buildd.debian.org/build.php?arch=hppapkg=glibc) but nothing newer then 2.3.5-6 :? Don't worry about this - I've already checked in a fix to SVN this morning. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321621: gcc biarch builds fails on i386
On Thu, Aug 11, 2005 at 09:53:06AM +0200, Andreas Jochens wrote: The attached patch to glibc-2.3.5-3 works for me. I'm taking a look at this, but I don't think it's enough: unlike some other platforms, you can't use the i386 headers to build 64-bit programs. You need to either install both sets of headers, or just the 64-bit headers. I'll give this a shot and see what I come up with... -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 12:20:50AM +0200, Aurelien Jarno wrote: - gcc-4.0 generates wrong code For that see my attached file. It's the file from the glibc, with the code from Steve pasted at the end. It works with gcc-3.4, but fails with gcc-4.0. I don't think that's what is happening at all: I think that in one of these cases, your test file's on-stack fenv_t is aligned, and on the other it isn't. The code you posted for gcc 4.0 looks fine. I think the assembly is broken or the definition of fenv_t. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 08:40:20AM +0800, Randolph Chung wrote: I don't think that's what is happening at all: I think that in one of these cases, your test file's on-stack fenv_t is aligned, and on the other it isn't. The code you posted for gcc 4.0 looks fine. I think the assembly is broken or the definition of fenv_t. drow is right, as usual. our fenv_t needs to be defined with __attribute__((aligned(8))) or similar. I'd recommend fixing the asm instead: that's an ABI change and would require heinous rebuilds. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332795: locales: post-install fails with *** glibc detected *** double free or corruption (!prev): 0x088e9208 ***
On Sat, Oct 08, 2005 at 07:21:32PM +0200, Attila Kinali wrote: Package: locales Version: 2.3.5-6 Severity: grave Justification: renders package unusable when updating locales to version 2.3.5-6 it failes after generating the locales: --- jashugan:/home/attila# apt-get install locales Reading Package Lists... Done Building Dependency Tree... Done locales is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 317 not upgraded. 1 not fully installed or removed. Need to get 0B of archives. After unpacking 0B of additional disk space will be used. Setting up locales (2.3.5-6) ... Generating locales (this might take a while)... de_DE.ISO-8859-1... done Generation complete. *** glibc detected *** double free or corruption (!prev): 0x088e9208 *** dpkg: error processing locales (--configure): subprocess post-installation script killed by signal (Aborted), core dumped Errors were encountered while processing: locales E: Sub-process /usr/bin/dpkg returned an error code (1) --- I tried other locales and it does seem to be unrelated. As i have no idea what the error means i could not really debug it, if you need more informations please tell me how to aquire them. Can you still reproduce this? If so, it says that bash dumped core; the core dump should be lying around somewhere. That might help. I've tried to reproduce this but could not. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332795: locales: post-install fails with *** glibc detected *** double free or corruption (!prev): 0x088e9208 ***
On Thu, Oct 13, 2005 at 10:57:36PM -0400, Daniel Jacobowitz wrote: On Sat, Oct 08, 2005 at 07:21:32PM +0200, Attila Kinali wrote: *** glibc detected *** double free or corruption (!prev): 0x088e9208 *** Can you still reproduce this? If so, it says that bash dumped core; the core dump should be lying around somewhere. That might help. I've tried to reproduce this but could not. Actually, this is probably the same as #326856. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 09:17:21PM -0600, Grant Grundler wrote: On Thu, Oct 13, 2005 at 08:54:30PM -0400, Daniel Jacobowitz wrote: drow is right, as usual. our fenv_t needs to be defined with __attribute__((aligned(8))) or similar. I'd recommend fixing the asm instead: that's an ABI change and would require heinous rebuilds. Sorry - I'm not following. The Application *Binary* Interface was providing 8 byte alignment with gcc 3.4, right? Why is it breaking the ABI if we tell gcc 4.0 to do the same? No, the _type_ fenv_t is documented to have 4 byte alignment. In both. In 3.4 you got lucky and it was usually placed at 8. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 05:59:33AM +0200, Aurelien Jarno wrote: Ok, that's mean that theoretically it would break the ABI, but practically, it does not break the ABI as the alignment is the same (otherwise we would also have noticed SIGBUS in other applications). Said in other words, applications with 4-byte aligned fenv_t variables are not working (SIGBUS), so it won't hurt to break the ABI in that case, as the applications have to be rebuilt anyway to fix the problem. Whichever you like then. I would appreciate it if someone could come up with a patch for one or the other, or at least an authoritative statement and I'll sort the code out in the morning; I have the next glibc upload otherwise ready. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Fri, Oct 14, 2005 at 05:59:33AM +0200, Aurelien Jarno wrote: Ok, that's mean that theoretically it would break the ABI, but practically, it does not break the ABI as the alignment is the same (otherwise we would also have noticed SIGBUS in other applications). Just to clarify: if you fix the inline asm in glibc, then you don't need to recompile any of the currently broken libraries or applications. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 08:54:30PM -0400, Daniel Jacobowitz wrote: On Fri, Oct 14, 2005 at 08:40:20AM +0800, Randolph Chung wrote: I don't think that's what is happening at all: I think that in one of these cases, your test file's on-stack fenv_t is aligned, and on the other it isn't. The code you posted for gcc 4.0 looks fine. I think the assembly is broken or the definition of fenv_t. drow is right, as usual. our fenv_t needs to be defined with __attribute__((aligned(8))) or similar. I'd recommend fixing the asm instead: that's an ABI change and would require heinous rebuilds. After talking to Carlos, I'm going to take care of this in the morning and aim for an upload tomorrow. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318590: editing library's soname (was Re: Fixed in upload of curl 7.14.1-1 to experimental)
On Sat, Sep 24, 2005 at 04:52:31PM +0200, Domenico Andreoli wrote: yes, i'm aware of this. it is due to the libcurl-gnutls.so.3 soname still being libcurl.so.3. everything else is in place for a good upload. as of today, i've not found a solution different from patching the makefiles. i'd like a tool to modify this kind of things in the elf, probably elfsh is what i'm looking for. something to run after the build process. any idea? In general you can't do this unless you're replacing it with a shorter soname. I highly recommend fixing the build system instead. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328483: Debian binutils dependency policy
I have no idea why you've copied this to the binutils upstream list, debian-devel, et cetera... On Tue, Sep 20, 2005 at 10:09:03AM -0400, Camm Maguire wrote: Greetings! Do we have a plan or policy regarding packages which need to depend on binutils-dev? Is there now or will there ever be in the future a stable binary api, by which I mean one that might be good for a year or more of development on average? In such a case, would binary api compatibility be guaranteed by the soname of the shared library as with other libs? Could Debian consider maintaining old and new shared lib versions to ease transitions, as with other libraries? No way. dpkg -s binutils-dev: Description: The GNU binary utilities (BFD development files) This package includes header files and static libraries necessary to build programs which use the GNU BFD library, which is part of binutils. Note that building Debian packages which depend on the shared libbfd is Not Allowed. The same thing applies to any other form of dependency on the binutils shared libraries. If the answer to the first question is no, then the only sensible policy would appear to be that everyone fork and locally maintain their own binutils snapshot for static linking. This appears terribly inefficient from a system design point of view. On the other hand, forcing a rebuild of gcl,maxima,acl2 and axiom on all platforms because of a binutils change which might in fact be completely innocuous is untenable as well. Use binutils-dev, link to libbfd.a? The source API changes relatively rarely, it probably won't bite you. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328483: Debian binutils dependency policy
On Tue, Sep 20, 2005 at 11:42:06AM -0400, Camm Maguire wrote: OK, but this is a pity. I still don't understand why this need be the case. Because the interface between BFD and binutils is subject to change and does on a regular basis, and there are not enough users to bother doing anything more complicated. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321712: Bug#323032: libc6: GLIBC_PRIVATE errors
On Sun, Aug 14, 2005 at 03:47:22AM -0700, Steve Langasek wrote: fakeroot debian/rules binary /usr/bin/make: relocation error: /lib/libdl.so.2: symbol _dl_catch_error, version GLIBC_PRIVATE not defined in file ld.so.1 with link time reference zsh: 8307 exit 127 fakeroot debian/rules binary However, $ dpkg -x g/glibc/libc6_2.3.5-3_powerpc.deb /tmp/libc6 $ nm -Du /tmp/libc6/lib/libdl.so.2 |grep _dl_catch_error $ I can't find any evidence of this bug you're describing in glibc 2.3.5-3. It was in 2.3.2, however; I suspect that Simon has somehow managed to get the old libdl with the new ld.so. Probably there is a stray copy in /usr or some directory in /etc/ld.so.conf. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321621: gcc biarch builds fails on i386
On Tue, Aug 09, 2005 at 07:50:38PM +0200, Andreas Jochens wrote: On 05-Aug-06 15:41, Matthias Klose wrote: Package: amd64-libs-dev Severity: serious after upgrading to glibc-2.3.5, the gcc-4.0 biarch build fails: Hello, I would suggest to drop the current Build-Depends of gcc-4.0 on 'amd64-libs-dev' entirely and instead use a 'libc6-i386-dev' package which could be built by glibc. This would be similar to the other architectures with a biarch toolchain which already use this kind of setup (sparc/sparc64, s390/s390x and powerpc/ppc64). Yes, we've already planned to do this. We were waiting for glibc 2.3.5 and gcc 4.0 to enter unstable, first. I could provide a patch to make 'glibc' build the necessary 'libc6-i386' and 'libc6-dev-i386' packages if this approach is welcome. If you have one handy, I won't complain... I will need to do some work on a transitional amd64-libs-dev package to remove diversions, et cetera. I need to think about how to do that. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317861: conflicting definitions of P_ALL, P_PID, and P_PGID
On Thu, Jul 14, 2005 at 09:31:24PM -0700, Matt Kraai wrote: On Thu, Jul 14, 2005 at 02:42:23PM -0400, Daniel Jacobowitz wrote: On Mon, Jul 11, 2005 at 09:47:11AM -0700, Matt Kraai wrote: Package: libc6-dev Version: 2.3.2.ds1-22 Severity: serious kbd-chooser fails to build because the definitions of P_ALL, P_PID, and P_PGID in /usr/include/sys/wait.h conflict with those in /usr/include/linux/wait.h: cc -c -Wall -I. -DNDEBUG=1 -fomit-frame-pointer -Os -DAT_KBD -DUSB_KBD loadkeys.c In file included from /usr/include/debian-installer/exec.h:29, from /usr/include/debian-installer.h:5, from loadkeys.y:24: /usr/include/sys/wait.h:100: error: syntax error before numeric constant loadkeys.y: In function 'addfunc': loadkeys.y:595: warning: comparison is always false due to limited range of data type make[1]: *** [loadkeys.o] Error 1 make[1]: Leaving directory `/tmp/buildd/kbd-chooser-1.15' make: *** [build-stamp] Error 2 Where is linux/wait.h being included from? Is it necessary? loadkeys.y includes linux/keyboard.h, which includes linux/wait.h. loadkeys.y does use some of the macros defined in linux/keyboard.h, so it seems like it should include it. linux/keyboard.h does not appear to use anything from linux/wait.h, though, so I'm not sure why it includes it. linux/keyboard.h is definitely one of the headers I would recommend not including. The network headers are generally safe, but that's about it. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317861: conflicting definitions of P_ALL, P_PID, and P_PGID
On Fri, Jul 15, 2005 at 08:37:20AM -0700, Matt Kraai wrote: loadkeys.y should inline the macro definitions that it needs from linux/keyboard.h instead of removing the include from linux/keyboard.h? loadkeys.y appears to use the following macros: Yes, in general this is correct. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317861: conflicting definitions of P_ALL, P_PID, and P_PGID
On Mon, Jul 11, 2005 at 09:47:11AM -0700, Matt Kraai wrote: Package: libc6-dev Version: 2.3.2.ds1-22 Severity: serious kbd-chooser fails to build because the definitions of P_ALL, P_PID, and P_PGID in /usr/include/sys/wait.h conflict with those in /usr/include/linux/wait.h: cc -c -Wall -I. -DNDEBUG=1 -fomit-frame-pointer -Os -DAT_KBD -DUSB_KBD loadkeys.c In file included from /usr/include/debian-installer/exec.h:29, from /usr/include/debian-installer.h:5, from loadkeys.y:24: /usr/include/sys/wait.h:100: error: syntax error before numeric constant loadkeys.y: In function 'addfunc': loadkeys.y:595: warning: comparison is always false due to limited range of data type make[1]: *** [loadkeys.o] Error 1 make[1]: Leaving directory `/tmp/buildd/kbd-chooser-1.15' make: *** [build-stamp] Error 2 Where is linux/wait.h being included from? Is it necessary? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317501: amd64-libs-dev conflicts with linux-kernel-headers
On Sat, Jul 09, 2005 at 09:29:33AM +0200, Matthias Klose wrote: Package: amd64-libs-dev Version: 1.1 Severity: grave Conflicts against linux-kernel-headers_2.6.12.0-1, the biarch build for gcc-3.4 and gcc-4.0 on i386 have to be disabled, therefore severity grave. This package was meant to be transitional, anyway. In your opinion, should we fix it, or should we remove it and make the affected library packages build biarch on i386? I believe that's just glibc, ncurses, and libbz2 (plus linux-kernel-headers). Ncurses and glibc already support biarch builds. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316093: ressource files should not be in etc
On Sun, Jul 03, 2005 at 12:59:25PM +0200, Eduard Bloch wrote: #include hallo.h * Thomas Dickey [Sun, Jul 03 2005, 06:53:55AM]: I think Bill has a good point here. Ressource files like compiled terminal descriptions should not be in etc since hardly anyone edits them. Instead, they should be moved to /usr/share and links from them to /etc/terminfo/... should be created, so the local admin still has a chance to modify the files, and on the other hands the packages can work without worrying about conffiles issues. You aren't supposed to put links from /etc to things, was my understanding. It's supposed to be the other way around... my understanding is that they're in /etc since they're used during startup when /usr/share is not mounted. Good point, things like editors maybe essential in an environment where /usr cannot be mounted. What about /lib/terminfo instead? That can't be right! There's a reason that the ncurses-term components /live in usr/share, not /usr/lib. If I put them in /lib someone else will file a bug report about that. The closest we have to /share is, historically, /etc. That said I don't think the library even searches in /etc/terminfo today. That's why ncurses-base includes symlinks from /usr/share/terminfo to /etc for the essential terminfo descriptions. But it would be nice if it did and ncurses nowadays has a configure option to search multiple directories. So I plan to make a future upload do this. Ideally I could ship /etc/terminfo empty, have tic default to write there, ship terminfo descriptions somewhere on /, and ncurses-term continues to live in /usr/share. Is there anything more appropriate then /lib? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316093: ncurses-base: binaries terminfo files marked as conffiles
On Tue, Jun 28, 2005 at 01:51:46PM +0200, Bill Allombert wrote: However theses files are binaries files, not text files. They probably do not beong in /etc in the first place but at least they should not be marked as conffiles, since dpkg do not handle non-text conffiles in a useful way: Setting up ncurses-base (5.4-8) ... Configuration file `/etc/terminfo/r/rxvt-unicode' == File on system created by you or by a script. == File also in package provided by package maintainer. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : background this process to examine the situation The default action is to keep your current version. *** rxvt-unicode (Y/I/N/O/D/Z) [default=N] ? D Binary files /etc/terminfo/r/rxvt-unicode and /etc/terminfo/r/rxvt-unicode.dpkg-new differ But they ARE conffiles! One of the reasons they're in /etc is so that the system administrator can modify them if desired. I'm sorry dpkg doesn't offer a way to specify a diff program usefully; infocmp would work fine. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316093: ncurses-base: binaries terminfo files marked as conffiles
On Tue, Jun 28, 2005 at 03:32:42PM +0200, Bill Allombert wrote: On Tue, Jun 28, 2005 at 09:01:21AM -0400, Daniel Jacobowitz wrote: But they ARE conffiles! One of the reasons they're in /etc is so that the system administrator can modify them if desired. No, they are maybe config files, but they cannot be conffiles, since they are not text files. Do you have a reference for this? I see nothing in policy to suggest that conffiles must be text files. Other than the inflexibility of using diff, the conffile management in dpkg is appropriate. I'm sorry dpkg doesn't offer a way to specify a diff program usefully; infocmp would work fine. That is why you should not mark them as conffiles but handle them manually with a script that provide a way to edit and diff them. You don't edit them. You build from alternate source, presumably provided by whatever oddball terminal you're using or derived by some overly clever sysadmin from terminfo.src. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316093: ncurses-base: binaries terminfo files marked as conffiles
On Wed, Jun 29, 2005 at 01:40:42AM +0200, Bill Allombert wrote: On Tue, Jun 28, 2005 at 07:26:25PM -0400, Daniel Jacobowitz wrote: On Tue, Jun 28, 2005 at 03:32:42PM +0200, Bill Allombert wrote: On Tue, Jun 28, 2005 at 09:01:21AM -0400, Daniel Jacobowitz wrote: But they ARE conffiles! One of the reasons they're in /etc is so that the system administrator can modify them if desired. No, they are maybe config files, but they cannot be conffiles, since they are not text files. Do you have a reference for this? I see nothing in policy to suggest that conffiles must be text files. Other than the inflexibility of using diff, the conffile management in dpkg is appropriate. Please see: http://release.debian.org/etch_rc_policy.txt 3. Configuration files Conffiles must be plain text. I am really sorry to have to resort to that, though. You're not resorting to anything. I only asked you for a reference, and I will go investigate the history and intent behind this apparent change. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315405: ncurses-term: share the same file with ncurses-base
On Thu, Jun 23, 2005 at 03:30:15PM +0200, Jörg Sommer wrote: $ for i in ncurses-base_5.4-7_all.deb ncurses-term_5.4-7_all.deb; do \ dpkg --contents $i; done |grep unic lrwxrwxrwx root/root 0 2005-06-20 04:18:44 ./usr/share/terminfo/r/rxvt-unicode - /etc/terminfo/r/rxvt-unicode -rw-r--r-- root/root 2165 2005-06-20 04:18:16 ./usr/share/terminfo/r/rxvt-unicode Got it... it's the funny Replaces ordering. Will fix soon. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315405: ncurses-term: share the same file with ncurses-base
On Wed, Jun 22, 2005 at 11:35:01AM +0200, Jörg Sommer wrote: Package: ncurses-term Version: 5.4-7 Severity: serious Hi, # LANG=C dpkg -S /usr/share/terminfo/r/rxvt-unicode diversion by ncurses-term from: /usr/share/terminfo/r/rxvt-unicode diversion by ncurses-term to: /usr/share/terminfo/r/rxvt-unicode.distrib ncurses-base, ncurses-term: /usr/share/terminfo/r/rxvt-unicode I solved it local with diversions, but it's a bug in the package. [EMAIL PROTECTED]:~% dpkg -l ncurses-term Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii ncurses-term 5.4-7Additional terminal type definitions [EMAIL PROTECTED]:~% dpkg -L ncurses-term|grep rxvt-uni Can you check the deb? Where does this come from? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315463: ncurses: ftbfs [sparc] error: Cannot link with GPM library
On Wed, Jun 22, 2005 at 01:25:14PM -0700, Blars Blarson wrote: Package: ncurses Version: 5.4-7 Severity: serious Tags: sid Justification: fails to build from source ncurses fails to build from source on a sparc pbuilder: checking if you want to link with dmalloc for testing... no checking if you want to link with the GPM mouse library... yes checking for Gpm_Open in -lgpm... no configure: error: Cannot link with GPM library make: *** [/build/buildd/ncurses-5.4/obj-64/config.status] Error 1 Bugger all. This means we have to disable gpm for the 64-bit builds, this will affect s390x also. I will do this next weekend or the following week; I'm travelling and away from my keys. It fails with a different error on my sparc pbuilder: Configuring NCURSES 5.4 ABI 5 (Wed Jun 22 18:15:11 UTC 2005) checking build system type... sparc-unknown-linux-gnu checking host system type... sparc64-unknown-linux-gnu checking target system type... sparc64-unknown-linux-gnu Configuring for linux-gnu checking for prefix... /usr checking for sparc64-linux-gnu-gcc... gcc -m64 checking for C compiler default output... configure: error: C compiler cannot create executables make: *** [/tmp/buildd/ncurses-5.4/obj-64/config.status] Error 77 Last time I suggested this was a problem with your pbuilder. I still think that's likely to be true. What package is missing for gcc -m64 to work? -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314448: ncurses: ftbfs [sparc] nc_panel.h: No such file or directory
On Thu, Jun 16, 2005 at 03:44:06AM -0700, Blars Blarson wrote: Package: ncurses Version: 5.4-6 Severity: serious Tags: sid Justification: fails to build from source ncurses fails to build from source a sparc buildd: gcc -DHAVE_CONFIG_H -I../ncurses -I/build/buildd/ncurses-5.4/ncurses -I/build/buildd/ncurses-5.4/ncurses/../include -I. -I../include -D_GNU_SOURCE -DNDEBUG -DCPP_HAS_STATIC_CAST -O2 -g -D_REENTRANT -c /build/buildd/ncurses-5.4/ncurses/widechar/lib_wunctrl.c -o ../objects/lib_wunctrl.o In file included from /build/buildd/ncurses-5.4/ncurses/widechar/lib_wunctrl.c:36: /build/buildd/ncurses-5.4/ncurses/curses.priv.h:100:22: nc_panel.h: No such file or directory /build/buildd/ncurses-5.4/ncurses/curses.priv.h:253:24: term_entry.h: No such file or directory In file included from /build/buildd/ncurses-5.4/ncurses/widechar/lib_wunctrl.c:36: /build/buildd/ncurses-5.4/ncurses/curses.priv.h:525: error: field `_panelHook' has incomplete type /build/buildd/ncurses-5.4/ncurses/curses.priv.h:801:22: nc_alloc.h: No such file or directory In file included from /build/buildd/ncurses-5.4/ncurses/widechar/lib_wunctrl.c:36: /build/buildd/ncurses-5.4/ncurses/curses.priv.h:1095: error: syntax error before '*' token /build/buildd/ncurses-5.4/ncurses/curses.priv.h:1095: error: syntax error before '*' token /build/buildd/ncurses-5.4/ncurses/curses.priv.h:1095: warning: data definition has no type or storage class /build/buildd/ncurses-5.4/ncurses/curses.priv.h:: error: syntax error before '*' token make[2]: *** [../objects/lib_wunctrl.o] Error 1 make[2]: Leaving directory `/build/buildd/ncurses-5.4/obj-wide/ncurses' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/ncurses-5.4/obj-wide' make: *** [build-wide] Error 2 Are you sure that the build directory was not removed during this build? I can't imagine how that error could happen. A different problem occurs on my sparc pbuilder: mv debian/tmp/usr/lib/libncursesw.so.5 debian/tmp/lib/ dh_movefiles -s dh_movefiles: debian/tmp/usr/lib64/libncurses.so not found (supposed to put it in lib64ncurses5-dev) dh_movefiles: debian/tmp/usr/lib64/libform.so not found (supposed to put it in lib64ncurses5-dev) dh_movefiles: debian/tmp/usr/lib64/libmenu.so not found (supposed to put it in lib64ncurses5-dev) dh_movefiles: debian/tmp/usr/lib64/libpanel.so not found (supposed to put it in lib64ncurses5-dev) dh_movefiles: debian/tmp/usr/lib64/libncurses.a not found (supposed to put it in lib64ncurses5-dev) dh_movefiles: debian/tmp/usr/lib64/libncurses++.a not found (supposed to put it in lib64ncurses5-dev) dh_movefiles: debian/tmp/usr/lib64/libform.a not found (supposed to put it in lib64ncurses5-dev) dh_movefiles: debian/tmp/usr/lib64/libmenu.a not found (supposed to put it in lib64ncurses5-dev) dh_movefiles: debian/tmp/usr/lib64/libpanel.a not found (supposed to put it in lib64ncurses5-dev) tar: /tmp/buildd/ncurses-5.4/debian/movelist: Cannot open: No such file or directory tar: Error is not recoverable: exiting now sh: /tmp/buildd/ncurses-5.4/debian/movelist: No such file or directory This works on the buildd; maybe there are missing packages? Or an unstated dependency on a 64-bit kernel, have you got a 32-bit system? Ben Collins wrote the lib64 support. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314448: ncurses: ftbfs [sparc] nc_panel.h: No such file or directory
On Thu, Jun 16, 2005 at 10:01:55AM -0700, Blars Blarson wrote: A different problem occurs on my sparc pbuilder: This works on the buildd; maybe there are missing packages? Or an unstated dependency on a 64-bit kernel, have you got a 32-bit system? Ben Collins wrote the lib64 support. This is a pbuilder running on a dual-processor ultra 2. (2.6.8-2-sparc64-smp kernel from testing.) The build dependancies as specified by the package were satasfied, but may not be identical versions to those used by the buildd. Is the entire log available? Your bug only showed me that the 64-bit packages were not built. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314448: ncurses: ftbfs [sparc] nc_panel.h: No such file or directory
On Thu, Jun 16, 2005 at 11:38:38AM -0700, Blars Blarson wrote: On Thu, Jun 16, 2005 at 01:23:51PM -0400, Daniel Jacobowitz wrote: Is the entire log available? Your bug only showed me that the 64-bit packages were not built. Attached. dpkg-architecture -qDEB_HOST_GNU_TYPE changed in the latest dpkg update. Grr. Will robustify. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310972: gdb: [CAN-2005-1704] [CAN-2005-1705] Integer overflow and privilege escalation
On Fri, May 27, 2005 at 01:29:17PM +0200, Martin Pitt wrote: Package: gdb Version: 6.3-5 Severity: grave Tags: security patch Justification: user security hole Hi! gdb is vulnerable against two flaws. Please see https://www.ubuntulinux.org/support/documentation/usn/usn-135-1 for details and http://patches.ubuntu.com/patches/gdb.CAN-2005-1704_1705.diff for the Ubuntu patch. This patch fixes not only the integer overflow, but also adds some robustness checking to not crash on various types of crafted ELF files. FYI, you have included two changes to elf.c which were not included in the upstream source. Neither appears to be necessary, and certainly neither is a security fix - both are NULL checks immediately preceeding dereferences. Otherwise the BFD patch looks generally fine. The .gdbinit portion needs to be discussed by the GDB maintainers before it can be included upstream, though there will probably not be a problem. But that bit is fine for Debian's purposes. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308624: Patch for security bug in gdb
On Sat, May 21, 2005 at 12:48:12AM +0200, Matthijs Mohlmann wrote: Hi, Attached to this mail a patch which fixes a security problem in gdb. I tested the patch and it works. Patch comes from the current snapshot of gdb, I backported it. Bug #308624 There are at least two other patches in CVS; they should all be brought in together. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309486: libc6 upgrade failed leaving system unusable
On Wed, May 18, 2005 at 10:51:09AM +1000, Hamish Moffatt wrote: On Wed, May 18, 2005 at 10:42:08AM +1000, Hamish Moffatt wrote: On Tue, May 17, 2005 at 11:34:58AM -0400, Daniel Jacobowitz wrote: If you dare, could you try to reproduce the problem? I can try that, as the system isn't too critical. Installing the -22 deb now works. Should I install -21 and then -22 again? That worked. Do you mean worked OK or successfully reproduced the problem? If it worked OK, let's close this; there's nothing we can do about it. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
