On 11 October 2011 08:52, Jean-Luc Aufranc
<email address hidden> wrote:
> I have the same problem compiling berkelium with linaro toolchain (gcc
> 4.5.2) on Ubuntu natty.
>
> /usr/lib/gcc/arm-linux-gnueabi/4.5.2/../../../../arm-linux-gnueabi/bin/ld: /home/jaufranc/edev/beagleboard/berkelium/build/chromium/src/out/Release/obj.target/ui/gfx/../../gfx/ui/gfx/rect.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
> /home/jaufranc/edev/beagleboard/berkelium/build/chromium/src/out/Release/obj.target/ui/gfx/libgfx.a: could not read symbols: Bad value


If you expect your library to be used only by 1 executable and 1
process statically link it, if you expect your library to be used by
more than one process across multiple executables, then create a
proper shared library using -fPIC. If you don't do this you'll end up
spraying around lots of DT_TEXTREL entries and each time the shared
library is used in a particular process it will end up creating a full
copy of the page with only the change for the addresses in movw / movt
and end up with a much higher memory footprint than expected rather
than just creating a new copy of the addresses you want in the Global
offset table and therefore cause more overhead than anything else.

I don't think the tools should change to allow this through. If you
really really want to do this use the GCC option -mword-relocations on
your command line and then hopefully the compiler will get it right.
If you have hand crafted assembler that uses movw / movt for addresses
and symbols change it to using constant pools.

cheers
Ramana

>
> --
> You received this bug notification because you are a member of Linaro
> Toolchain Developers, which is subscribed to Linaro Binutils.
> https://bugs.launchpad.net/bugs/503448
>
> Title:
>  [arm] building non-PIC libraries fails under ARMv7 mode
>
> Status in Linaro Binutils:
>  New
> Status in “gcc-4.4” package in Ubuntu:
>  Confirmed
>
> Bug 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 && make
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/binutils-linaro/+bug/503448/+subscriptions
>