mpv @0.33.0_2+audiocd+bluray+bundle+dvd+libarchive+network+opengl+osd+python39+rubberband: cannot convert value of type 'CALayerContentsFormat' to specified type 'String'

[JDLH (Jim DeLaHunt)]

Attempting to install or upgrade mpv @0.33.0_2+audiocd+bluray+bundle+dvd+libarchive+network+opengl+osd+python39+rubberband fails when compiling swift_compat.swift with 3 instances of this compile error:

cannot convert value of type 'CALayerContentsFormat' to specified type 'String'

The main.log is attached. The interesting part appears to be:

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_mpv/mpv/work/mpv-player-mpv-d5ae9f7/osdep/macos/swift_compat.swift:29:38: error: cannot convert value of type 'CALayerContentsFormat' to specified type 'String'
:info:build     static let RGBA16Float: String = kCAContentsFormatRGBA16Float
:info:build                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
:info:build                                                                  .rawValue
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_mpv/mpv/work/mpv-player-mpv-d5ae9f7/osdep/macos/swift_compat.swift:30:36: error: cannot convert value of type 'CALayerContentsFormat' to specified type 'String'
:info:build     static let RGBA8Uint: String = kCAContentsFormatRGBA8Uint
:info:build                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
:info:build                                                              .rawValue
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_mpv/mpv/work/mpv-player-mpv-d5ae9f7/osdep/macos/swift_compat.swift:31:36: error: cannot convert value of type 'CALayerContentsFormat' to specified type 'String'
:info:build     static let gray8Uint: String = kCAContentsFormatGray8Uint
:info:build                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
:info:build                                                              .rawValue
…[snip]…
:info:build Build failed
:info:build  -> task in 'osdep/macOS_swift.o,osdep/macOS_swift.h,osdep/macOS_swift.swiftmodule' failed with exit status 1: 
:info:build 	{task 4549021872: osdep/macOS_swift.o,osdep/macOS_swift.h,osdep/macOS_swift.swiftmodule log_helper.swift,libmpv_helper.swift,mpv_helper.swift,swift_extensions.swift,swift_compat.swift,remote_command_center.swift,common.swift,view.swift,window.swift,title_bar.swift,cocoa_cb_common.swift,gl_layer.swift -> macOS_swift.o,macOS_swift.h,macOS_swift.swiftmodule}
:info:build ''
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_mpv/mpv/work/mpv-0.33.0" && /opt/local/bin/python3.9 ./waf build -v --verbose 

I am compiling with macports 2.6.4 on macOS 10.13.6 High Sierra. I saw the same results with both the +python38 and +python39 variants of mpv.

[JDLH (Jim DeLaHunt)]

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_mpv/mpv/main.log

[i0ntempest]

Same errors as in #62112. Can you try editing out the conditions for use_xcode yes and try again?

[JDLH (Jim DeLaHunt)]

Thank you for the prompt response!

Unfortunately it did not seem to work. I edited the portfile to comment out the use of use_xcode as follows:

    # Should eliminate most swift (module) related problems
    # @@@ prevent this code per #62177 and #62112.
    # if {[vercmp ${xcodeversion} 9.1] >= 0 || ${os.major} >= 16} {
    #     use_xcode yes
    # }

The build failed with the same error message as before: error: cannot convert value of type 'CALayerContentsFormat' to specified type 'String'.

[i0ntempest]

Replying to JDLH:

Thank you for the prompt response!

Unfortunately it did not seem to work. I edited the portfile to comment out the use of use_xcode as follows:

    # Should eliminate most swift (module) related problems
    # @@@ prevent this code per #62177 and #62112.
    # if {[vercmp ${xcodeversion} 9.1] >= 0 || ${os.major} >= 16} {
    #     use_xcode yes
    # }

The build failed with the same error message as before: error: cannot convert value of type 'CALayerContentsFormat' to specified type 'String'.

I should have said that more clearly, I meant editing out the CONDITIONS and leave use_xcode yes in, that is forcing use_xcode yes on all OSes. Commandline tools (and mixing Xcode and CLT) are known to cause swift related problems like this.

[JDLH (Jim DeLaHunt)]

Ah, I get it. Sorry about that.

Unfortunately, it still seems not to work. I edited the portfile to set use_xcode yes unconditionally:

    # Should eliminate most swift (module) related problems
    # @@@ unconditionally set this value per #62177 and #62112.
    # @@@ if {[vercmp ${xcodeversion} 9.1] >= 0 || ${os.major} >= 16} {
        use_xcode yes
    # @@@}

The build failed with the same error message as before: error: cannot convert value of type 'CALayerContentsFormat' to specified type 'String'.

[i0ntempest]

In that case I'd recommend switching to Xcode 9.4.1, which matches your OS (and is what 10.13 buildbot uses). I'd recommend sticking with Xcode 9 on 10.13 unless you need Xcode 10 for specific reasons.

[kencu (Ken)]

Jim, take a moment to make sure that your xcode and CLTs exactly match (same clang version).

Almost 100% of MacPorts users on 10.13 are using Xcode 10+ according to our stats, and if you do downgrade to Xcode 9, other things will fail to build.

Or be happy with mpv from the buildbot...

[JDLH (Jim DeLaHunt)]

@i0ntempet and @kencu, I appreciate your taking an interest.

Regarding Xcode versions, I hear you saying different things: switch to Xcode 9.4.1, vs use Xcode 10+ as do almost 100% of macports users.

According to the version check script at XcodeVersionInfo , my XCode and clang version numbers match what that page lists for macOS10.13, Xcode 10.1:

• Xcode: Build version 10B61
• clang: Apple LLVM version 10.0.0 (clang-1000.11.45.5)

I'm not sure if that counts as "your xcode and CLTs exactly match (same clang version)". There are several version numbers in this soup: "10.1" (Xcode.app), "10B61" (Xcode build version), "10.0.0" (clang), "clang-1000.11.45.5" (clang), "2349" (result of xcode-select --version), "10.1.0.0.1.1539992718" (result of pkgutil --pkg-info=com.apple.pkg.CLTools_Executables).

And:

Or be happy with mpv from the buildbot...

I might well be happy with mpv from the buildbot. Which mpv does the buildbot provide?

I browsed around at ​https://build.macports.org/ , but I couldn't find something which said, "the ​https://build.macports.org/builders/ports-10.13_x86_64-builder built mpv@0.33.0_2+foo+bar+baz".

I don't have strong feelings about which options I use. I just asked macports for "mpv", and macports gave me "mpv @0.33.0_2+audiocd+bluray+bundle+dvd+libarchive+network+opengl+osd+python39+rubberband". Should I be asking for something different?

[JDLH (Jim DeLaHunt)]

Apropos of trying to get mpv from the buildbot: There is a URL https://ywg.ca.packages.macports.org/mirror/macports/packages/mpv/mpv-0.32.0_1%2Baudiocd%2Bbluray%2Bbundle%2Bdvd%2Blibarchive%2Bnetwork%2Bopengl%2Bosd%2Bpython38%2Brubberband.darwin_17.x86_64.tbz2.

I ran the command which attempts to install exactly that port:

sudo port install mpv @0.32.0_1+audiocd+bluray+bundle+dvd+libarchive+network+opengl+osd+python38+rubberband

Instead, macports seemed to give me @0.33.0_2:

Portfile changed since last build; discarding previous state.
--->  Computing dependencies for mpv
--->  Fetching archive for mpv
--->  Attempting to fetch mpv-0.33.0_2+audiocd+bluray+bundle+dvd+libarchive+network+opengl+osd+python38+rubberband.darwin_17.x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/mpv
… [snip] …

… so I don't know how to ask for "mpv from the buildbot".

[kencu (Ken)]

If you look at a page such as this <​https://ports.macports.org/port/libffi/stats?days=30&days_ago=0> you can see the xcode versions installed by users on various systems. I picked libffi to look at as it's commonly installed. In the section of the display where it shows xcode version by system, you can see that almost all users who submitted stats for macOS 10.13 have Xcode 10.1 installed.

When I say make sure your Xcode and your CLTs match, I mean to check that your system is coherent and not buggered by a mismatch between toolchains, which is a bit too easy to have happen. Specifically, these three things should match:

% /Library/Developer/CommandLineTools/usr/bin/clang -v
Apple clang version 12.0.0 (clang-1200.0.32.29)

% /usr/bin/clang -v
Apple clang version 12.0.0 (clang-1200.0.32.29)

% /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -v
Apple clang version 12.0.0 (clang-1200.0.32.29)

Now obviously those numbers are from my Catalina machine, but whatever yours are, they should all be the exact same. If they are not, you're out of sync.

Finally, when I say use the the "mpv from the buildbot", what I mean is to take the default version, and it *should* just download a prebuilt binary that you don't have to build, and you're on your way with no muss, no fuss.

Not every port has a prebuilt binary. Unlike some other package managers, MacPorts takes the whole license thing extremely seriously, especially a very irritating and stupid license issue with openssl that permeates way too many builds.

but if you go here:

<​http://packages.macports.org/mpv/>

you can see that there are prebuilt binaries for many systems for mpv.

If what you ask for (the default) matches what the buildbot supplies <​http://packages.macports.org/mpv/mpv-0.32.0_1+audiocd+bluray+bundle+dvd+libarchive+network+opengl+osd+python38+rubberband.darwin_17.x86_64.tbz2> then you won't have to build anything.

You will just download the one Ryan built, on his nice, clean, nobody ever touches it, perfectly set up, system :>

By the time we're done with you, JDLH, you are going to know more about MacPorts than you ever cared to know !

[kencu (Ken)]

OH -- and mpv has a very confusing array of variants that cause (IMHO) nothing but trouble for people, and we'd do well to get rid of 99% of them. That would make the probability that you'd hit a prebuilt binary from the buildbot much higher...

[kencu (Ken)]

My message was finished when yours came through, but I see that mpv has been updated since the last one hit the buildbot, to 33.

It looks like the buildbot built it <​https://build.macports.org/builders/ports-10.13_x86_64-builder/builds/102124/steps/install-port/logs/stdio>

I am not sure -- at this second -- exactly why it's not visible on the buildbot just yet. Presumably, it will show up there sooner or later...

[acrostich (Panda Mery)]

Thank Ken for hinting at the source of this problem (similarly upgrading mpv on Mojave kept failing). Following your suggestion, I checked all three versions of clang and /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang was older (Apple LLVM version 10.0.1 (clang-1001.0.46.4)) than the two other clang (11C504) (Apple clang version 11.0.0 (clang-1100.0.33.17)), which matched the installed XCode Version 11.3.1.

What was left as an exercise was how to upgrade the Developer/ version. Removing the directory and doing an xcode-select --install reinstalled the old version.

What eventually worked and may help others was to download the corresponding Command Line Tools package from ​https://developer.apple.com/download/more/

[JDLH (Jim DeLaHunt)]

When I say make sure your Xcode and your CLTs match, I mean to check that your system is coherent and not buggered by a mismatch between toolchains, which is a bit too easy to have happen. Specifically, these three things should match:

Here are my versions for those tools:

% /Library/Developer/CommandLineTools/usr/bin/clang -v
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
% /usr/bin/clang -v
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -v
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% whereis clang
/usr/bin/clang

So, my /Library/Developer/CommandLineTools/usr/bin/clang is a bit older than /usr/bin/clang, but the latter clang matches the clang within Xcode.app, and the latter is what gets used if no path is specified.

How do I change my /Library/Developer/CommandLineTools/usr/bin/clang to be consistent with the other two?

[JDLH (Jim DeLaHunt)]

Inspired by @acrostich, I tried the following to upgrade /Library/Developer/CommandLineTools/usr/bin/clang:

% cd /Library/Developer 
% sudo rm -r CommandLineTools
Password:
% xcode-select --install
xcode-select: note: install requested for command line developer tools
Nothung% ls -lF                
total 0
drwxr-xr-x@ 7 root  wheel  224  2 Sep  2019 3.1/
drwxr-xr-x  5 root  admin  160 31 Jan 12:28 CommandLineTools/
drwxr-xr-x  4 root  admin  128 17 Oct  2018 PrivateFrameworks/

But, that just reinstalled the previous version:

% /Library/Developer/CommandLineTools/usr/bin/clang -v
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

So, I went to ​https://developer.apple.com/download/more/ , searched for "Xcode 10.1", downloaded and installed "​Command Line Tools (macOS 10.13) for Xcode 10.1".

Unfortunately, that also gave me the same version of the /Library/Developer/CommandLineTools:

% /Library/Developer/CommandLineTools/usr/bin/clang -v
Apple LLVM version 10.0.0 (clang-1000.10.44.4)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

…and sudo port install mpv fails with the same error.

Interestingly, sudo port install mpv appears to try installing mpv @0.33.0_2+audiocd+bluray+bundle+dvd+libarchive+network+opengl+osd+python39+rubberband. I do not see a corresponding buildbot port in ​http://packages.macports.org/mpv/ , nor in the mirrors like ​https://ywg.ca.packages.macports.org/mirror/macports/packages/mpv . But if I look at the logs linked to from ​https://build.macports.org/builders/ports-10.13_x86_64-builder/builds/102124 , everything seemed to run without error.

[kencu (Ken)]

well you've done all the right things now.

I suspect the clangs can be a minor decimal point different between xcode and clts (but not the generational 100s different).

It might be that mpv won't build with xcode10 on 10.13. I will try it.

Why it's not on the buildbot is unclear, but presumably we've run afoul of that ridiculous openssl license hiccup.

I'll report back.

[kencu (Ken)]

Xcode 10.1 comes with the MacOSX10.14.sdk.

If MacPorts does not find the MacOS10.13.sdk on 10.13, it then drops back to use MacOS.sdk.

In Xcode 10.1, MacOSX.sdk is a symlink to the MacOSX10.14.sdk.

In mpv, they have generated a "swift compatibility module, here:

osdep/macos/swift_compat.swift

In that file, there is this block

#if !HAVE_MACOS_10_14_FEATURES
extension NSAppearance.Name {
    static let darkAqua: NSAppearance.Name = NSAppearance.Name(rawValue: "NSAppearanceNameDarkAqua")
    static let accessibilityHighContrastAqua: NSAppearance.Name = NSAppearance.Name(rawValue: "NSAppearanceNameAccessibilityAqua")
    static let accessibilityHighContrastDarkAqua: NSAppearance.Name = NSAppearance.Name(rawValue: "NSAppearanceNameAccessibilityDarkAqua")
    static let accessibilityHighContrastVibrantLight: NSAppearance.Name = NSAppearance.Name(rawValue: "NSAppearanceNameAccessibilityVibrantLight")
    static let accessibilityHighContrastVibrantDark: NSAppearance.Name = NSAppearance.Name(rawValue: "NSAppearanceNameAccessibilityVibrantDark")
}

@available(OSX 10.12, *)
extension String {
    static let RGBA16Float: String = kCAContentsFormatRGBA16Float
    static let RGBA8Uint: String = kCAContentsFormatRGBA8Uint
    static let gray8Uint: String = kCAContentsFormatGray8Uint
}
#endif

this compatibility block seems to be what is generating the error. I don't see exactly where this MACRO gets defined during the build of mpv:

HAVE_MACOS_10_14_FEATURES

But disabling that by doing this:

- #if !HAVE_MACOS_10_14_FEATURES
+ #if false
extension NSAppearance.Name {

and mpv builds through without trouble on 10.13 using the Xcode 10.14 SDK.

$ port -v installed mpv
The following ports are currently installed:
  mpv @0.33.0_2+audiocd+bluray+bundle+dvd+libarchive+network+opengl+osd+python39+rubberband (active) platform='darwin 17' archs='x86_64' date='2021-01-31T18:23:56-0800'

One solution to this (not the one I will use) would be to drop 10.13 back to Xcode 9, which came with the 10.13 SDK.

Another solution is to make a very trivial patch to change that blocker the way I did.

Another solution would be to find out how and why HAVE_MACOS_10_14_FEATURES is being defined, and decide if it should be defined if you are building with the MacOSX10.14.sdk, which I would hazard that it should, but I don't do a whole lot of swift.

Another solution (the one I did on my other 10.13 system) is to get the MacOS10.13.sdk from Xcode 9, and put it next the the MacOS10.14.sdk in the proper location in Xcode, and in the similar proper location in the CLTs. You might have one copy of the MacOSX10.13.sdk in, say, /Library/Developer/SavedSDKs/ and then put a symlink into Xcode 10.1 and into the CLTs in the proper place.

Any of these options should work for you. All of them have their plusses and minuses. Please pick the one you like best.

For the maintainer, I leave it to you to decide which, if any, of these you prefer to recommend.

[JDLH (Jim DeLaHunt)]

Ken, thank you very much for this investigation.

I will look into these workarounds one by one on my macOS 10.13.6 High Sierra system.

I have already discovered that I have no directory /Library/Developer/SavedSDKs/. I do see a MacOS10.14.sdk at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk@ and /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk@.

The project ​https://github.com/phracker/MacOSX-SDKs claims to have archived copies of older Apple SDKs, including ​https://github.com/phracker/MacOSX-SDKs/tree/master/MacOSX10.13.sdk . I'm not sure how I go about deciding if I trust that data. An Ask Different answer to "​How can I download and install macOS 10.12 SDK?" recommends it, so there's that.

More reports when I get to them. Thanks again, Ken.

[i0ntempest]

If you don't trust the SDKs in that repo, there's ​http://xcodereleases.com to download any version of Xcode. SDKs can be extracted from Xcode app bundle. Release versions need a free Apple dev account and beta versions need a paid one. Looks like the root of the problem is mpv incorrectly enabling features only available on 10.14 on 10.13 because of the presence of 10.14 SDK. Idk if the upstream will accept this as a bug, but for now I may make a conditional patch based on Ken's discovery.

[kencu (Ken)]

Glad to help.

For me, it seems HAVE_MACOS_10_14_FEATURES should be defined if you are building with the MacOSX10.14.sdk (somehow), but it is not.

In a traditional build, I would instead use:

MAC_OS_X_VERSION_MAX_ALLOWED >= 101400

to test if you're building with the MacOSX10.14.sdk.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #62323.