Opened 6 years ago

Closed 4 years ago

#57196 closed defect (fixed)

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) 6 years ago.
Zipped version of the log file (original was 10mb)

Download all attachments as: .zip

Change History (19)

Changed 6 years ago by ProgrammingPoet (Gregory Gelfond)

Attachment: main.log.zip added

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

comment:1 Changed 6 years ago by ryandesign (Ryan Carsten 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 5 years 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 5 years ago by kencu (Ken)

There is a comment to that effect in the gcc* Portfiles:

        # 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
        #
Version 0, edited 5 years ago by kencu (Ken) (next)

comment:4 Changed 5 years 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 5 years 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 5 years ago by ryandesign (Ryan Carsten Schmidt)

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

comment:7 Changed 5 years 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 5 years ago by kencu (Ken) (previous) (diff)

comment:8 in reply to:  7 ; Changed 5 years 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 5 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:9 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: MarcusCalhoun-Lopez added

comment:10 in reply to:  7 Changed 5 years ago by 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.

comment:11 Changed 5 years ago by rlhamil

Cc: rlhamil added

comment:12 Changed 5 years 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 5 years 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 5 years ago by basmac

Cc: basmac added

comment:15 Changed 5 years 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 years ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:17 Changed 5 years 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#

comment:18 Changed 4 years ago by cjones051073 (Chris Jones)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.