This is the mail archive of the
mailing list for the GCC project.
Re: config/tls.m4: Use the general dynamic model for the crossed case
On Tue, 16 Oct 2007, Paolo Bonzini wrote:
> > + dnl Add -fPIC so that the general dynamic model is used as the
> > + dnl compiler may support TLS, but __tls_get_addr() may be absent
> > + dnl from the C library if not supported there.
> > + CFLAGS="$CFLAGS -fPIC"
> > + dnl Similarly, ask the linker to build a shared object and forbid
> > + dnl unresolved symbol references. This is so that the linker
> > + dnl does not try to convert the object to the local exec model
> > + dnl and the lack of __tls_get_addr() is actually seen.
> > + LDFLAGS="$LDFLAGS -shared -Wl,-z,defs"
> I would like to hear from other people if this makes sense but anyway this
Of course, I am open to any kind of feedback, be it positive or critical.
It is a bit frustrating when this test incorrectly succeeds and then later
on the build fails like this:
./.libs/libgcj.so: undefined reference to `__tls_get_addr'
when the newly built library is used to link against.
> patch is not enough. You have to do this only when GNU binutils or another
> linker that supports -Wl,-z,defs is being used. So you should split the test
> in two, one for -Wl,-z,defs and one for TLS. It might also be that -fPIC or
> -shared is not supported at all in some configurations, some of which may
> support TLS in standalone programs.
Well, if -Wl,-z,defs is not supported, then supplying the other flags
makes no sense, because an unsatified dependency on __tls_get_addr will
not get reported as a link error. It only makes sense to supply them all
or none, which is why testing them separately does not add any value.
Unless you mean we want to be able to use an alternative flag as possibly
available with other binary utilities that is -- libtool.m4 has some
embedded knowledge about them -- but then the key question is: do we
actually support cross-compiling GCC with non-GNU-binutils? And: is there
an alternative set of binary cross-utilities available for a target that
supports TLS? If the answer to either of these questions is no, then I
would recommend not to overdesign this test and only come back to the
issue if an actual problem arises.
And for standalone, etc. configurations which do not support -fPIC or
-shared, the test is still done, but without these options. Of course it
implies they are really unsupported and not that they are accepted but
produce unpredictable results that would make the test meaningless. That
would be a bug in these configurations.