Opened 6 years ago

Closed 21 months ago

#57198 closed defect (fixed)

libgcc8: build fails when libunwind-headers is installed

Reported by: miken32 (Michael Newton) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.5.3
Keywords: Cc: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), Dave-Allured (Dave Allured), maverickwoo (Maverick Woo), thynus, hapaguy (Brian Kurt Fujikawa), iEFdev, Jahrme (Jahrme Risner), 3add3287 (3add3287), cooljeanius (Eric Gallager)
Port: libgcc8

Description

Problems appears to be related to libunwind:

:info:build In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/libgcc8/work/gcc-8.2.0/libstdc++-v3/libsupc++/eh_alloc.cc:35:
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/libgcc8/work/gcc-8.2.0/libstdc++-v3/libsupc++/unwind-cxx.h:92:3: error: '_Unwind_Ptr' does not name a type; did you mean '_Unwind_SetIP'?
:info:build    _Unwind_Ptr catchTemp;
:info:build    ^~~~~~~~~~~
:info:build    _Unwind_SetIP
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/libgcc8/work/gcc-8.2.0/libstdc++-v3/libsupc++/unwind-cxx.h:146:3: error: '_Unwind_Ptr' does not name a type; did you mean '_Unwind_SetIP'?
:info:build    _Unwind_Ptr catchTemp;
:info:build    ^~~~~~~~~~~
:info:build    _Unwind_SetIP
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/libgcc8/work/gcc-8.2.0/libstdc++-v3/libsupc++/unwind-cxx.h:320:7: error: '_Unwind_Exception_Class' does not name a type; did you mean '_Unwind_Exception'?
:info:build  const _Unwind_Exception_Class __gxx_primary_exception_class
:info:build        ^~~~~~~~~~~~~~~~~~~~~~~
:info:build        _Unwind_Exception
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc8/libgcc8/work/gcc-8.2.0/libstdc++-v3/libsupc++/unwind-cxx.h:332:7: error: '_Unwind_Exception_Class' does not name a type; did you mean '_Unwind_Exception'?
:info:build  const _Unwind_Exception_Class __gxx_dependent_exception_class
:info:build        ^~~~~~~~~~~~~~~~~~~~~~~
:info:build        _Unwind_Exception

Full log file is attached

Attachments (3)

main.log.zip (596.7 KB) - added by miken32 (Michael Newton) 6 years ago.
build log
gcc8.pdf (47.2 KB) - added by Jahrme (Jahrme Risner) 5 years ago.
Dependency graph of gcc8.
gcc8+xcode.pdf (26.6 KB) - added by Jahrme (Jahrme Risner) 5 years ago.
Dependency graph of gcc8 with xcode variant.

Download all attachments as: .zip

Change History (24)

Changed 6 years ago by miken32 (Michael Newton)

Attachment: main.log.zip added

build log

comment:1 Changed 6 years ago by kencu (Ken)

and yet:

$ port -v installed libgcc8
The following ports are currently installed:
  libgcc8 @8.2.0_0 (active) platform='darwin 18' archs='x86_64' date='2018-09-29T16:50:08-0700'

comment:2 Changed 6 years ago by pguyot (Paul Guyot)

Indeed, this is related to libunwind. Uninstalling port libunwind-headers worked for me.

comment:3 Changed 6 years ago by miken32 (Michael Newton)

Confirmed, and I don't even know why it was installed; it must have been a build dependency for something.

comment:4 in reply to:  2 Changed 6 years ago by dlamija (Muhammed Ramiza)

Replying to pguyot:

Indeed, this is related to libunwind. Uninstalling port libunwind-headers worked for me.

Confirmed!

comment:5 Changed 6 years ago by kencu (Ken)

well -- we could make this a conflicts_build, I guess... but there must be some more elegant method of working this...

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

Cc: MarcusCalhoun-Lopez added

comment:7 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)

Summary: Failed to build libgcc8 on Mojavelibgcc8: build fails when libunwind-headers is installed

comment:8 in reply to:  3 Changed 6 years ago by rlhamil

cctools requires libunwind, and thus libunwind-headers. More strictly, from the cctools Portfile,

if {![variant_isset xcode]} {
    depends_build       port:libunwind-headers
    variant universal conflicts xcode {}
}

Replying to miken32:

Confirmed, and I don't even know why it was installed; it must have been a build dependency for something.

Last edited 6 years ago by rlhamil (previous) (diff)

comment:9 Changed 5 years ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:10 Changed 5 years ago by maverickwoo (Maverick Woo)

Cc: maverickwoo added

comment:11 Changed 5 years ago by thynus

Cc: thynus added

comment:12 Changed 5 years ago by hapaguy (Brian Kurt Fujikawa)

Cc: hapaguy added

comment:13 Changed 5 years ago by kencu (Ken)

It turns out this is actually a duplicate of this ticket 43869.

I haven't explored exactly when/where/how this manifests -- but it clearly bites lots of people and is not going to be fixed in gcc, at least in the older gcc versions. This would workaround it, at least to let people know what the issue is

conflicts_build libunwind-headers

which we actually had before (changeset:125551) for a while, until it was taken out again for reasons I have not prospected.

Last edited 5 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:14 Changed 5 years ago by iEFdev

Cc: iEFdev added

Changed 5 years ago by Jahrme (Jahrme Risner)

Attachment: gcc8.pdf added

Dependency graph of gcc8.

Changed 5 years ago by Jahrme (Jahrme Risner)

Attachment: gcc8+xcode.pdf added

Dependency graph of gcc8 with xcode variant.

comment:15 Changed 5 years ago by Jahrme (Jahrme Risner)

Is there any direction for resolving the issue here?

This appears to be a fairly egregious issue as it is not possible to build gcc5, gcc6, gcc7, or gcc8 from source without intervention. With a fresh install of MacPorts into a custom directory, attempting to install gcc8 fails with the following message:

Error: libgcc9 cannot be built while libunwind-headers is active.
Error: Please forcibly deactivate libunwind-headers, e.g. by running:
Error: 
Error:     sudo port -f deactivate libunwind-headers
Error: 
Error: Then try again. You can reactivate libunwind-headers again later.
Error: Failed to configure libgcc9: libunwind-headers is active
Error: See /opt/mp-2.5.4/var/macports/logs/_opt_mp-2.5.4_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/libgcc9/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port gcc8 failed

This can be reproduced by running the following shell script:

#!/bin/sh

mp_version=2.5.4
mp_prefix=/opt/mp-${mp_version}

# Download and install MacPorts.
export PATH=/bin:/sbin:/usr/bin:/usr/sbin
curl -L -s https://distfiles.macports.org/MacPorts/MacPorts-${mp_version}.tar.bz2 | tar xf -
cd MacPorts-${mp_version}
./configure --without-startupitems --prefix=${mp_prefix} --with-applications-dir=${mp_prefix}/Applications
make
sudo make install

# Update and install gcc8.
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:${mp_prefix}/bin
sudo port selfupdate
sudo port install gcc8

The cause appears to be a result of conflicting dependencies. First, libgcc9 is a dependency of gcc5, gcc6, gcc7, and gcc8. Second, libgcc9 depends on cctools which depends on libunwind-headers. Finally, the Portfile for libgcc9 specifies a conflicts_build conflict with libunwind-headers.

In scripted situations, it seems that there are two relatively simple solutions.

First, pass the +xcode variant which will cause the use of Xcode cctools instead of MacPorts built cctools. This will prevent the current issue as well as greatly reducing the dependency graph (see the two attached PDFs), but this emits a warning and is suggested against in the Portfile for gcc9 (where libgcc9 is defined).

Second, install gcc8 (or others) in multiple steps; for example, instead of running sudo port install gcc8 a user would run:

sudo port install cctools
sudo port uninstall libunwind-headers
sudo port install gcc8

I do not know the proper resolution; perhaps there needs to be a mechanism that allows for the deactivation of a port during install. This would require checks that the port being deactivated is not currently "in use".

Attached are the dependency graphs for gcc8 and gcc8 +xcode which illustrate the dependencies discussed above.

comment:16 Changed 5 years ago by Jahrme (Jahrme Risner)

Cc: Jahrme added

comment:17 Changed 5 years ago by 3add3287 (3add3287)

Cc: 3add3287 added

comment:18 in reply to:  15 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to Jahrme:

Is there any direction for resolving the issue here?

You've described the current situation and the available workarounds.

I do not know the proper resolution; perhaps there needs to be a mechanism that allows for the deactivation of a port during install.

We have such a mechanism. It's called the "deactivate hack". But we don't use it in scenarios like this one, because...

This would require checks that the port being deactivated is not currently "in use".

...MacPorts has no way of knowing whether a user is using the files installed by a port. Instead, in situations like this, we use the conflicts_build portgroup, which is what prints the message you showed above which told you what port you need to deactivate to proceed. By asking the user to do this, this ensures the user understands that that port will be deactivated and that its files will be unavailable.

comment:19 Changed 4 years ago by cooljeanius (Eric Gallager)

This is gcc upstream's bug 78251: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251

comment:20 Changed 4 years ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added

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

Resolution: fixed
Status: newclosed

fixed via declaring a conflict.

Note: See TracTickets for help on using tickets.