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
>
On 11 October 2011 08:52, Jean-Luc Aufranc gcc/arm- linux-gnueabi/ 4.5.2/. ./../.. /../arm- linux-gnueabi/ bin/ld: /home/jaufranc/ edev/beagleboar d/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 edev/beagleboar d/berkelium/ build/chromium/ src/out/ Release/ obj.target/ ui/gfx/ libgfx. a: could not read symbols: Bad value
<email address hidden> wrote:
> I have the same problem compiling berkelium with linaro toolchain (gcc
> 4.5.2) on Ubuntu natty.
>
> /usr/lib/
> /home/jaufranc/
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
> /bugs.launchpad .net/bugs/ 503448 MOVW_ABS_ NC against old.nabble. com/Detect- MOVT-relocation s-in-shared- library- links-td2326626 9.html) /bugs.launchpad .net/binutils- linaro/ +bug/503448/ +subscriptions
> --
> You received this bug notification because you are a member of Linaro
> Toolchain Developers, which is subscribed to Linaro Binutils.
> https:/
>
> 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_
> `a local symbol' can not be used when making a shared object;
> recompile with -fPIC error
>
> According to the binutils mailing list (http://
> ARM-MOVW-
> 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:/
>