Package: libc6
Version: 2.3.5-13
Severity: normal
The following two fails occur in the CVS binutils testsuite:
Running /home/dave/binutils-2.16.91/src/ld/testsuite/ld-pie/pie.exp ...
gcc -L/home/dave/binutils-2.16.91/objdir/./ld -pie
/home/dave/binutils-2.16.91/s
rc/ld/testsuite/ld-pie/pie.c -o
> Aurelien Jarno a écrit :
> >
> > Could you please tell me where to find this version of the glibc, and
> > also the sources? I can then find the patch and include it in the Debian
> > package.
> >
> OK, I have found the fix in the CVS, I am currently doing a test build.
Great.
If you are do
> On Sat, Jan 07, 2006 at 01:05:11AM -0800, Steve Langasek wrote:
> > Grant, thank you for your work to date on this bug. (BTW, it would be
> > helpful if you would follow up to bug #342545 on libgcc2, instead of bug
> > #341675 which is filed against just one of the many packages affected by
> >
> There isn't a lot of info in #342545. However, I suspect from the
> following comment
>
> > It would be nice if somebody fluent with hppa assembly can tell us if
>
> > fldw -10(,sp),fr23
>
> that this is the same bug as reported here:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754
Package: libc6
Version: 2.3.5-8
Severity: normal
The following program produces incorrect results:
#include
int
main ()
{
printf ("%Lf\n", strtold ("1", NULL));
return 0;
}
[EMAIL PROTECTED]:~/gcc_test$ gcc -o ld1 ld1.c
[EMAIL PROTECTED]:~/gcc_test$ ./ld1
0.00
-- System Information:
D
Package: libc6
Version: 2.3.5-6.0.1
Severity: important
DWARF2 exception support is broken due to bad EH data in the .eh_frame
section of /lib/libc-2.3.5.so.
After installation of libc6 version 2.3.5-6.0.1, a number of regressions
were observed in the GCC 4.0 and 4.1 testsuites. The following f
Don't know if this will work. My mail server at NRC is down for the
day due
to building maintenance requiring a shutdown of electrical power.
Thus, I
can't receive mail.
> Could you check for me why this failed:
>
> if (hdr->fde_count_enc != DW_EH_PE_omit
> && hdr->table_enc == (DW_EH_P
> binutils-2.15 has this in include/opcodes/hppa.h:
> { "fdc",0x04001280, 0xfc003fdf, "cZx(s,b)", pa10, 0},
> { "fdc",0x04001280, 0xfc003fdf, "cZx(b)", pa10, 0},
> { "fic",0x04000280, 0xfc001fdf, "cZx(S,b)", pa10, 0},
> { "fic",0x04000280, 0xfc001fdf, "cZx(b)", pa10,
> > binutils-2.15 has this in include/opcodes/hppa.h:
> > { "fdc",0x04001280, 0xfc003fdf, "cZx(s,b)", pa10, 0},
> > { "fdc",0x04001280, 0xfc003fdf, "cZx(b)", pa10, 0},
> > { "fic",0x04000280, 0xfc001fdf, "cZx(S,b)", pa10, 0},
> > { "fic",0x04000280, 0xfc001fdf, "cZx(
> On Sat, Sep 24, 2005 at 09:27:22PM -0400, John David Anglin wrote:
> > The last "fic" opcode entry is wrong. It's using the wrong
> > instruction format, the mask is wrong, pa10 is wrong, etc.
>
> I don't think we realised this until now. I suspect w
> > no, it's not fakeroot, it's make segfaulting ...
> [...]
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 16384 (LWP 16911)]
> > 0x4091fd20 in __canonicalize_funcptr_for_compare () from
> > /lib/libpthread.so.0
> > (gdb) bt
> > #0 0x4091fd20 in __canonicalize_
> #1 0x406d7424 in __pthread_sigaction (sig=18, act=0xc0241ec8,
> oact=0xc0241f50)
> at signals.c:106
> 106 if (old == SIG_IGN || old == SIG_DFL || old == SIG_ERR)
> (gdb) print &old
> Address requested for identifier "old" which is in register $r11
> (gdb) print /x $r11
> $6 =
> > no, it's not fakeroot, it's make segfaulting ...
> [...]
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 16384 (LWP 16911)]
> > 0x4091fd20 in __canonicalize_funcptr_for_compare () from
> > /lib/libpthread.so.0
> > (gdb) bt
> > #0 0x4091fd20 in __canonicalize_
> > no, it's not fakeroot, it's make segfaulting ...
> [...]
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 16384 (LWP 16911)]
> > 0x4091fd20 in __canonicalize_funcptr_for_compare () from
> > /lib/libpthread.so.0
> > (gdb) bt
> > #0 0x4091fd20 in __canonicalize_
> >>Confirmed. We are passing a function pointer with a value of -2 into
> >>__cffc, which should not happen...
> >
> >
> > Is -2 a special signal number?
>
> I don't think so. in any case, others have observed that if they use an
> older glibc, this problem does not happen.
Not sure this is r
to be determined. In the
> meantime, I think it's best to reassign this back to qt-x11-free.
This might be a nan bug. There is one GCC nan fix that's only
installed on the trunk:
2006-05-24 John David Anglin <[EMAIL PROTECTED]>
PR target/27627
* pa/
Steve,
> This might be a nan bug. There is one GCC nan fix that's only
> installed on the trunk:
>
> 2006-05-24 John David Anglin <[EMAIL PROTECTED]>
>
> PR target/27627
> * pa/pa-modes.def: Use mips_single_format, mips_double_format and
>
> Could you try with the latest xserver-xorg-core 1.3 currently in
> unstable and latest drivers and report back whether this bug still occurs?
I'm not sure when I can get to this. Too many problems with recent update
to glibc version 2.5 in testing and gcc issues (and my real world job).
Dave
-
A patch for this problem was posted here:
http://lists.parisc-linux.org/pipermail/parisc-linux/2007-June/031690.html
However, it's likely that the parisc specific code will be removed in
favour of the generic compat code.
Dave
--
J. David Anglin [EMAIL PROTECTED]
Package: xserver-xorg
Version: 1:7.1.0-18
Severity: normal
After starting X using any of gdm, kdm or xstart, keyboard wasn't
accepted. There were no errors in Xorg.0.log. However, I see stuff
like the following in kdm.log:
(==) Log file: "/var/log/Xorg.0.log", Time: Sat May 5 14:43:39 2007
(=
Package: libc6
Version: 2.5-9
Severity: critical
Justification: breaks the whole system
The following command leads to a system crash:
[EMAIL PROTECTED]:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
The command hangs after the first line of output is printed. It
is no
Package: libc6
Version: 2.5-9
Severity: grave
Justification: renders package unusable
After updating to libc6 2.5-9 Friday evening, the svn package is
now broken:
[EMAIL PROTECTED]:~/gnu/gcc-4.3/gcc$ contrib/gcc_update
Updating SVN tree
Ugcc/real.c
Ugcc/real.h
Ugcc/ChangeLog
Ugcc
> Is the libc6 the only thing that you updated? I am using the same libc
> here, paer.debian.org also uses it in the sid chroot, and I am unable to
> reproduce the problem.
No, some other packages were updated. Here are the most recent
packages in /var/cache/apt/archives:
-rw-r--r-- 1 root root
> Is the libc6 the only thing that you updated? I am using the same libc
> here, paer.debian.org also uses it in the sid chroot, and I am unable to
> reproduce the problem.
This is on a PA8800 machine.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research C
> > YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> > PSW: 1110 Not tainted
> > r00-03 00ff0806ff0f 4036c000 40104edc
> > c0601048
> > r04-07 403d79d4 403d89d4 0002c258
> >
> > r08-11 0002a3f4
> It looks like you are using a hand built kernel. Do you use the patch to
> disable LWS CAS debugging [1] ?
Yes, but I've been told by Kyle that it's too old. Syscall 298 was
added in 2.6.21.
I haven't disabled LWS CAS.
My attempts at modifying the kernel to return ENOSYS so far haven't
been s
> > fstat64(3, {st_mode=0, st_size=0, ...}) = 0
> > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> > 0x40005000
> > read(3, "/dev/sda3 / ext3 rw,errors=remou"..., 4096) = 339
> > read(3, "", 4096) = 0
> > close(3)=
> I found really strange that this version of the glibc is using this
> syscall. It has been released 6 months ago, when 2.6.19 was still not
> released... How did you get this syscall number?
It's in register r20 of the register dump that I posted.
Dave
--
J. David Anglin
> It really looks like a bug in the kernel.
Yes, see
http://lists.parisc-linux.org/pipermail/parisc-linux/2007-June/031651.html
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
--
To UNSU
> > It really looks like a bug in the kernel.
>
> Yes, see
> http://lists.parisc-linux.org/pipermail/parisc-linux/2007-June/031651.html
The change posted here fixes the df problem:
http://lists.parisc-linux.org/pipermail/parisc-linux/2007-June/031652.html
So, this bug report can be closed.
Dave
> Did you have a chance to test this?
The software updates are installed and the links that I installed
are removed. However, I haven't actually had a chance to look at
the display. Normally, I access the machine remotely.
I think there's a new problem:
...
(EE) FBDEV(0): FBIOPUT_VSCREENINFO s
> Which xserver-xorg-video-fbdev and xserver-xorg-core is this?
ii xserver-xorg-v 1:0.3.1-1 X.Org X server -- fbdev display driver
ii xserver-xorg-c 2:1.3.0.0.dfsg X.Org X server -- core server
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Co
> John David Anglin wrote:
> >> Which xserver-xorg-video-fbdev and xserver-xorg-core is this?
> >>
> >
> > ii xserver-xorg-v 1:0.3.1-1 X.Org X server -- fbdev display driver
> > ii xserver-xorg-c 2:1.3.0.0.dfsg X.Org X server -- core server
>
> It could also indicate a broken framebuffer device. John, which one are
> you using?
HP VisEG.
Dave
--
J. David Anglin [EMAIL PROTECTED]
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
X Window System Version 1.3.0
Release Date:
> On Sat, Apr 22, 2006 at 10:00:04AM +0200, Matthias Klose wrote:
> > $ ldd a.out
> > libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x40575000)
> > libm.so.6 =3D> /lib/libm.so.6 (0x4046e000)
> > libgcc_s.so.2 =3D> /lib/libgcc_s.so.2 (0x40068000)
> > libc.so.6 =3D> /li
> > [EMAIL PROTECTED]:~/gmp-4.2.dfsg/tests/cxx$ g++ -Wall test-throw.cc &&
> > ./a.out
> > /usr/bin/ld: warning: libgcc_s.so.4, needed by
> > /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so, may conflict with
> > libgcc_s.so.2
I'm puzzled about this. It seems like libstdc++ for GCC 4.0.3 was
bu
> Yes, we do, but
>
> $ ls -l /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so
> lrwxr-xr-x 1 root root 23 Apr 6 02:08
> /usr/lib/gcc/hppa-linux-gnu/4.0.3/libstdc++.so -> ../../../libstdc++.so.6
Oh, I was thinking there were separate libraries for each GCC version.
I've had to live with this for
> Is this acutally decided? Is it likely to happen soon, or should I
> build GMP with gcc 3.3 (which doesn't exhibit the problem) in the
> short term?
For now, I suggest that you remove gcc-4.1 from your build system.
Then, GMP should build fine with 4.0. You might have to reinstall
4.0.
As far
> Er, no; we're talking about official Debian packages here, and the
> libstdc++.so.6 in Debian is now from gcc-4.1. The problem is precisely that
> GMP *is* being built using gcc-4.0, but libstdc++ is from gcc-4.1, resulting
> in the double libgcc_s problem.
Then, you must build *eveything* for
> Ok, coming back to the question of the system compiler on hppa for
> etch. Assuming that hppa does want to do that:
>
> - is glibc buildable with gcc-4.1 on hppa?
As far as I know, there's no new problems using 4.1 instead of 4.0. See
http://lists.parisc-linux.org/pipermail/parisc-linux/2006-A
See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
Since ROC hasn't been dropped, this change appears premature. It
also breaks compatibility with other linux distributions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
See GCC PR 31413:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
This change appears premature and breaks compatibility with other linux
distributions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
42 matches
Mail list logo
