r5087 - in glibc-package/branches/glibc-branch-squeeze/debian: . patches patches/arm patches/mips
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-package/branches/glibc-branch-squeeze/debian/changelog glibc-package/branches/glibc-branch-squeeze/debian/patches/series Log: * Add patches/arm/cvs-tls-unallocated.diff and patches/mips/cvs-tls-unallocated.diff to fix FTBFS on armel, mips and mipsel. Modified: glibc-package/branches/glibc-branch-squeeze/debian/changelog === --- glibc-package/branches/glibc-branch-squeeze/debian/changelog 2011-12-14 20:12:19 UTC (rev 5086) +++ glibc-package/branches/glibc-branch-squeeze/debian/changelog 2011-12-15 08:47:39 UTC (rev 5087) @@ -1,3 +1,11 @@ +eglibc (2.11.3-2) UNRELEASED; urgency=low + + * Add patches/arm/cvs-tls-unallocated.diff and +patches/mips/cvs-tls-unallocated.diff to fix FTBFS on armel, mips +and mipsel. + + -- Aurelien Jarno aure...@debian.org Thu, 15 Dec 2011 09:46:52 +0100 + eglibc (2.11.3-1) stable; urgency=low * Update from stable upstream version, and update from the upstream Added: glibc-package/branches/glibc-branch-squeeze/debian/patches/arm/cvs-tls-unallocated.diff === --- glibc-package/branches/glibc-branch-squeeze/debian/patches/arm/cvs-tls-unallocated.diff (rev 0) +++ glibc-package/branches/glibc-branch-squeeze/debian/patches/arm/cvs-tls-unallocated.diff 2011-12-15 08:47:39 UTC (rev 5087) @@ -0,0 +1,15 @@ +2011-04-11 Joseph Myers jos...@codesourcery.com + + * ports/sysdeps/arm/dl-tls.h (TLS_DTV_UNALLOCATED): Define. + +diff --git a/ports/sysdeps/arm/dl-tls.h b/ports/sysdeps/arm/dl-tls.h +index 02285a7..694d11d 100644 +--- a/ports/sysdeps/arm/dl-tls.h b/ports/sysdeps/arm/dl-tls.h +@@ -27,3 +27,6 @@ typedef struct dl_tls_index + + + extern void *__tls_get_addr (tls_index *ti); ++ ++/* Value used for dtv entries for which the allocation is delayed. */ ++#define TLS_DTV_UNALLOCATED ((void *) -1l) Added: glibc-package/branches/glibc-branch-squeeze/debian/patches/mips/cvs-tls-unallocated.diff === --- glibc-package/branches/glibc-branch-squeeze/debian/patches/mips/cvs-tls-unallocated.diff (rev 0) +++ glibc-package/branches/glibc-branch-squeeze/debian/patches/mips/cvs-tls-unallocated.diff 2011-12-15 08:47:39 UTC (rev 5087) @@ -0,0 +1,15 @@ +2011-04-11 Joseph Myers jos...@codesourcery.com + + * ports/sysdeps/mips/dl-tls.h (TLS_DTV_UNALLOCATED): Define. + +diff --git a/ports/sysdeps/mips/dl-tls.h b/ports/sysdeps/mips/dl-tls.h +index 6d3ed6f..75facb0 100644 +--- a/ports/sysdeps/mips/dl-tls.h b/ports/sysdeps/mips/dl-tls.h +@@ -44,3 +44,6 @@ extern void *__tls_get_addr (tls_index *ti); + + # define GET_ADDR_OFFSET (ti-ti_offset + TLS_DTV_OFFSET) + # define __TLS_GET_ADDR(__ti) (__tls_get_addr (__ti) - TLS_DTV_OFFSET) ++ ++/* Value used for dtv entries for which the allocation is delayed. */ ++#define TLS_DTV_UNALLOCATED ((void *) -1l) Modified: glibc-package/branches/glibc-branch-squeeze/debian/patches/series === --- glibc-package/branches/glibc-branch-squeeze/debian/patches/series 2011-12-14 20:12:19 UTC (rev 5086) +++ glibc-package/branches/glibc-branch-squeeze/debian/patches/series 2011-12-15 08:47:39 UTC (rev 5087) @@ -73,6 +73,7 @@ arm/local-no-hwcap.diff arm/local-hwcap-updates.diff arm/local-sigaction.diff +arm/cvs-tls-unallocated.diff hppa/local-inlining.diff hppa/local-linuxthreads.diff @@ -164,6 +165,7 @@ mips/local-lowlevellock.diff mips/local-r10k.diff mips/submitted-rld_map.diff +mips/cvs-tls-unallocated.diff s390/cvs-makecontext.diff s390/submitted-nexttowardf.diff -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rb6yz-0006sx...@vasks.debian.org
Re: struct user conflicts on arm
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 app that defines a struct 'user' and uses wait.h or signal.h will find a clash with the system struct of the same name, which should only be needed for GDB (when built on/for arm). On other arches this is not pulled in by default so the problem doesn't arise. 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 disclaimer: I know nothing at all about this except what I just read in that thread. Please refer to the thread for details. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111215110917.gc28...@dream.aleph1.co.uk
[m68k] eglibc expected(?) testsuite results
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 # regression testing during builds. # Format: Failed test, Error Make error code [(ignored)] # annexc.out, Error 1 (ignored) bug-nextafter.out, Error 24 bug-nexttoward.out, Error 32 bug-regex20.out, Error 139 check-localplt.out, Error 1 sort-test.out, Error 1 test-double.out, Error 1 test-fenv.out, Error 1 test-float.out, Error 1 test-idouble.out, Error 1 test-ifloat.out, Error 1 test-misc.out, Error 1 tst-atomic-long.out, Error 1 tst-atomic.out, Error 1 tst-mqueue5.out, Error 1 tst-mqueue6.out, Error 1 tst-mutexpi2.out, Error 1 tst-mutexpi4.out, Error 1 tst-mutexpi5.out, Error 1 tst-mutexpi5a.out, Error 1 tst-mutexpi6.out, Error 1 tst-mutexpi7.out, Error 1 tst-mutexpi7a.out, Error 1 tst-mutexpi9.out, Error 1 tst-robust1.out, Error 1 tst-robust2.out, Error 1 tst-robust3.out, Error 1 tst-robust4.out, Error 1 tst-robust5.out, Error 1 tst-robust6.out, Error 1 tst-robust7.out, Error 1 tst-robust8.out, Error 1 tst-robust9.out, Error 1 tst-robustpi1.out, Error 1 tst-robustpi2.out, Error 1 tst-robustpi3.out, Error 1 tst-robustpi4.out, Error 1 tst-robustpi5.out, Error 1 tst-robustpi6.out, Error 1 tst-robustpi7.out, Error 1 tst-robustpi8.out, Error 1 tst-rxspencer.out, Error 139 *** WARNING *** Please generate expected testsuite results for this arch! *** WARNING *** touch /tmp/buildd/eglibc-2.13/stamp-dir/check_libc bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (239 (257) bugs: 0 RC, 166 (180) IN, 73 (77) MW, 0 FP) ‣ src:dash (72 (82) bugs: 3 RC, 27 (30) IN, 42 (49) MW, 0 FP) ‣ src:mksh (1 bug: 0 RC, 0 IN, 1 MW, 0 FP) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit? -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1112151245590.15...@herc.mirbsd.org
Re: [m68k] eglibc expected(?) testsuite results
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' # # Testsuite failures, someone should be working towards # fixing these! They are listed here for the purpose of # regression testing during builds. # Format: Failed test, Error Make error code [(ignored)] # annexc.out, Error 1 (ignored) bug-nextafter.out, Error 24 bug-nexttoward.out, Error 32 bug-regex20.out, Error 139 check-localplt.out, Error 1 sort-test.out, Error 1 test-double.out, Error 1 test-fenv.out, Error 1 test-float.out, Error 1 test-idouble.out, Error 1 test-ifloat.out, Error 1 test-misc.out, Error 1 tst-atomic-long.out, Error 1 tst-atomic.out, Error 1 tst-mqueue5.out, Error 1 tst-mqueue6.out, Error 1 tst-mutexpi2.out, Error 1 tst-mutexpi4.out, Error 1 tst-mutexpi5.out, Error 1 tst-mutexpi5a.out, Error 1 tst-mutexpi6.out, Error 1 tst-mutexpi7.out, Error 1 tst-mutexpi7a.out, Error 1 tst-mutexpi9.out, Error 1 tst-robust1.out, Error 1 tst-robust2.out, Error 1 tst-robust3.out, Error 1 tst-robust4.out, Error 1 tst-robust5.out, Error 1 tst-robust6.out, Error 1 tst-robust7.out, Error 1 tst-robust8.out, Error 1 tst-robust9.out, Error 1 tst-robustpi1.out, Error 1 tst-robustpi2.out, Error 1 tst-robustpi3.out, Error 1 tst-robustpi4.out, Error 1 tst-robustpi5.out, Error 1 tst-robustpi6.out, Error 1 tst-robustpi7.out, Error 1 tst-robustpi8.out, Error 1 tst-rxspencer.out, Error 139 *** WARNING *** Please generate expected testsuite results for this arch! *** WARNING *** touch /tmp/buildd/eglibc-2.13/stamp-dir/check_libc bye, //mirabilos -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.LNX.2.00.1112160008400.2552@nippy.intranet
Processed: Re: Bug#652160: libstdc++6-4.6-dbg: ldconfig complains about /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16-gdb.py
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 in versions gcc-4.6/4.6.2-7. thanks Stopping processing here. Please contact me if you need assistance. -- 652160: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652160 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.132395946417621.transcr...@bugs.debian.org
Re: struct user conflicts on armel and armfh
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 like a wrong approach to me. The real problem IMO is that headers that are supposed to be implementing special purpose interfaces for debugging are being pulled in by headers that are supposed to be implementing common public interfaces. * at least as far back as debian slink ** In squeeze armel signal.h would only include sys/ucontext.h if explicit defines were set. In wheezy and sid it seems to include it by default. Are you volunteering to change glibc and gdb, and work with upstream to get the changes merged? Depends on what exactly is involved in doing that and whether we can agree on how things should be fixed. As I said i'm not convinced that gdb needs to be changed. As a first step why don't you try breaking the header include chain in glibc, and rebuild gdb to ensure everything works? Applications that actually need `struct user' will need to pull it in explicitly instead of implicitly through another header. One thing I wanted to check, but can't (the site is still undergoing reconstruction after the security breach), is whether or not LSB documents this interface as pat of the standard. If it was documented in LSB (which has an ISO standard), you could argue that the application is non-conforming to LSB, and that the real fix is to stop using `struct user' because it's part of the standard. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADZpyixPg+EgSBMkfjoAWc8BD6C7C=wn0uwcgnerfo2kvi-...@mail.gmail.com
Re: struct user conflicts on arm
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 GDB perspective: the files sys/procfs.h and sys/user.h define the layout of the various register sets the kernel provides to user space debuggers via ptrace and/or core file register note sections. In the past, it was considered a good idea for this information to be provided by kernel headers via inclusion into glibc to be used by GDB sources. However, this turned out to not be really feasible with modern GDB: since this information is needed to access core files, and with a cross-debugger we need to access core files produced on some other architecture than the host, we cannot actually rely on system headers (which only provide information about the host architecture). Fortunately, the layout is part of the unchanging kernel ABI, so there is no real need for GDB to rely on any header files in the first place. Therefore, GDB is currently in the process to switching to simply hard-coding register set layouts for various architectures. Once this process is complete, sys/user.h and sys/procfs.h will no longer be needed to build GDB. (The process is mostly complete for sys/user.h; it will still take a while for sys/procfs.h.) However, from a system perspective, it is probably still not a good idea to just remove (or incompatibly change) those headers: you want to keep the capability to compile older GDB sources (and possibly other debuggers). Now, glibc also provides a file sys/ucontext.h that defines layouts of register sets for use with signal handlers as well as the makecontext/setcontext/getcontext family of routines. Usually, those layouts tend to be in fact identical to the layouts described in sys/user.h / sys/procfs.h. Apparently, whoever implemented the ARM version of sys/ucontext.h was trying to avoid some seemingly unnecessary code duplication by making sys/ucontext.h *include* sys/procfs.h and using the information from there directly. This is not done on other platforms, for precisely the reason that the sys/procfs.h and sys/user.h headers do pollute the name space ... So I think the right thing to do in the short term would be to stop sys/ucontext.h including sys/procfs.h, and instead add the register set information there directly, even if that means some duplication of code. (Again, since this is never-changing ABI, duplication isn't actually all that bad. Also, all the other platforms do it that way too, so why should ARM be different ...) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/of944a0ed5.1ea1377b-onc1257967.00636680-c1257967.0066b...@de.ibm.com
Re: struct user conflicts on armel and armfh
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 including sys/ucontext.h (this would match armel squeeze) I first tried breaking the chain by removing the include of sys/procfs.h from sys/ucontext.h (this would make arm* consistent with i386 and amd64) but it seems sys/ucontext.h on arm DOES use a couple of things from sys/procfs.h so breaking the chain at this point would require investigating those. Next I tried breaking the chain by commenting out the include of sys/ucontext.h in signal.h. This seemed more positive, a test program that included signal.h still built fine as did gdb. So that brings us back to why is signal/h including sys/ucontext.h by default in wheezy/sid when it didn't do so in squeeze. It seems the cause is the change of the following ifdef Squeeze: #ifdef __USE_XOPEN /* This will define `ucontext_t' and `mcontext_t'. */ # include sys/ucontext.h # endif Wheezy/Sid: # if defined __USE_XOPEN || defined __USE_XOPEN2K8 /* This will define `ucontext_t' and `mcontext_t'. */ # include sys/ucontext.h # endif seems to be defined by default 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 solve the issue but before submitting a patch to actually do that I would like to know why the change was made in the first place. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4eea41f4.8010...@p10link.net
Re: [m68k] eglibc expected(?) testsuite results
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.” -- Edward Burr -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1112152055350@herc.mirbsd.org
Re: struct user conflicts on armel and armfh
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 ifdef would solve the issue but before submitting a patch to actually do that I would like to know why the change was made in the first place. Look at the git logs for upstream glibc, find the author and ask them? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADZpyiy=hw9AkLH5qp2B_EgzDqZ6RLk=bvsfmwpixmbcyuk...@mail.gmail.com
