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

2024-11-27 Thread Gordon Steemson
Hello Nick,

> On Nov 27, 2024, at 4:10 AM, Nick Clifton  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



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

2024-11-27 Thread Nick Clifton

Hi Gordon,

>> Result is build failure.

What specifically fails ?

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



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.

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.



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.  If so, please
could you report this bug using the binutils bugzilla system:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

Cheers
  Nick






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

2024-11-07 Thread Gordon Steemson
Background to this dismaying discovery:  I'm attempting to find a
minimally painful way to bootstrap a 20-year-old Power Mac G5 into
some semblance of a modern toolchain.  Out of the box, it comes with
GCC 4.2.1 and an amazingly primitive Apple version of as.  I can
readily build a less-ancient GCC (e.g. GCC 6 and 7 each sit at a
comfortable distance from both "can't be compiled" and "can't compile
anything"), but I was hoping to be able to bootstrap gas along with it
(among other reasons, Macs generally expect to be able to
cross-compile for whatever architecture Apple is migrating to or from
at the time, so building GCC is properly done by building a native GCC
and also at least one cross-compiling GCC; in this case ppc[64] →
(i686/x86-64), and possibly also ppc[64] → aarch64, if I want to get
overenthusiastic).  This and similar software combinations can of
course be constructed piecemeal, but ideally a package-manager recipe
would do it all in one shot.  (Admittedly it will be one _very drawn
out_ shot, but the key point is the user shouldn't need to hold it by
the hand until it finishes.)

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.
Should the ./configure script be throwing up an error and refusing to
proceed if TLS is not available?  I don't know what the project's
design philosophy is here.

Sincerely,
Gordon Steemson

PS: if anyone answers this, please also CC me directly – I do not
necessarily have reliable access to the mailing list.

-- 
The world’s only gsteemso