gcc{6,7,8,9} : Build failures due to "Atomic" error with macOS 10.4.4 and Xcode 10.2

[physicsbeany]

Recently upgraded to MacOS Mojave from High Sierra, and followed general Macports instructions for migrating my old ports. Things went fine until libgcc8 (needed to do my py27-scipy installation). Initially, this failed because of Unwind issues. I solved this by following the advice in ticket #57198.

Now, however, the compilation fails because of an "Atomic" error. Specifically, the first instance of the Error in the log file is:

:info:build /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/ucred.h:94:2: error: '_Atomic' does not name a type
:info:build   _Atomic u_long          cr_ref;  /* reference count */

The full logfile is 64 MB; I've uploaded the last 50K lines of it.

Some Googling indicates that this may be avoided by defining __STDC_NO_ATOMICS__, but I'm not certain this is the right answer (and I don't know how to do this as part of a Macports installation).

[physicsbeany]

last 50K lines of log file (whole thing is 64 MB)

[SerpentChris (Chris Calderon)]

I've got the same error on my brand new iMac running 10.14.4.

[kencu (Ken)]

This is a strange error to see. My first thought is to clean and try again ( I noticed you didn't clean between attempts previously, and this can have unforeseen weird effects).

sudo port clean libgcc8
sudo port -v install libgcc8

I'm also wondering why you didn't have it downloaded from the binary buildbot instead of MacPorts' making you build it. It's right there <​http://packages.macports.org/libgcc8/libgcc8-8.3.0_0.darwin_18.x86_64.tbz2>.

[ryandesign (Ryan Carsten Schmidt)]

Could you attach the entire logfile, compressing it first?

[cjones051073 (Chris Jones)]

I am seeing this in a number of builds on the buildbots. e.g.

​https://build.macports.org/builders/ports-10.14_x86_64-builder/builds/27818/steps/install-port/logs/stdio

What is odd is builds that previously built fine (i.e. the binary tarballs exist) are now failing. This leads me to wonder if its related to a recent macOS/Xcode update...

[cjones051073 (Chris Jones)]

It seems this is being found in a number of places. e.g.

​https://apple.stackexchange.com/questions/355049/compilation-error-with-mojave-error-atomic-does-not-name-a-type

​https://discourse.brew.sh/t/atomic-does-not-name-a-type-gcc8-should-be-updated-patched/4516

Its looking to me like something new to the recent macOS 10.14.4 and Xcode 10.2 update.

[cjones051073 (Chris Jones)]

Just to complete the Mac OS package manager set ...

​https://github.com/fink/fink-distributions/issues/386

There is also a link there to an upstream gcc bug report.

​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

The gcc devs seem to confirm in their view its an Xcode 10.2 issue.

[ryandesign (Ryan Carsten Schmidt)]

Replying to cjones051073:

I am seeing this in a number of builds on the buildbots. e.g.

​https://build.macports.org/builders/ports-10.14_x86_64-builder/builds/27818/steps/install-port/logs/stdio

What is odd is builds that previously built fine (i.e. the binary tarballs exist) are now failing. This leads me to wonder if its related to a recent macOS/Xcode update...

I did just update the Mojave builder to Xcode 10.2.

[cjones051073 (Chris Jones)]

Yes, I did check the logs and saw Xcode 10.2 was used in the failed builds.

[mf2k (Frank Schima)]

Has duplicate #58324.

[n7zzt (eric oyen)]

ok, so it appears that I am not the only one to notice. Also, instead of migrating my old ports from High Sierra, I simply made a list of those items Needed and installed new. However, because of this "Atomic Error", gcc9 fails to build.

I have also noted that there seems to be an increasing frequency of breakages of this type across more and more packages as time goes on. Is this a deep error inside the compiler somewhere?

Last item (not directly related to this ticket, but relevant): this site needs to be properly audited for accessibility. Filing the ticket was a real exercise in frustration as not all form controls were immediately accessible and catalogued by my screen reader. If this doesn't tell you, then perhaps I need to make it plainly clear: I am totally blind and website ease of use for me is a BIG priority. Right now, trying to navigate through this site is a bit of a PITA. I had to reload it before the screen reader would catalogue all the controls, links, edit boxes, checkboxes and the like. Even then, This particular edit box was not visible until I dug deep into this table entry to find it. This is something the web development team needs to take a look at. If they have questions, I can be reached via return email.

very last item, exactly what causes an "Atomic Error" anyway? trying to dig around on google only confused things.

[cjones051073 (Chris Jones)]

Regarding gcc9, please note this is not a production compiler, but a build of one of the gcc snapshot development versions. No other port in MacPorts should depend on it, so I suggest you just uninstall it for now, and use gcc8 instead, which should install for you as you will use the pre-built binary tarball.

I am sorry to hear about the accessibility issues you had with the website. I guess no one has ever tried using it with accessibility in mind. Please bear in mind the site is community maintained, so unless someone steps up with specific suggestions, or audits it specifically for accessibility, its perhaps not surprising it isn't as easy to use as it should be. What would help, is if you have specific suggestions of things to change, as I guess few have screen readers so would be able to know what the issues are.

"Atomic Error" is just a para-phrasing of the compiler error that is generated, that refers to a missing type, that if I have understood things correct is due to an issue with incorrectly including/using C/C++ types in the wrong context.

[Nullstelllensatz <50169837+Nullstelllensatz@…>]

In 742e739105533d88b9e87a62af790561ce34ccd0/macports-ports (master):

gcc9: bump to latest snapshot, no more "Atomic" error

• updates gcc9 snapshot to 20190428
• no more build errors on Mojave and Xcode 10.2+
• updated checksums

closes: #58260

[cjones051073 (Chris Jones)]

reopening this, simply as fix committed so far only fixes things for gcc9. I am working on backporting patches to gcc{5,6,7,8}.

[cjones051073 (Chris Jones)]

​https://github.com/macports/macports-ports/pull/4242

​https://github.com/macports/macports-ports/pull/4241

​https://github.com/macports/macports-ports/pull/4240

​https://github.com/macports/macports-ports/pull/4239

[cjones051073 (Chris Jones)]

Now all merged.

[jmon12]

Dear all, I need to build gcc5 from source and fail encountering the so-called "Atomic error". From what I understand, it seems that the "xcode-bug-_Atomic-fix.patch" is applied based on the value of the xcodeversion variable. See lines 84:90 in gcc5's portfile:

if {[vercmp ${xcodeversion} 10.2] >= 0} {                                      
    # https://trac.macports.org/ticket/58260                                   
    # Patch for Xcode bug, taken from                                          
    # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864#c43                   
    # https://github.com/Homebrew/homebrew-core/pull/39134/files               
    patchfiles-append   xcode-bug-_Atomic-fix.patch                            
}

I don't know how the xcodeversion variable is defined, but it's probably not defined if Xcode is not installed, which is my case. I'm indeed using only the command line tools.

So:

• It doesn't concern full xcode installations only
• Which condition should be evaluated instead? I'll try to investigate myself but am at the very beginning of discovering macports' internals...

From a superficial google search, I'm able to get the version of the CLT using pkgutil --pkg-info=com.apple.pkg.CLTools_Executables giving in my case:

package-id: com.apple.pkg.CLTools_Executables
version: 10.3.0.0.1.1562985497
volume: /
location: /
install-time: 1563885516
groups: com.apple.FindSystemFiles.pkg-group 

Is there another macports variable based on the above CLT version number instead of the xcode's one (using xcodebuild)?

I would be happy to contribute, I'm sorry for my lack of knowledge. Hope I'll be at some point able to give back to the macports community!

[cjones051073 (Chris Jones)]

To be honest, I never considered the possibility to not have Xcode installed.

Maybe it would work to just remove the version test. This would have to be tested though.

Any reason you are installing from source, and not using the prebuilt binaries ? Do this, without Xcode installed, is probably not very well tested ground.

[jmon12]

Replying to cjones051073:

To be honest, I never considered the possibility to not have Xcode installed.

Maybe it would work to just remove the version test. This would have to be tested though.

Any reason you are installing from source, and not using the prebuilt binaries ? Do this, without Xcode installed, is probably not very well tested ground.

I need to build gcc from source because of the issues in ticket #57937 (see my comments). Summed up: the prebuilt gcc ports don't add / to the sysroot anymore (only xcode specific ones), which was forcing me to always run gcc with the --sysroot=/ -Wl,-syslibroot,/ options.

Removing the xcodeversion check, I could indeed build gcc5 with the (default) / sysroot, and it solved my problem.

I think the check for the gcc ports should be done against a variable containing the SDK version, not the xcode version. It would solve my problem and is anyway more specific to the actual problem with the new headers if I'm not mistaking.

From a debug configuration of the gcc5 port:

DEBUG: Xcode none
DEBUG: SDK 10.14

As expected, Xcode variable is not populated, but the SDK one is. I will continue my exploration of the macports internals for finding the corresponding variable and provide a suggestion of a simple patch fixing the if-clause here. Do you have any obvious objection?

PS: sorry for my late answer! I thought I would receive some kind of email notification and didn't see your comment.

[jmon12]

Indeed from the comment 2 of the related gcc ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864#c43, the problem is SDK-specific, not Xcode-specific.

I attached is a simple patch checking the SDK version instead of Xcode version. It works on my side.

[kencu (Ken)]

are you sure that you want to test against SDK 10.4?

if {[vercmp ${configure.sdk_version} 10.4] >= 0} {

I presume you meant

if {[vercmp ${configure.sdk_version} 10.14] >= 0} {

[jmon12]

Replying to kencu:

are you sure that you want to test against SDK 10.4?

if {[vercmp ${configure.sdk_version} 10.4] >= 0} {

I presume you meant

if {[vercmp ${configure.sdk_version} 10.14] >= 0} {

Hum yes indeed I'm sorry. Let me fix it.

[jmon12]

Condition for applying the _Atomic patch against the SDK version instead of Xcode version.