This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/ 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]