Thread local storage not working with -fPIC and shared objects

[Alexander Kabaev]

On Sat, 31 Mar 2007 04:26:23 +0200
Pieter de Goeje <pieter at degoeje.nl> 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:
> pyotr at nox:~/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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20070331/79c8ecdf/signature.pgp