Opened 8 years ago
Closed 4 years ago
#52091 closed defect (fixed)
cctools, ld64: Removing +llvm33 variant introduces circular dependencies on Leopard due to llvm-3.4 failing to build with Xcode 3.1's gcc
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.4 |
Keywords: | leopard | Cc: | mojca (Mojca Miklavec) |
Port: | cctools, ld64 |
Description
cctools and ld64 cannot be installed on Leopard because they eventually depend on themselves.
https://build.macports.org/builders/ports-10.5_ppc_legacy-builder/builds/2
---> Dependencies to be installed: cctools llvm-3.4 apple-gcc42 ld64 ld64-127 libgcc-devel DEBUG: dlist_eval: all entries in dependency list have unsatisfied dependencies; can't process Error: The following dependencies were not installed: cctools llvm-3.4 apple-gcc42 ld64 ld64-127 libgcc-devel To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port gcc7 failed
cctools depends on llvm-3.4, which depends on apple-gcc42, which depends on cctools.
ld64 depends on ld64-127, which depends on llvm-3.4, which depends on apple-gcc42, which depends on ld64.
Change History (19)
comment:1 Changed 8 years ago by larryv (Lawrence Velázquez)
comment:2 follow-up: 7 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Yeah, there's not really a way to do that short of rolling up a bootstrap package which lays down a toolchain in /opt/macports-bootstrap-toolchain or something similar. Of course, base would need to be updated to know how to use that toolchain (and make it part of the default toolchains, perhaps as macports-bootstrap-gcc and macports-bootstrap-clang). I'm not opposed to doing that and have considered doing so myself in the past. If that seems like it would be worthwhile, I'll see what I can do to come up with such a package.
comment:3 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
We could also make 'apple-gcc42 +bootstrap' into a subport instead of a variant if that is desired.
comment:4 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)
I like the subport idea, if apple-gcc42 now needs the bootstrap stuff on Leopard as well. I thought it only applied to Tiger, based on stuff like:
$ port variants apple-gcc42 apple-gcc42 has the variants: bootstrap: Variant to break a dependency cycle on Tiger by first building an apple-gcc42 using host ld and cctools gpl3: Merge in changes from gcc-4.2.4 universal: Build for multiple architectures
comment:5 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Ah, ok. That was true in the past but isn't now.
In r135187, I added Leopard's apple-gcc to the blacklist for llvm-3.4, so to build llvm-3.4, we need either apple-gcc42 or clang-3.3.
In r150763 r150764, I removed the +llvm33 variant from cctools and ld64 and made the default on Leopard be +llvm34.
I think the simplest solution for now might be to revert r150763 and r150764.
comment:7 Changed 8 years ago by mojca (Mojca Miklavec)
Replying to jeremyhu@…:
Yeah, there's not really a way to do that short of rolling up a bootstrap package which lays down a toolchain in /opt/macports-bootstrap-toolchain or something similar. Of course, base would need to be updated to know how to use that toolchain (and make it part of the default toolchains, perhaps as macports-bootstrap-gcc and macports-bootstrap-clang). I'm not opposed to doing that and have considered doing so myself in the past. If that seems like it would be worthwhile, I'll see what I can do to come up with such a package.
We started discussing using an external compiler for libc++
builds in the past, but Ryan warned against that idea because some compilers might leave traces (we could end up with a library linking against /opt/macports-bootstrap-toolchain/lib/libsomething.dylib
or any other weird situation).
The problem we'll have on the libc++
build slaves will be that clang-3.x
and all of its dependencies will have to be activated and deactivated over and over again.
comment:8 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
I reverted back to +llvm33 as the default in r152009. Leaving this open as I want to find a better solution.
comment:9 Changed 8 years ago by mojca (Mojca Miklavec)
Jeremy, why not using
if {${os.major} < 11} { variant llvm34 conflicts llvm33 llvm38 llvm39 llvmdev description {Use llvm-3.4 for libLTO and llvm-mc} { set llvm_version 3.4 depends_lib-append port:llvm-${llvm_version} set has_llvm_nm false set has_llvm_size false } }
instead of
variant llvm34 conflicts llvm33 llvm38 llvm39 llvmdev description {Use llvm-3.4 for libLTO and llvm-mc} { set llvm_version 3.4 depends_lib-append port:llvm-${llvm_version} set has_llvm_nm false set has_llvm_size false if {${os.major} >= 11} { ui_error "The +llvm34 variant is not supported on Lion and later." error "Invalid variant selected" } }
? I guess that conflicting variants could be adjusted with a loop, but then again conflicts with non-existing variants probably don't hurt anyway.
Similar for ld64
:
-
devel/ld64/Portfile
42 42 sha256 307f73678a3e5c9ed4d1bcf77da7399d84efac32916c5df6cd477c3b5c36f953 43 43 44 44 45 if {${os.major} < 14} { 45 46 subport ld64-97 { 46 47 # XCode 3.2.6 47 48 version 97.17 … … 62 63 ld64-97-no-Availability.h.patch \ 63 64 ld64-97-BaseAtomImplicitDecl.patch \ 64 65 ld64-97-no-ppc-thread_status.patch 65 66 if {${os.major} >= 14} {67 pre-fetch {68 ui_error "$subport is not supported on Yosemite or later."69 error "unsupported platform"70 }71 }72 66 } 67 } 73 68 74 69 subport ld64-127 { 75 70 # XCode 4.2 … … 94 89 ld64-ppc-9610466.patch 95 90 } 96 91 92 if {${os.major} > 9} { 97 93 subport ld64-136 { 98 94 # XCode 4.6 99 95 version 136 … … 113 109 if {${configure.cxx_stdlib} eq "libstdc++"} { 114 110 patchfiles-append ld64-136-hash_set.patch 115 111 } 116 117 if {${os.major} <= 9} {118 pre-fetch {119 ui_error "$subport is not supported on Leopard or earlier. It requires the blocks runtime."120 error "unsupported platform"121 }122 }123 112 } 113 } 124 114 115 if {${os.major} > 9} { 125 116 subport ld64-236 { 126 117 # XCode 5.1 127 118 version 236.3 … … 146 137 if {${configure.cxx_stdlib} eq "libstdc++"} { 147 138 patchfiles-append ld64-236-hash_set.patch 148 139 } 149 150 if {${os.major} <= 9} {151 pre-fetch {152 ui_error "$subport is not supported on Leopard or earlier. It requires the blocks runtime."153 error "unsupported platform"154 }155 }156 140 } 141 } 157 142 143 # requires a C++11 runtime 144 if {[file exists /usr/lib/libc++.dylib]} { 158 145 subport ld64-latest { 159 146 # XCode 7.3.1 160 147 version 264.3.102 … … 180 167 configure.cxxflags-append -std=c++11 181 168 182 169 supported_archs i386 x86_64 183 184 pre-fetch {185 if {![file exists /usr/lib/libc++.dylib]} {186 ui_error "$name requires a C++11 runtime, which your configuration does not allow"187 error "unsupported configuration"188 }189 }190 170 } 171 } 191 172 192 173 subport ld64-xcode { 193 174 version 1
Anyway, I'm not sure if it's just because I made a partial update of your commits (I only checked out ld64
and ran portindex
), but this fails for me already during the portindex
phase:
Adding port devel/ld64 Error: The +llvm34 variant is not supported on Lion and later. Error: ld64: Error executing llvm34: Invalid variant selected Failed to parse file devel/ld64/Portfile with subport 'ld64-97': Error evaluating variants
comment:10 follow-up: 12 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Because that will cause portindex to be created differently based on which OS you create it on.
comment:11 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
You should 'sudo port -v -s upgrade ld64-97 -llvm34.
comment:12 follow-up: 13 Changed 8 years ago by mojca (Mojca Miklavec)
Replying to jeremyhu@…:
Because that will cause portindex to be created differently based on which OS you create it on.
I'm not familiar with the infrastructure, but judging from Ryan's email:
Currently, there is only one PortIndex file generated on the server, and published to the rsync server, for each OS name/version/endianness combination.
I guess that except perhaps for
if {[file exists /usr/lib/libc++.dylib]} {
(until we make a separate PortIndex
, in particular on < 10.7) this should work.
comment:13 Changed 8 years ago by larryv (Lawrence Velázquez)
It would work technically, but it introduces implicit behavior (different variants visible on different systems) that might be considered undesirable.
comment:14 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)
I don't think we have a policy on that: is it better to only show variants on systems where they can be used, or show them everywhere and make them error when they're not applicable? I think we have examples of both currently in the port tree.
comment:15 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
comment:16 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Summary: | cctools, ld64: circular dependencies → cctools, ld64: Removing +llvm33 variant introduces circular dependencies on Leopard due to llvm-3.4 failing to build with Xcode 3.1's gcc |
---|
comment:17 Changed 8 years ago by mojca (Mojca Miklavec)
I opened a new ticket for removing the variants: #52128.
I didn't understand why
sudo port -v -s upgrade ld64-97 -llvm34
because I don't have ld64-97
installed at all. But I just realized that I have
ld64-latest @264.3.102_2+llvm34 (active)
which the next upgrade should fix.
More likely the reason had at least something to do with #52127 though. I no longer experience the error now.
comment:18 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
cctools removed the +llvm33 variant in 373d97e8/macports-ports in a way that should not make this be a problem (essentially dropping support for LTO on Leopard by default).
You have to use
apple-gcc42 +bootstrap
here, although I don’t know how you’d automate it on a buildslave.