Opened 22 months ago

Closed 21 months ago

Last modified 11 months ago

#58260 closed defect (fixed)

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

Reported by: physicsbeany Owned by: Nullstelllensatz <50169837+Nullstelllensatz@…>
Priority: Normal Milestone:
Component: ports Version: 2.5.4
Keywords: mojave Cc: cjones051073 (Chris Jones), Dave-Allured (Dave Allured), mndavidoff (Monte Davidoff), basmac, n7zzt (eric oyen), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), akimd (Akim Demaille)
Port: gcc9 gcc8 gcc7 gcc6 libgcc-devel libgcc8 libgcc7 libgcc6

Description (last modified by ryandesign (Ryan Schmidt))

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).

Attachments (2)

libgcc8_INSTALLFAILURE_TRUNCATED.log (8.5 MB) - added by physicsbeany 22 months ago.
last 50K lines of log file (whole thing is 64 MB)
Portfile-gcc6.diff (475 bytes) - added by jmon12 11 months ago.
Condition for applying the _Atomic patch against the SDK version instead of Xcode version.

Change History (34)

Changed 22 months ago by physicsbeany

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

comment:1 Changed 22 months ago by physicsbeany

Description: modified (diff)

comment:2 Changed 22 months ago by SerpentChris (Chris Calderon)

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

comment:3 Changed 22 months ago by mf2k (Frank Schima)

Keywords: atomic removed

comment:4 Changed 22 months ago by 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>.

comment:5 Changed 22 months ago by ryandesign (Ryan Schmidt)

Description: modified (diff)
Keywords: mojave added

Could you attach the entire logfile, compressing it first?

comment:6 Changed 22 months ago by 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...

comment:7 Changed 22 months ago by cjones051073 (Chris Jones)

Cc: cjones051073 added

comment:8 Changed 22 months ago by 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.

comment:9 Changed 22 months ago by 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.

comment:10 Changed 22 months ago by cjones051073 (Chris Jones)

Port: gcc9 gcc8 gcc7 gcc6 libgcc-devel libgcc7 libgcc6 added
Summary: libgcc8 build fails due to "Atomic" error on Mojavegcc{6,7,8,9} : Build failures due to "Atomic" error with macOS 10.4.4 and Xcode 10.2

comment:11 Changed 22 months ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:12 Changed 22 months ago by mndavidoff (Monte Davidoff)

Cc: mndavidoff added

comment:13 Changed 22 months ago by collavr (Hyun Kang)

Cc: collavr added

comment:14 Changed 22 months ago by collavr (Hyun Kang)

Cc: collavr removed

comment:15 Changed 22 months ago by basmac

Cc: basmac added

comment:16 in reply to:  6 Changed 22 months ago by ryandesign (Ryan 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.

comment:17 Changed 22 months ago by cjones051073 (Chris Jones)

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

comment:18 Changed 22 months ago by mf2k (Frank Schima)

Cc: n7zzt added

Has duplicate #58324.

comment:19 Changed 22 months ago by 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.

comment:20 Changed 22 months ago by 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.

comment:21 Changed 22 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: MarcusCalhoun-Lopez added

comment:22 Changed 21 months ago by akimd (Akim Demaille)

Cc: akimd added

comment:23 Changed 21 months ago by Nullstelllensatz <50169837+Nullstelllensatz@…>

Owner: set to Nullstelllensatz <50169837+Nullstelllensatz@…>
Resolution: fixed
Status: newclosed

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

comment:24 Changed 21 months ago by cjones051073 (Chris Jones)

Resolution: fixed
Status: closedreopened

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}.

Last edited 21 months ago by cjones051073 (Chris Jones) (previous) (diff)

comment:26 Changed 21 months ago by cjones051073 (Chris Jones)

Resolution: fixed
Status: reopenedclosed

Now all merged.

comment:27 Changed 15 months ago by 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!

comment:28 Changed 15 months ago by 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.

comment:29 in reply to:  28 Changed 11 months ago by 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.

comment:30 Changed 11 months ago by 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.

comment:31 Changed 11 months ago by 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} {

comment:32 in reply to:  31 Changed 11 months ago by 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.

Changed 11 months ago by jmon12

Attachment: Portfile-gcc6.diff added

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

Note: See TracTickets for help on using tickets.