On Sat, 31 Mar 2007 04:26:23 +0200 Pieter de Goeje <[EMAIL PROTECTED]> wrote:
> Hello List,
>
> I have these files:
> --- loader.cpp ---
> #include <stdio.h>
> #include "tls.h"
>
> int main() {
> tls = 0;
> printf("%d\n", tls);
> }
>
> --- tls.cpp ---
> #include "tls.h"
> int __thread tls;
>
> --- tls.h ---
> extern __thread int tls;
>
> When I compile them like this:
> c++ -fPIC -o tls.so tls.cpp -shared
> c++ -fPIC -o loader loader.cpp tls.so
>
> And run the resulting program, I get:
> [EMAIL PROTECTED]:~/projects/misc/tls> ./loader
> /libexec/ld-elf.so.1: ./loader: Unsupported relocation type 37 in
> non-PLT relocations
>
> When I omit -fPIC, it runs fine. But I need fPIC for the shared
> object on amd64 arch. I've tried it on Linux/i386 (gcc 4.1) and it
> ran fine (with fPIC).
>
> Much to my surprise however, a particularly large application I'm
> working on did compile & run on FreeBSD/amd64 using -fpic (lowercase)
> and gcc 4.3. Trying -fpic on FreeBSD/i386 resulted in failure.
>
> FYI, I need tls to work because I'm using OpenMP's tls (#pragma omp
> threadprivate()) support in gcc 4.3.
>
> The workaround I found on FreeBSD/amd64 was linking the main
> executable with -fno-PIC, or building everything with -fpic. (both
> workarounds didn't work on FreeBSD/i386)
>
> I would be grateful if someone could shed some light on this.
>
There is no reason whatsoever to compile main binary code with -f[pP]ic.
Executables are not shared libraries and stuffing position independent
code into them makes no sense.
--
Alexander Kabaev
signature.asc
Description: PGP signature
