Bug#292673: additional info

2005-04-08 Thread David Mosberger
> On Fri, 08 Apr 2005 18:38:05 +0900, GOTO Masanori <[EMAIL PROTECTED]> > said: GOTO> OK, I pulled the Jakub's patch and built it. I put it at: GOTO> GOTO> http://www.gotom.jp/~gotom/debian/glibc/2.3.2.ds1-21_ia64.linuxthreads GOTO> David, could you test this glibc on your ia64

Bug#297769: patch

2005-04-08 Thread David Mosberger
> On Fri, 08 Apr 2005 15:32:29 +0900, GOTO Masanori <[EMAIL PROTECTED]> > said: GOTO> I fear to change this interface until sarge release because there GOTO> might be another packages that uses sched_setaffinity. Well, yes, schedutils probably would need updating. I don't know of an

Bug#297769: glibc: sched_setaffinity() provides obsolete interface

2005-03-02 Thread David Mosberger
Package: glibc Severity: grave Justification: renders package unusable The current Sarge glibc still provides the obsolete 2-argument interface for sched_setaffinity(). As more software is starting to use this system call, this is becoming a real issue because developers will have to create a sp

Bug#292673: additional info

2005-03-01 Thread David Mosberger
> On Mon, 28 Feb 2005 09:32:20 +0900, GOTO Masanori <[EMAIL PROTECTED]> > said: GOTO> David, does this problem only occurs on ia64? Or i686? To be honest, GOTO> I have concerned this kind of problem - the incompatibility between GOTO> nptl and linuxthreads. As indicated in my bug

Bug#292673: additional info

2005-02-24 Thread David Mosberger
While there hasn't been any discussion for glibc bugzilla report #685 [1], private communication with one of the glibc maintainers indicates that this issue is not considered to be a glibc bug because, officially, glibc supports only one thread library at a time: LinuxThreads _or_ NPTL, but not bot

Bug#284563: status of libunwind patches for ia64

2004-12-15 Thread David Mosberger
>>>>> On Wed, 15 Dec 2004 13:55:45 -0800, David Mosberger <[EMAIL PROTECTED]> >>>>> said: David> I just checked and with the current packaging, I'm still David> getting failures during the libunwind build. After fixing these problems in li

Bug#284563: status of libunwind patches for ia64

2004-12-15 Thread David Mosberger
>>>>> On Tue, 14 Dec 2004 11:58:07 +0100, Matthias Klose <[EMAIL PROTECTED]> >>>>> said: Matthias> David Mosberger writes: >> >>>>> On Mon, 13 Dec 2004 20:47:41 +0100, Matthias Klose >> <[EMAIL PROTECTED]> sa

Bug#284563: status of libunwind patches for ia64

2004-12-13 Thread David Mosberger
> On Mon, 13 Dec 2004 20:47:41 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> please get the libgcc1 package from the unstable Matthias> distribution. I think I've got that one already (libgcc1 v3.4.3-2). Matthias> It's currently built by the gcc-3.4 sources and inclu

Bug#284563: status of libunwind patches for ia64

2004-12-13 Thread David Mosberger
Hi Matthias, > On Sun, 12 Dec 2004 17:55:57 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> with the patch attached and an updated gcc-3.3 package, Matthias> libunwind support for ia64 seems to work for me. I Matthias> couldn't install any of the built packages. I'd lik

Bug#284563: libunwind in unstable

2004-12-09 Thread David Mosberger
> On Thu, 9 Dec 2004 13:35:07 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> works ok until building glibc with the just built Matthias> compiler. _Unwind_Resume, _Unwind_GetRegionStart are Matthias> referenced by glibc objects, _Unwind_GetIP, _Unwind_SetGR, Matthias>

Bug#284563: libunwind in unstable

2004-12-09 Thread David Mosberger
> On Thu, 9 Dec 2004 12:49:38 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> ok, I'm currently bootstrapping gcc-3.3 with the patch Matthias> attached, a glibc bootstrap using this compiler did Matthias> succeed. I'll upload the fixed gcc-3.3, when bootstrap and Matth

Bug#284563: -19 FTBFS on ia64

2004-12-07 Thread David Mosberger
> On Tue, 7 Dec 2004 09:10:13 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> I assume the link line should read Matthias> -lunwind -lgcc -lgcc_eh Matthias> instead of Matthias> -lgcc -lgcc_eh I already submitted a patch for this (based on a patch by HJ Lu)

Re: libunwind in unstable

2004-11-23 Thread David Mosberger
> On Wed, 24 Nov 2004 00:26:01 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> From my point of view we can get around with it by Matthias> including the libunwind shared library in libgcc1 for the Matthias> sarge release. I'm worried about the version skew of the Matt

Re: libunwind in unstable

2004-11-23 Thread David Mosberger
> On Tue, 23 Nov 2004 09:27:52 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> Is the patch in #278836 a prerequisite for the above Matthias> changes, or can it be done without it? If the gas-patch isn't applied, you run the risk of getting wrong unwind-info into object-f

Re: TLS-version of libc6/{testing,unstable} breaks libunwind

2004-10-28 Thread David Mosberger
> On Thu, 28 Oct 2004 02:14:48 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: GOTO> We got security bug report; it may be chance to switch -19. Cool. I suddenly like security bugs... ;-) GOTO> I put no -fomit-frame-pointer .deb based on -18 at: GOTO> http://www.gotom.jp/~got

Re: TLS-version of libc6/{testing,unstable} breaks libunwind

2004-10-22 Thread David Mosberger
> On Fri, 22 Oct 2004 11:02:22 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: Goto> But I try to build with -fomit-frame-pointer. You mean _without_ -fomit-frame-pointer, right? Goto> If it's serious for some usages, please let me know. It's definitely serious. Any application that tri

Re: TLS-version of libc6/{testing,unstable} breaks libunwind

2004-10-21 Thread David Mosberger
work. Is it possible to fix this before Debian 3.1 is released? It would be very nice, since otherwise, backtraces are hopelessly broken. Thanks, --david >>>>> On Fri, 10 Sep 2004 12:21:04 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: Goto> At Fri, 20 Aug 20

Re: TLS-version of libc6/{testing,unstable} breaks libunwind

2004-09-13 Thread David Mosberger
> On Fri, 10 Sep 2004 12:21:04 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: GOTO> I think it's good idea to drop -fomit-frame-pointer from GOTO> linux.mk for building libc with NPTL. If such optimization GOTO> option is fine for specific architecture, it should be defined GOTO> -fom

Re: TLS-version of libc6/{testing,unstable} breaks libunwind

2004-08-20 Thread David Mosberger
>>>>> On Fri, 20 Aug 2004 12:51:03 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: GOTO> Hi David, At Thu, 19 Aug 2004 04:36:59 -0700, David Mosberger GOTO> wrote: >> I recently noticed that with Debian/testing or Debian/unstable, >> many libunwind

TLS-version of libc6/{testing,unstable} breaks libunwind

2004-08-19 Thread David Mosberger
Hi, I recently noticed that with Debian/testing or Debian/unstable, many libunwind [1] checks are failing with a SEGFAULT. The root-cause of these crashes appears to be that the TLS-version of libc-2.3.2 is built with -fomit-frame-pointer on i386 (see nptl_extra_cflags in debian/sysdeps/i386.mk o

Bug#225466: libc6.1: thread-creation fails after setting non-page-aligned stack limit

2003-12-29 Thread David Mosberger
Package: libc6.1 Version: 2.3.2.ds1-10.0.1 Severity: normal Tags: sid patch I noticed that I can no longer load a directory via dired. The root-cause of the problem appears to be that Emacs uses setrlimit() to set RLIMIT_STACK. This limit won't be page-size-aligned in general. As a result, whene

Bug#225466: libc6.1: thread-creation fails after setting non-page-aligned stack limit

2003-12-29 Thread David Mosberger
Package: libc6.1 Version: 2.3.2.ds1-10.0.1 Severity: normal Tags: sid patch I noticed that I can no longer load a directory via dired. The root-cause of the problem appears to be that Emacs uses setrlimit() to set RLIMIT_STACK. This limit won't be page-size-aligned in general. As a result, whene

Bug#210359: kernel CONFIG_TR interferes with busybox CONFIG_TR

2003-09-17 Thread David Mosberger
>>>>> On Thu, 18 Sep 2003 10:23:48 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: Goto> At Wed, 17 Sep 2003 17:37:02 -0700, Goto> David Mosberger wrote: >> >>>>> On Thu, 18 Sep 2003 09:33:47 +0900, GOTO Masanori <[EMAIL PROTECTED]> said

Bug#210359: kernel CONFIG_TR interferes with busybox CONFIG_TR

2003-09-17 Thread David Mosberger
> On Thu, 18 Sep 2003 09:33:47 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: Goto> Adding HZ=1024 for userland seems ok for me even if CONFIG_IA64_HP_SIM Goto> is defined, but any problems? Yeah, but it just looks so warty... Are there any Debian packages that break if HZ is not defined

Bug#210359: kernel CONFIG_TR interferes with busybox CONFIG_TR

2003-09-17 Thread David Mosberger
> On Thu, 18 Sep 2003 08:09:33 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: Goto> Yes, it's not libc6 own problem, but kernel source problem. Goto> In some kernels, this problem should also be occured on alpha. Goto> One way to fix is to enclose #ifdef __KERNEL__. Goto> David, could

Bug#204789: [Gcl-devel] Re: recent commit

2003-09-05 Thread David Mosberger
> On 05 Sep 2003 18:38:45 -0400, Camm Maguire <[EMAIL PROTECTED]> said: Camm> Greetings, and thankyou for this suggestion. It does seem like a bit Camm> of a hack though, no? It's a hack until it's used > 3 times, then it becomes a technique... ;-) Camm> Do you feel this would be more

Bug#204789: [Gcl-devel] Re: recent commit

2003-09-02 Thread David Mosberger
> On 29 Aug 2003 17:38:31 -0400, Camm Maguire <[EMAIL PROTECTED]> said: Camm> Greetings, and thanks again! So how do I find the right area Camm> before dumping? Perhaps it would work to scan /proc/self/maps for the mapping that covers the address of (any) function descriptor in the main

Bug#204789: recent commit

2003-08-30 Thread David Mosberger
> On 28 Aug 2003 21:00:54 -0400, Camm Maguire <[EMAIL PROTECTED]> said: Camm> Greetings! This sounds like the sort of sidestepping of the Camm> function descriptors that I was seeking initally. Can you Camm> elaborate? I can dump the actual address, but don't I need to Camm> find wh

Bug#204789: recent commit

2003-08-29 Thread David Mosberger
Camm, > On 21 Aug 2003 00:52:14 -0400, Camm Maguire <[EMAIL PROTECTED]> said: Camm> --enable-static configuration option -- default on ia64, as a Camm> workaround for current algorithm of runtime realized function Camm> descriptors. It appears that you'd see the same/similar problem on

Re: FWD: IMPORTANT glibc fix

2003-03-28 Thread David Mosberger
> On Sat, 29 Mar 2003 00:14:00 +0900, GOTO Masanori <[EMAIL PROTECTED]> > said: >> Thanks. I've just updated cvs.dpatch to the latest. glibc >> 2.3.2-1 should fix this problem. Excellent. Debian beating everybody else to the punch, once again! ;-) --david

Re: FWD: IMPORTANT glibc fix

2003-03-28 Thread David Mosberger
> On Sat, 29 Mar 2003 00:14:00 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: >> Thanks. I've just updated cvs.dpatch to the latest. glibc >> 2.3.2-1 should fix this problem. Excellent. Debian beating everybody else to the punch, once again! ;-) --david -- To UNSUBSCRIBE, e

Re: bad {MIN}SIGSTKSZ on debian glibc-2.2.5-14.3

2003-01-27 Thread David Mosberger
> On Sat, 25 Jan 2003 18:22:38 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: GOTO> Ah, I see. But... is it critical thing to replace "stable" package? GOTO> Changing Debian "stable" release is something high barrier... GOTO> I don't know current IA-64 really needs such change or not, s

Re: bad {MIN}SIGSTKSZ on debian glibc-2.2.5-14.3

2003-01-22 Thread David Mosberger
>> investigate and give us an answer, please? >> >> Bdale, at Linux Conf Australia this week >> >> >> From: David Mosberger <[EMAIL PROTECTED]> >> Subject: [ia64 R&D] bad {MIN}SIGSTKSZ on debian glibc-2.2.5-14.3 >> >&g