Opened 3 months ago

Last modified 5 weeks ago

#57196 new defect

libgcc7 fails to compile/install on macOS Mojave

Reported by: ProgrammingPoet (Gregory Gelfond) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.5.3
Keywords: mojave Cc: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), rlhamil, basmac, Dave-Allured (Dave Allured)
Port: libgcc7

Description

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

Attachments (1)

main.log.zip (744.7 KB) - added by ProgrammingPoet (Gregory Gelfond) 3 months ago.
Zipped version of the log file (original was 10mb)

Download all attachments as: .zip

Change History (18)

Changed 3 months ago by ProgrammingPoet (Gregory Gelfond)

Attachment: main.log.zip added

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

comment:1 Changed 3 months ago by ryandesign (Ryan Schmidt)

Cc: sean@… removed
Keywords: mojave added; libgcc7 install fail removed
Port: py27-matplotlib removed

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.

comment:2 Changed 3 months ago by 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.

comment:3 Changed 3 months ago by 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}"
    }
Last edited 3 months ago by kencu (Ken) (previous) (diff)

comment:4 Changed 3 months ago by 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"

comment:5 Changed 3 months ago by 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.

comment:6 Changed 3 months ago by ryandesign (Ryan Schmidt)

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

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

Last edited 3 months ago by kencu (Ken) (previous) (diff)

comment:8 in reply to:  7 ; Changed 3 months ago by 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.

Last edited 2 months ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:9 Changed 2 months ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: MarcusCalhoun-Lopez added

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

comment:11 Changed 2 months ago by rlhamil

Cc: rlhamil added

comment:12 Changed 2 months ago by 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.

comment:13 in reply to:  8 Changed 2 months ago by 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.

comment:14 Changed 6 weeks ago by basmac

Cc: basmac added

comment:15 Changed 6 weeks ago by 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)

comment:16 Changed 5 weeks ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:17 Changed 5 weeks ago by 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#
Note: See TracTickets for help on using tickets.