Re: BFD config.h correctly #undefs 'TLS' (my compiler is old), but then bfd.c uses it anyway. Result is build failure.

[Gordon Steemson]

Hello Nick,

> On Nov 27, 2024, at 4:10 AM, Nick Clifton <nickc@redhat.com> wrote:
> 
> Hi Gordon,
> 
> >> Result is build failure.
> 
> What specifically fails ?

My compiler encounters a __thread decorator and throws up its metaphorical 
hands, as it did not (yet?) support it for PowerPC at that time (Apple's last 
custom builds of GCC were forked from the mainline at version 4.2.1).

> And where exactly are you adding the "#undef TLS"  ?

Huh?  Where'd you get that from?  The configure script tests for it and 
correctly notes its absence, which it then records by not defining (which I 
summarize as "undefining") whatever config.h variable it uses for the purpose.

>> I am not enormously familiar with the mechanics of thread-local
>> storage, but I get the impression that optionally doing without it
>> would be next to impossible given the way that bfd.c is written.
> 
> Really ?  The only reason that bfd.c is using thread local storage
> is so that it can work with multi-threaded applications that use the
> bfd library.  The bfd library itself is single threaded, and it only
> uses thread local storage for static variables that have compilation
> unit scope.

That's encouraging!  I must have overestimated its pervasiveness.

> One possible solution is to use the 2.41 binutils release (or earlier).
> Support for thread local storage in bfd.c was only added in the 2.42
> release, so using an earlier one should solve your problems.

Sounds good!  I'll give that a try.  Hopefully I won't miss any super urgent 
bugfixes by so doing.

>> Should the ./configure script be throwing up an error and refusing to
>> proceed if TLS is not available?  
> 
> No - it should continue to work and just provide an empty definition
> of the TLS macro.  See bfd/ax_tls.m4 for the configure code that is
> supposed to determine in the compiler supports TLS.  It is possible
> that there is a bug in this code and that it is not performing correctly
> when a compiler does not have any thread support at all.

I don't think that's it.  Thread support is well entrenched and used in many 
places, just not TLS.  As far as I can tell, it correctly determines TLS to be 
unsupported – but then does nothing useful with that knowledge.

> If so, please
> could you report this bug using the binutils bugzilla system:
> 
>  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils
> 
> Cheers
>  Nick