clang-3.8 and later: All compilers are either blacklisted or unavailable

[ryandesign (Ryan Carsten Schmidt)]

clang 3.8 and later cannot be compiled on 10.8 (without LibcxxOnOlderSystems).

$ port info --name --version clang-{3.7,3.8,3.9,4.0,5.0,devel}
version: 3.7.1
name: clang-3.7
--
Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option
version: 3.8.1
name: clang-3.8
--
Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option
version: 3.9.1
name: clang-3.9
--
Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option
version: 4.0.1
name: clang-4.0
--
Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option
version: 5.0.0
name: clang-5.0
--
Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option
version: devel-r319156
name: clang-devel

Could clang-3.7 be added to compiler.fallback to accommodate this?

I know you've been maintaining the fallback list in MacPorts base, so maybe you can think about whether it would be reasonable to add clang-3.7 to the fallback in base, or whether it should go individually into each of those clang ports.

[jeremyhu (Jeremy Huddleston Sequoia)]

macports-clang-3.7 is in the fallback list in base but only if the stdlib is libc++ (since the port itself requires C++11 and libc++):

    if {${configure.cxx_stdlib} eq "libc++"} {
        # clang-3.5+ require libc++
        lappend compilers macports-clang-5.0 macports-clang-4.0

        if {${os.major} < 17} {
            # The High Sierra SDK requires a toolchain that can apply nullability to uuid_t
            lappend compilers macports-clang-3.9
        }

        if {${os.major} < 16} {
            # The Sierra SDK requires a toolchain that supports class properties
            lappend compilers macports-clang-3.7
        }
    }

I suppose we could make that check based on [file exists /usr/lib/libc++.dylib] || ${configure.cxx_stdlib} eq "libc++" since the port itself forces the use of libc++ even when it's not default (Lion / ML).

Thoughts?

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu:

I suppose we could make that check based on [file exists /usr/lib/libc++.dylib] || ${configure.cxx_stdlib} eq "libc++" since the port itself forces the use of libc++ even when it's not default (Lion / ML).

That could be reasonable. If a port requires libc++, it will set configure.cxx_stdlib libc++ and add the port:libcxx dependency, so that should work.

[kencu (Ken)]

clang 3.8 no longer exists in MacPorts

[kencu (Ken)]

overeager.

[kencu (Ken)]

In c35b1701f54cb5a048f8821641d8ecdf524bf989/macports-ports (master):

clang-6.0: fix build on leopard Intel

work around compiler_rt build error due to
no libdispatch on Leopard

disables santizer_common which presently doesn't build on Leopard

add fallback to clang-3.7 and clang-3.9

closes: #55444
closes: #57694

[kencu (Ken)]

this was closed by a commit reference, but is not yet fully solved for all the clangs