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:
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
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
#
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'
#
#
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, Dec 15, 2011 at 2:15 AM, peter green
peter.gr...@postgrad.manchester.ac.uk 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
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 from a
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
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.”
--
On Thu, Dec 15, 2011 at 1:52 PM, peter green plugw...@p10link.net 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
10 matches
Mail list logo
