Your message dated Mon, 31 May 2010 12:14:21 +0100
with message-id <20100531111421.ga11...@reptile.pseudorandom.co.uk>
and subject line Re: Bug#552224: gcc-4.3: [armel] __thread variable uses
R_ARM_GOTOFF32 relocation if optimizing => SEGV
has caused the Debian Bug report #552224,
regarding gcc-4.3: [armel] __thread variable uses R_ARM_GOTOFF32 relocation if
optimizing => SEGV
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
552224: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552224
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: gcc-4.3
Version: 4.3.4-5
Severity: normal
(I'm guessing that this is a compiler bug, but it could conceivably be
the linker or some other toolchain component; if so, please reassign.)
As described in <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546823>,
libcap-ng0 0.6.1 contains a __thread variable. When built with -O0 it seems to
work fine, but when built with -O1 or -O2 dereferencing that variable
causes a segfault.
This appears to be related to this linker warning, which does not appear
under -O0:
> gcc -shared .libs/cap-ng.o .libs/lookup_table.o -Wl,-z -Wl,relro
> -Wl,-z -Wl,defs -Wl,-soname -Wl,libcap-ng.so.0 -o
> .libs/libcap-ng.so.0.0.0
> /usr/bin/ld: .libs/cap-ng.o(.text+0x810): R_ARM_GOTOFF32 used with TLS
> symbol m
> /usr/bin/ld: .libs/cap-ng.o(.text+0xc1c): R_ARM_GOTOFF32 used with TLS
> symbol m
To test this it is sufficient to compile libcap-ng with the desired option,
then run "make check". The test program will segfault if optimizations
were used. I tried this in both squeeze and sid environments.
At my suggestion, the libcap-ng maintainer has worked around this bug by
turning off optimization on armel. If this bug in the toolchain is
fixed, the optimizations should be reinstated.
Pierre, could you please mention this bug# next to the workaround in
debian/rules in future versions? Sorry, I should have filed this before
sending you the patch...
Regards,
S
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing'), (101, 'unstable')
Architecture: armel (armv5tel)
Kernel: Linux 2.6.30-1-kirkwood
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gcc-4.3 depends on:
ii binutils 2.19.91.20091006-1 The GNU assembler, linker and bina
ii cpp-4.3 4.3.4-5 The GNU C preprocessor
ii gcc-4.3-base 4.3.4-5 The GNU Compiler Collection (base
ii libc6 2.9-25 GNU C Library: Shared libraries
ii libgcc1 1:4.4.1-4 GCC support library
ii libgomp1 4.4.1-4 GCC OpenMP (GOMP) support library
Versions of packages gcc-4.3 recommends:
ii libc6-dev 2.9-25 GNU C Library: Development Librari
Versions of packages gcc-4.3 suggests:
pn gcc-4.3-doc <none> (no description available)
pn gcc-4.3-locales <none> (no description available)
pn libgcc1-dbg <none> (no description available)
pn libgomp1-dbg <none> (no description available)
pn libmudflap0-4.3-dev <none> (no description available)
pn libmudflap0-dbg <none> (no description available)
-- no debconf information
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
Version: 4.4.4-2
On Mon, 31 May 2010 at 00:08:16 +0200, Matthias Klose wrote:
> Please could you recheck with 4.4 from unstable, and if the problem
> is still seen, with 4.4 and/or gcc-snapshot?
Verified to be OK in at least 4.4.4-2 and 4.4.4-3, so I've closed the bug.
Thanks,
Simon
signature.asc
Description: Digital signature
--- End Message ---
