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

[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