Re: BFD config.h correctly #undefs 'TLS' (my compiler is old), but then bfd.c uses it anyway. Result is build failure.
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.
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.
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