Bug#546823: __thread usage in libcap-ng0 broken on armel if optimizing

2009-10-27 Thread Pierre Chifflier
Hi Simon, On Sun, Oct 25, 2009 at 03:53:39PM +, Simon McVittie wrote: The uploaded packages do solve this bug at least for now (verified on my armel box by restarting smartd), since Debian doesn't yet cross-build anything and so host = build in practice; however, my change was wrong for

Bug#546823: __thread usage in libcap-ng0 broken on armel if optimizing

2009-10-25 Thread Simon McVittie
On Sun, 25 Oct 2009 at 03:50:57 +0100, Guillem Jover wrote: On Thu, 2009-10-22 at 23:46:22 +0100, Simon McVittie wrote: +# armel compiler doesn't seem to do too well at __thread if optimizing +ifeq ($(DEB_BUILD_GNU_TYPE),arm-linux-gnueabi) +CFLAGS += -O0 +endif This is not correct, you

Bug#546823: __thread usage in libcap-ng0 broken on armel if optimizing

2009-10-24 Thread Guillem Jover
Hi! On Thu, 2009-10-22 at 23:46:22 +0100, Simon McVittie wrote: diff -u libcap-ng-0.6.2/debian/rules libcap-ng-0.6.2/debian/rules --- libcap-ng-0.6.2/debian/rules +++ libcap-ng-0.6.2/debian/rules @@ -23,7 +23,10 @@ PYDEF=$(shell pyversions -d) PYVERS=$(shell pyversions -r) - +# armel

Bug#546823: __thread usage in libcap-ng0 broken on armel if optimizing

2009-10-22 Thread Simon McVittie
It appears that the segfaults in libcap-ng0 described in my earlier bug report, caused by (or at least related to) use of R_ARM_GOTOFF32 relocations with TLS symbols, can be avoided by compiling libcap-ng without optimization. I attach an interdiff; for your convenience, it also includes fixes for