Opened 6 years ago
Closed 2 years 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)
Change History (24)
Changed 6 years ago by miken32 (Michael Newton)
Attachment: | main.log.zip added |
---|
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 follow-up: 4 Changed 6 years ago by pguyot (Paul Guyot)
Indeed, this is related to libunwind. Uninstalling port libunwind-headers
worked for me.
comment:3 follow-up: 8 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 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 Mojave → libgcc8: build fails when libunwind-headers is installed |
---|
comment:8 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.
comment:9 Changed 6 years ago by Dave-Allured (Dave Allured)
Cc: | Dave-Allured added |
---|
comment:10 Changed 6 years ago by maverickwoo (Maverick Woo)
Cc: | maverickwoo added |
---|
comment:11 Changed 6 years ago by thynus
Cc: | thynus added |
---|
comment:12 Changed 6 years ago by hapaguy (Brian Kurt Fujikawa)
Cc: | hapaguy added |
---|
comment:13 Changed 6 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.
comment:14 Changed 6 years ago by iEFdev
Cc: | iEFdev added |
---|
Changed 5 years ago by Jahrme (Jahrme Risner)
Attachment: | gcc8+xcode.pdf added |
---|
Dependency graph of gcc8 with xcode variant.
comment:15 follow-up: 18 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 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 5 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 5 years ago by cooljeanius (Eric Gallager)
Cc: | cooljeanius added |
---|
comment:21 Changed 2 years ago by cjones051073 (Chris Jones)
Resolution: | → fixed |
---|---|
Status: | new → closed |
fixed via declaring a conflict.
build log