Exact details to build GCC

I need to build GCC 8 from source on my Mac, ultimately without brew. I tried gleaning the relevant portions from the brew formula but the build always fails with the following when --enable-tls is enabled:

/var/folders/cq/wx4ff_gd0xncqh9qnbzmt2w40000gp/T//ccS0vBm1.s:9:2: error: unsupported symbol modifier

in relocation

leaq __ZN3GTM12_gtm_thr_tlsE@tlsgd(%rip), %rdi

^

make[5]: *** [alloc_cpp.lo] Error 1

I’ve tried multiple versions of GCC (4.9, 5,5, 8.3, and 8.4) and Mac (10.10, 10.12 and 10.15)–all behave the same.
All systems have only XCode CLT, none have XCode. All systems are fresh installs with very minimal adjustment additions.

If I build without --enable-tls or with --disable-tls then the build succeeds but then I get synchronization problems in my code which uses std::unique_lock<std::mutex> (namely it seems the synchronization isn’t performed).

Anyway I’m looking for the exact environment & commands that brew uses to build GCC on Mac. Any chance there’s some nightly/weekly automated build that captures such info that I can look at to see where I’m going wrong? If not, is there a way I can get such info if I use brew to build GCC on my system? And if so, can I tell brew to leave GCC only in the prefix and not try to tie it into the main system (/usr/… )?

Anyway I’m looking for the exact environment & commands that brew uses to build GCC on Mac.

There’s very extensive sandboxing and filtering in homebrew builds. You could run the build with --debug to see what is happening though.

And if so, can I tell brew to leave GCC only in the prefix and not try to tie it into the main system (/usr/… )?

The prefix is /usr/local. But if you don’t want GCC linked on install you can just do brew unlink gcc after you install it.

1 Like

Thanks this is helpful. Per GCC folks it turns out --enable-tls is not expected to work on Mac at this time. So most of this was just operator error on my part.

Regarding brew install without linking, is it possible to avoid the linking entirely (so as to guarantee the original system is not affected)? Maybe using a non-priviledged account to run brew so system files can’t be changed?

Brew can’t actually run in a configuration where it affects system files. It’ll only ever write to /usr/local which is empty on macOS (until you start using homebrew).

I see, so since /usr/local/bin is first in $PATH then it’ll take precedence without having to touch anything inside /usr/bin. Very nice. Thanks!

Such is the magic (and pain) of the PATH variable