On Thu, Dec 15, 2011 at 1:52 PM, peter green wrote:
> From my tests it seems that in both squeeze and sid __USE_XOPEN2K8 gets
> defined by default
> (in ) but __USE_XOPEN does not.
> so this change to the ifdef changed it from "default no" to "default yes"
>
> Reverting the change the ifdef would
Finn Thain dixit:
>It might be helpful to do the same with gcc 4.4.
That was with gcc 4.4 (which src:eglibc forces).
bye,
//mirabilos
--
“Having a smoking section in a restaurant is like having
a peeing section in a swimming pool.”
--
>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 inc
Wookey wrote:
> We can
> 1) Change every app in the world that defines a 'struct user'
> 2) Stop these headers getting brought in when not actually needed
> (it's a relatively recent change that brings it in)
> 3) Change the name in glibc/GDB to something less likely to clash
Some background fro
On Thu, Dec 15, 2011 at 2:15 AM, peter green
wrote:
> While renaming the structure would be one soloution to the
> conflicts changing a long standing* interface to solve a
> problem that is arch specific and has only recently become a
> significant issue** seems like a wrong approach to me.
>
> Th
Processing commands for cont...@bugs.debian.org:
> reassign 652160 eglibc
Bug #652160 [libstdc++6-4.6-dbg] libstdc++6-4.6-dbg: ldconfig complains about
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16-gdb.py
Bug reassigned from package 'libstdc++6-4.6-dbg' to 'eglibc'.
Bug No longer marked as found
On Thu, 15 Dec 2011, Thorsten Glaser wrote:
> Just FYI, maybe you can do something with it (or not).
> I built the latest eglibc 2.13-23 without nocheck.
It might be helpful to do the same with gcc 4.4.
Finn
>
>
> make[1]: Leaving directory `/tmp/buildd/eglibc-2.13/build-tree/m68k-libc'
> #
Just FYI, maybe you can do something with it (or not).
I built the latest eglibc 2.13-23 without nocheck.
make[1]: Leaving directory `/tmp/buildd/eglibc-2.13/build-tree/m68k-libc'
#
# Testsuite failures, someone should be working towards
# fixing these! They are listed here for the purpose of
# r
This subject came up on debian-arm:
http://lists.debian.org/debian-arm/2011/12/msg00025.html
And it seems like the sort of architectural issue linaro should take
an interest in fixing to avoid making people's lives difficult when
building on arm. Is it on anyone's list already?
In short:
A C ap
Author: aurel32
Date: 2011-12-15 08:47:39 + (Thu, 15 Dec 2011)
New Revision: 5087
Added:
glibc-package/branches/glibc-branch-squeeze/debian/patches/arm/cvs-tls-unallocated.diff
glibc-package/branches/glibc-branch-squeeze/debian/patches/mips/cvs-tls-unallocated.diff
Modified:
glibc-p
10 matches
Mail list logo