Activity log for bug #503448

Date Who What changed Old value New value Message
2010-01-05 16:54:21 Michael Casadevall bug added bug
2010-01-05 16:54:21 Michael Casadevall attachment added GNU hell test suite http://launchpadlibrarian.net/37453821/gnuhell.tar.gz
2010-01-05 16:56:29 Michael Casadevall tags armel
2010-01-05 16:58:13 Michael Casadevall description Binary package hint: gcc-4.4 Under lucid, GCC can no longer build non-PIC shared libraries, attempting to build a non-PIC library causes: /usr/bin/ld: .libs/hello.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC error According to the binutils mailing list (http://old.nabble.com/Detect-ARM-MOVW-MOVT-relocations-in-shared-library-links-td23266269.html) this error is tripped as a safeguard when an object thats compiled for PIC attempts to load from load an absolute symbol address. Its not clear from the list archives if building non-PIC shared libraries is still supported as of ARMv7, or if this is a regression in the toolchain. The issue disappears if -march=armv6 is passed into the CFLAGS. Reproduction Instructions: I've attached a copy of the GNU hell test which is used as part of the libtool test suite, and can be used to easily reproduce the problem on a lucid/armel system. Building for ARMv7 mode fails with a relocation error from the linker. Passing -march=armv6 in the CFLAGS allows the build to succeed and the resulting libraries and binaries work as expected: To build for ARMv7 $ ./configure --with-pic=no && make To build for ARMv6 $ CFLAGS=-march=armv6 ./configure --with-pic=no Binary package hint: gcc-4.4 Under lucid, GCC can no longer build non-PIC shared libraries, attempting to build a non-PIC library causes: /usr/bin/ld: .libs/hello.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC error According to the binutils mailing list (http://old.nabble.com/Detect-ARM-MOVW-MOVT-relocations-in-shared-library-links-td23266269.html) this error is tripped as a safeguard when an object thats compiled for PIC attempts to load from load an absolute symbol address. Its not clear from the list archives if building non-PIC shared libraries is still supported as of ARMv7, or if this is a regression in the toolchain. The issue disappears if -march=armv6 is passed into the CFLAGS. Reproduction Instructions: I've attached a copy of the GNU hell test which is used as part of the libtool test suite, and can be used to easily reproduce the problem on a lucid/armel system. Building for ARMv7 mode fails with a relocation error from the linker. Passing -march=armv6 in the CFLAGS allows the build to succeed and the resulting libraries and binaries work as expected: To build for ARMv7 $ ./configure --with-pic=no && make To build for ARMv6 $ CFLAGS=-march=armv6 ./configure --with-pic=no && make
2010-01-06 12:25:04 Matthias Klose tags armel armel armv7
2010-06-22 09:11:12 Matthias Klose tags armel armv7 armel armv7 toolchain
2010-07-12 16:42:25 Loïc Minier tags armel armv7 toolchain armel armv7 thumb toolchain
2010-07-21 14:34:23 Andrew Stubbs bug task added gcc-linaro
2010-07-21 14:35:13 Andrew Stubbs gcc-linaro: importance Undecided High
2010-07-21 14:36:27 Andrew Stubbs affects gcc-linaro binutils-linaro
2010-09-07 23:42:01 Khem Raj bug added subscriber Khem Raj
2010-11-17 16:18:46 Curtis Hovey removed subscriber Registry Administrators
2011-01-05 13:52:36 Jani Monoses bug added subscriber Jani Monoses
2011-01-20 11:32:12 Jani Monoses removed subscriber Jani Monoses
2011-05-10 21:42:11 Hector Oron bug added subscriber Hector Oron
2011-10-10 12:00:52 Launchpad Janitor gcc-4.4 (Ubuntu): status New Confirmed
2013-03-07 08:03:03 Will Newton binutils-linaro: status New Triaged
2013-03-07 08:03:26 Will Newton binutils-linaro: importance High Undecided
2013-03-12 15:55:52 Will Newton binutils-linaro: status Triaged Won't Fix