I tracked down what was causing the "./a.out: Symbol `fstat' causes
overflow in R_X86_64_PC32 relocation" message (and I suppose the others as
well).
My build script attempts to link my executables with my project's dynamic
lib (unless directed otherwise) and then a static version of the same lib
before linking in external libs (the idea is to have a generic recipe that
provides for the possibility that some of my project's executables might
want to refer to project symbols that aren't exported in the shared lib).
It seems it is this double linking ( `tcc something... liblib.so liblib.a`
), compounded with something in the glibc definition of
fstat, that causes the problem on tcc.
MCVE:
#!/bin/sh -eu
cat > liblib.c <<EOF
#include <sys/stat.h>
void f(void) { struct stat sb; fstat(0, &sb); }
EOF
cat > main.c <<EOF
int main() { extern void f(); f(); return 0; }
EOF
: ${CC:=tcc}
$CC liblib.c -fPIC -c; ar rcs liblib.a liblib.o; $CC -o liblib.so liblib.o
-shared
$CC main.c $PWD/liblib.so liblib.a #uncommenting liblib.a removes the error
LD_LIBRARY_PATH=$PWD ./a.out
In the above reproducer, liblib.a should be ignored because it's not
resolving any undefined references, but instead it appears to be causing
the error message.
Regards,
Petr Skocik
On Mon, Jul 2, 2018 at 1:16 AM Michael Matz <matz....@frakked.de> wrote:
> Hi,
>
> On Thu, 28 Jun 2018, Petr Skocik wrote:
>
> > Symbol `__dso_handle' causes overflow in R_X86_64_PC32 relocation
> > Symbol `fstatat' causes overflow in R_X86_64_PC32 relocation
> > Symbol `fstat' causes overflow in R_X86_64_PC32 relocation
> > Symbol `mknod' causes overflow in R_X86_64_PC32 relocation
> > Symbol `pthread_atfork' causes overflow in R_X86_64_PC32 relocation
>
> Indeed. TCC doesn't link with crtbegin.o (or crtbeginS.o) coming from
> GCC, and hence doesn't provide the hack symbol __dso_handle (which
> pthread_atfork in glibc needs). This is another case of an
> interdependency between glibc and compiler specifics.
>
> > I tried to make an MCVE (minimal, complete, verifiable example) and this
> one
> > should do it:
>
> Thanks. There's a work around for the pthread_atfork problem: add this
> definition to one source file for each shared library/executable that
> contains a call to pthread_atfork:
>
> void * __dso_handle __attribute((visibility("hidden"))) = &__dso_handle;
>
> e.g. in your testcase, add it to liblib.c . Eventually we probably want
> to create this symbol automatically from TCC on glibc systems, until then
> you can use the above.
>
> That fstat/fstatat/mknod have overflows as well might have multiple
> reasons: on glibc systems all three functions have something in common:
> they are defined in the libc_nonshared.a archive, which normally should
> have been included via libc.so (a linker script, not a normal softlink to
> the real shared lib). You can check with -vvv which should list that
> library to be included. No matter what I can't reproduce that problem by
> e.g. adding a call to fstatat into your reproducer for the dso_handle
> problem, so if you can provide one for e.g. fstatat as well...
>
> > If this is a bad place to post such bug reports, please let me know.
> > (Should I post bug reports on
> > https://savannah.nongnu.org/bugs/?group=tinycc or elsewhere instead?)
>
> Many people here don't have a bugzilla account there and so
> don't monitor it; it seems better to write here.
>
>
> Ciao,
> Michael._______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
