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 in reply to:  description Changed 8 years ago by larryv (Lawrence Velázquez)

You have to use apple-gcc42 +bootstrap here, although I don’t know how you’d automate it on a buildslave.

comment:2 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:6 Changed 8 years ago by mojca (Mojca Miklavec)

Cc: mojca@… added

Cc Me!

comment:7 in reply to:  2 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

     
    4242                    sha256  307f73678a3e5c9ed4d1bcf77da7399d84efac32916c5df6cd477c3b5c36f953
    4343
    4444
     45if {${os.major} < 14} {
    4546subport ld64-97 {
    4647    # XCode 3.2.6
    4748    version             97.17
     
    6263        ld64-97-no-Availability.h.patch \
    6364        ld64-97-BaseAtomImplicitDecl.patch \
    6465        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     }
    7266}
     67}
    7368
    7469subport ld64-127 {
    7570    # XCode 4.2
     
    9489        ld64-ppc-9610466.patch
    9590}
    9691
     92if {${os.major} > 9} {
    9793subport ld64-136 {
    9894    # XCode 4.6
    9995    version             136
     
    113109    if {${configure.cxx_stdlib} eq "libstdc++"} {
    114110        patchfiles-append   ld64-136-hash_set.patch
    115111    }
    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     }
    123112}
     113}
    124114
     115if {${os.major} > 9} {
    125116subport ld64-236 {
    126117    # XCode 5.1
    127118    version             236.3
     
    146137    if {${configure.cxx_stdlib} eq "libstdc++"} {
    147138        patchfiles-append   ld64-236-hash_set.patch
    148139    }
    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     }
    156140}
     141}
    157142
     143# requires a C++11 runtime
     144if {[file exists /usr/lib/libc++.dylib]} {
    158145subport ld64-latest {
    159146    # XCode 7.3.1
    160147    version             264.3.102
     
    180167    configure.cxxflags-append -std=c++11
    181168
    182169    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     }
    190170}
     171}
    191172
    192173subport ld64-xcode {
    193174    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
Last edited 8 years ago by mojca (Mojca Miklavec) (previous) (diff)

comment:10 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 in reply to:  10 ; 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 in reply to:  12 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)

FWIW, the variant-exclusions are being addressed by hiding them on newer OS versions (r152081, with r152082 reverting the accidental change to wiggle).

This is being left open to still consider the apple-gcc42-bootstrap subport option as a way of avoiding the need for the +llvm33 variant.

comment:16 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Summary: cctools, ld64: circular dependenciescctools, 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).

So on Leopard and Tiger, we should be able to build cctools without depending on llvm, but we still have the issue with ld64.

Last edited 8 years ago by jeremyhu (Jeremy Huddleston Sequoia) (previous) (diff)

comment:19 Changed 4 years ago by kencu (Ken)

Resolution: fixed
Status: newclosed

fixed

Note: See TracTickets for help on using tickets.