libgcc7 fails to compile/install on macOS Mojave

[ProgrammingPoet (Gregory Gelfond)]

Attempting to install libgcc7 as a dependency for matplotlib fails. Log file attached.

[ProgrammingPoet (Gregory Gelfond)]

Zipped version of the log file (original was 10mb)

[ryandesign (Ryan Carsten Schmidt)]

Your log says:

fatal error: experimental/bits/lfts_config.h: No such file or directory
 #include <experimental/bits/lfts_config.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

This looks like the parallel build failure we previously encountered on APFS on High Sierra. ​The upstream bug report has recently had a comment that the issue has resurfaced on Mojave, even with the existing solutions in place. The workaround is to build non-parallel:

sudo port install libgcc7 build.jobs=1

If other gcc ports fail in the same way, use the same workaround.

[tenomoto (Takeshi Enomoto)]

I had a similar problem with libgcc8 and followed Ryan's suggestion, but the same error occurred. I installed system headers (see ​https://solarianprogrammer.com/2017/05/21/compiling-gcc-macos/). Although the build is still going, it seems that it passed the point of error.

[kencu (Ken)]

There is a comment relating to something like that in the gcc* Portfiles:

    if {${configure.sdkroot} ne ""} {
        # We should be using --with-build-sysroot here.  Using --with-sysroot
        # changes the behavior of the installed gcc to look in that sysroot
        # by default instead of /.  Using --with-build-sysroot is supposed
        # to be used during the build but not impact the installed product.
        # Unfortunately, the build fails because the value doesn't get
        # plumbed everywhere it is supposed to.
        #
        # https://trac.macports.org/ticket/53726
        # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
        #
        # Note that macports toolchains will fail to compile gcc unless
        # the DevSDK is installed due to another gcc build system bug:
        # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80203
        configure.args-append --with-sysroot="${configure.sdkroot}"
    }

[kencu (Ken)]

I broke down the failing command:

:info:build /bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc7/work/build/./gcc/xgcc 
-shared-libgcc 
-B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc7/work/build/./gcc 
-nostdinc++ 
-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc7/work/build/x86_64-apple-darwin18/libstdc++-v3/src 
-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc7/work/build/x86_64-apple-darwin18/libstdc++-v3/src/.libs 
-L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc7/work/build/x86_64-apple-darwin18/libstdc++-v3/libsupc++/.libs 
-B/opt/local/x86_64-apple-darwin18/bin/ 
-B/opt/local/x86_64-apple-darwin18/lib/ 
-isystem /opt/local/x86_64-apple-darwin18/include 
-isystem /opt/local/x86_64-apple-darwin18/sys-include    
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc7/work/gcc-7.3.0/libstdc++-v3/../libgcc 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc7/work/build/x86_64-apple-darwin18/libstdc++-v3/include/x86_64-apple-darwin18 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc7/work/build/x86_64-apple-darwin18/libstdc++-v3/include 
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc7/work/gcc-7.3.0/libstdc++-v3/libsupc++   
-prefer-pic -D_GLIBCXX_SHARED -std=gnu++14 -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once  -fvisibility-inlines-hidden -ffunction-sections -fdata-sections  -frandom-seed=cow-ops.lo -g -O2 -pipe -Os 
-isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk  
-c -o cow-ops.lo /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc7/work/gcc-7.3.0/libstdc++-v3/src/filesystem/cow-ops.cc


:info:build  #include <experimental/bits/lfts_config.h>
:info:build           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

that file is here:

$ locate lfts_config.h
/opt/local/include/gcc/c++/experimental/bits/lfts_config.h
/opt/local/include/gcc5/c++/experimental/lfts_config.h
/opt/local/include/gcc6/c++/experimental/bits/lfts_config.h
/opt/local/include/gcc7/c++/experimental/bits/lfts_config.h

$ port provides /opt/local/include/gcc/c++/experimental/bits/lfts_config.h
/opt/local/include/gcc/c++/experimental/bits/lfts_config.h is provided by: libgcc8

none of which are on a search path that I can see.

There is probably another copy of that file in the headers of the libgcc that is being built.

I'm not quite sure why it's not being found.

Are we messing with the build by overriding the CPP and forcing it to use clang?

# the generated compiler doesn't accept -arch
configure.env-append \
    CPP="${configure.cc} -E" \
    CXXCPP="${configure.cxx} -E"
build.env-append \
    CPP="${configure.cc} -E" \
    CXXCPP="${configure.cxx} -E"

[kencu (Ken)]

Well, now I don't know. I just installed octave from source on my 10.14 box, and although I was expecting trouble, it all installed right through without any issues, including

gcc7
libgcc7
libgcc8

I didn't touch a portfile except aquaterm, and I don't have the command-line tools installed -- just the 10.14 SDK.

[ryandesign (Ryan Carsten Schmidt)]

Ken, as I explained above, there is a problematic interaction between the gcc build system and the APFS filesystem.

[kencu (Ken)]

Just to add a data point, I am using APSF on my 10.14 system, and it built libgcc7 and libgcc8 on my 8-core MacPro with no trouble at all.

I was trying to sort out why Tenomoto's build still failed with only 1 build job, which could not be due to the issue you raised.

I have also noted at least one port where #include <somefile.h> had to be changed to #include "somefile.h" to make it build with Xcode 10, and I wondered if the CPP has changed somewhat.

But as it (surprisingly) builds for me with no trouble at all, I will not be able to debug this locally anyway, so I'll leave it to people who exhibit the issue to sort out.

[dlamija (Muhammed Ramiza)]

ibgcc7 failed to build because it's depend on libgcc8 which is also failed to be build.

according to libgcc8: to successfully buid libgcc8 we need to remove libunwind-headers first.

Tested on mojave with Quard-Core: both libgcc8 and libgcc7 build with no error.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

Just to add a data point, I am using APSF on my 10.14 system, and it built libgcc7 and libgcc8 on my 8-core MacPro with no trouble at all.

gcc5 through gcc9 (and the libgcc's they depend on) also built fine on the Mojave buildbot worker.

I was trying to sort out why Tenomoto's build still failed with only 1 build job, which could not be due to the issue you raised.

True.

[zhulcher]

I completely uninstalled all my ports, and then attempted to install libgcc8. I specifically checked that port libunwind-headers was not on the system. It still failed.

[nicogno (Nicolò Cogno)]

Replying to dlamija:

ibgcc7 failed to build because it's depend on libgcc8 which is also failed to be build.

according to libgcc8: to successfully buid libgcc8 we need to remove libunwind-headers first.

Tested on mojave with Quard-Core: both libgcc8 and libgcc7 build with no error.

I had the same problem trying to install root6 (on MacOS Mojave) that has libgcc7 has a dependency and, as @dlamija said, the steps that solved my problem were:

• uninstall libunwind-headers
• install libcgg8
• install ligcc7 with build.jobs=1

(don't really know if build.jobs=1 was mandatory, but I tried in this way and it worked)

Thank you.

[basmac]

libgcc7-7.3.0_4 fails now after selfupdate, the following is installed on Mojave 10.14.1
  gcc7 @7.3.0_5 (active)
  gcc8 @8.2.0_2 (active)
  gcc_select @0.1_8 (active)
  libgcc @1.0_0 (active)
  libgcc7 @7.3.0_3 (active)
  libgcc8 @8.2.0_2 (active)

[basmac]

after a self update and clean and remove inactive, gcc7 installs now on 10.14.1

bash-3.2# port install gcc7
--->  Computing dependencies for libgcc7
--->  Fetching archive for libgcc7
--->  Attempting to fetch libgcc7-7.3.0_4.darwin_18.x86_64.tbz2 from https://packages.macports.org/libgcc7
--->  Attempting to fetch libgcc7-7.3.0_4.darwin_18.x86_64.tbz2.rmd160 from https://packages.macports.org/libgcc7
--->  Installing libgcc7 @7.3.0_4
--->  Cleaning libgcc7
--->  Computing dependencies for libgcc7
--->  Deactivating libgcc7 @7.3.0_3
--->  Cleaning libgcc7
--->  Activating libgcc7 @7.3.0_4
--->  Cleaning libgcc7
--->  Computing dependencies for gcc7
--->  Fetching archive for gcc7
--->  Attempting to fetch gcc7-7.3.0_6.darwin_18.x86_64.tbz2 from https://packages.macports.org/gcc7
--->  Attempting to fetch gcc7-7.3.0_6.darwin_18.x86_64.tbz2.rmd160 from https://packages.macports.org/gcc7
--->  Installing gcc7 @7.3.0_6
--->  Deactivating gcc7 @7.3.0_5
--->  Cleaning gcc7
--->  Activating gcc7 @7.3.0_6
--->  Cleaning gcc7
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
bash-3.2# port install libgcc7
--->  Computing dependencies for libgcc7
--->  Cleaning libgcc7
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
bash-3.2#