Package: libc6
Version: 2.21-0experimental1
I had an expermimental chroot on a system that happened to be running an
old kernel. I got an error message about needing a 2.6.32 kernel which
was strange as I already had a 2.6.32 kernel.
Reading the preinst revealed
# The GNU libc
Package: eglibc
Severity: serious
From the mips build log (the mipsel one looks the same to me though
I haven't done a thourough check to see if the list of failed tests
is identical
Encountered regressions that don't match expected failures:
tst-cancel24, Error 1
tst-cancelx10, Error 1
package: libc6-dev
version:
severity: important
justification: causes other packages to FTBFS
On arm* sys/ucontext.h heavilly polloutes the global
namespace firstly by including sys/user.h (which defines
among other things a type called struct user and secondly
by defining symbols and #defines
Joseph S. Myers wrote:
The most obvious users of these definitions would be (native) GDB and
gdbserver - do those still build OK (i.e. include the correct headers to
get the definitions they need and not rely on any definitions that were
removed) after this patch?
I have built the debian
Konstantinos Margaritis wrote:
Does anyone know what the impact of renaming these to use a REG_ prefix like
i386, amd64 and sparc do* would be?
at worst the packages that had to be workaround on arm* for this, can
have the workaround removed.
I have prepared a patch (attatched) that eliminates
ISO C99 says that WCHAR_MAX must be a constant expression and the
above definition is such an expression. Technically the program needs
fixing (see below though for the standards matter but so do users),
there is nothing wrong with a type cast and a constant value e.g.
signed -1 converted to
Ulrich WeigandNow, glibc also provides a file sys/ucontext.h that defines
Ulrich Weigandlayouts of register sets for use with signal handlers as well
Ulrich Weigandas the makecontext/setcontext/getcontext family of routines.
Ulrich Weigand
Ulrich WeigandUsually, those layouts tend to be in fact
As a first step why don't you try breaking the header include chain in
glibc, and rebuild gdb to ensure everything works?
It looks like there are two places the chain could reasonablly be
broken. sys/ucontext.h could stop including sys/procfs.h
(this would match amd64) or signal.h could stop
Carlos O'Donell wrote:
As an upstream glibc maintainer I would be happy to see this fixed in
glibc and gdb, but nobody has stepped up to fix it.
Ok.
The `struct user` is used by the gdbserver code that uses ptrace
(PTRACE_PEEKUSR/POKEUSR) to peek/poke at the inferior and read out
stored
recently i've been seeing some packages FTBFS on armhf with definition
clashes of struct
user. Test building packages the package on armel has invariblly shown
the issue
happening there as well despite the same version of the source package
having built there
successfully in the past. I've also
oops forgot to actually cc it like I said I would
Does anyone know if there is any particular reason that bitlbee uses
libresolv.a rather than libresolv.so ?
Yes; the fact that Ulrich Drepper thought it'd be a good idea to declare
this API private and unsupported, claiming it's for
+++-==-==-
un libc6-i686 none (no description available)
The file comes from libc6-i686 version 2.6.1-1. According to the symlink
it has been installed on 2007-08-21 (ie the date it migrates to
testing).
After a
It's not that easy in the swi-prolog case. The two headers are included
in two separate headers, which are then included into the .c file. The
order cannot be switched around, because the former header includes
config.h, which is needed for the second header to work at all (IIRC).
Can't you
nearly a week ago a bug was filed against libc6
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421037) reporting a sigill
when upgrading on a netwinder. Replies to the bug report say that on some
netwinders it does work.
there is still no information in the bug report log on what the
it seems like it would be a good idea to check for non dpkg owned versions
of problem libraries sitting in that directory in the preinst and either
aborting the upgrade before the system is left in a badly broken state or
moving the files out of the way.
--
To UNSUBSCRIBE, email to [EMAIL
15 matches
Mail list logo
