mpv: fatal error encountered while reading from module 'Foundation'

[ShadSterling (Shad Sterling)]

I guess this is another bizarre swift error

:info:build 1.  Apple Swift version 5.5.1 (swiftlang-1300.0.31.4 clang-1300.0.29.6)
:info:build 2.  
:info:build 3.  While evaluating request ExecuteSILPipelineRequest(Run pipelines { Mandatory Diagnostic Passes + Enabling Optimization Passes } on SIL for macOS_swift.macOS_swift)
:info:build 4.  While running pass #12803 SILModuleTransform "MandatorySILLinker".
:info:build 5.  While deserializing SIL function "free"
:info:build 6.  *** DESERIALIZATION FAILURE ***
:info:build module 'Foundation' with full misc version '5.5.1(5.5.1)/Apple Swift version 5.5.1 (swiftlang-1300.0.31.4 clang-1300.0.29.6)'
:info:build top-level value not found
:info:build Cross-reference to module 'Darwin'
:info:build ... free
:info:build ... with type (UnsafeMutableRawPointer) -> ()

[i0ntempest]

I got a similar (or identical) error yesterday before upgrading my Hack to Monterey, but with the newest Xcode I seem to no longer getting it so I just ignored it... it's building for me on 12.0.1. So maybe update your OS to 11.6.1 or 12.0.1? Worst case downgrading Xcode to 12 should work just like last time.

[mopihopi]

I am seeing the same error upgrading mpv on macOS 11.6.1 20G224 (x86_64) with Xcode 13.1 13A1030d.

[i0ntempest]

Try 0.34.0 when it's up

[mopihopi]

I still see the same error with mpv 0.34.0_0 on macOS 11.6.1 20G224 (x86_64), Xcode 13.1 13A1030d.

[mopihopi]

mpv 0.34.0_0 on macOS 11.6.1 20G224 (x86_64), Xcode 13.1 13A1030d

[i0ntempest]

Unfortunately I'm not skilled enough to debug swift stuff, especially if you have mismatching Xcode and OS version.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #63706.

As it says in the log, "Please submit a bug report (​https://swift.org/contributing/#reporting-bugs) and include the project and the crash backtrace."

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #63791 which says upgrading to Xcode 13.1 fixes it however comment:10 in this ticket would seem to contradict that.

[yasuiniko (Niko Yasui)]

Coming from #63791: I am on macOS 11.5.2 (20G95) and upgraded to the latest available XCode 13.0 (19234). I still have this bulid problem. I'll have to check later if 13.1 works, although it doesn't seem to be available on my version of macOS.

[pmetzger (Perry E. Metzger)]

I'm having the same problem. mpv simply won't build. I'm using XCode 13.1 and it doesn't help.

[i0ntempest]

As I said for now you need a version of Xcode that matches your system for mpv to build.

[ShadSterling (Shad Sterling)]

I'm on macOS 11.6 (Big Sur), which version of Xcode matches that?

​https://trac.macports.org/wiki/XcodeVersionInfo seems to indicate Xcode 12.2 through 12.5

​https://en.wikipedia.org/wiki/Xcode seems to indicate at least Xcode 12.5 through 13.0

​https://developer.apple.com/support/xcode/ seems to indicate Xcode 13.0 through 13.1

The App Store has automatically updated to Xcode 13.1.

But pkgutil --pkg-info=com.apple.pkg.CLTools_Executables shows command line tools 13.0, which doesn't even match the Xcode version. xcode-select --print-path shows /Applications/Xcode.app/Contents/Developer and xcodebuild -version shows Xcode 13.1 Build version 13A1030d

Did the App Store automatically update Xcode to a version incompatible with MacPorts? Is there an issue with my versions of Xcode vs. the command line tools?

[i0ntempest]

For Big Sur you should use Xcode 12. 13 is not incompatible with MacPorts, it’s just this port gives a lot of problems if you have a mismatching Xcode version. Also mpv port on new systems does not use CLT.

[mascguy (Christopher Nielsen)]

You'll probably want to use the latest Xcode 12 release, which I believe is 12.5.1. Be sure to install the corresponding Xcode CLT too, matching that version.

​https://download.developer.apple.com/Developer_Tools/Xcode_12.5.1/Xcode_12.5.1.xip

​https://download.developer.apple.com/Developer_Tools/Command_Line_Tools_for_Xcode_12.5.1/Command_Line_Tools_for_Xcode_12.5.1.dmg

[mvenkadesan (MV)]

I am on the latest MacOS version 12.0.1 and latest XCode versio 13.1 (13A1030d), and can confirm that mpv installed smoothly. It is a fresh install of Macports, followed by a fresh install of MPV.

[ShadSterling (Shad Sterling)]

In what sense does Xcode 13.1 not match macOS 11.6? Why does Apple think it matches if it doesn't?

[i0ntempest]

When I say I match I basically mean "released with and contains the SDK of"

[Gandoon (Erik Hedlund)]

mpv-0.34.0_0 build on OSX 10.15.7 (19H1519) with Swift 5.3.2 and Xcode 12.4 (12D4e) [Intel x86_64]

[Gandoon (Erik Hedlund)]

I have a similar, but not identical issue as I am on MacOS 10.15.7 (19H1519) with Swift 5.3.2 from Xcode 12.4 (12D4e). The log is not identical, but it does seem to end with a similar error, and I cannot really figure out how to get it to build. Fortunately I still have a working version installed, but it is still not possible to build the 0.34.0_0 version. The dependencies have already been rebuilt but that does not help.

I cannot (and have little interest in due to software that will break) at this point upgrade to MacOS 11.
All other ports I have installed upgrades fine (albeit sometimes with some manual tweaking needed).
I append my log as well (mpv-0.34.0_0-OSX_10.15.7_(19H1519)-Swift_5.3.2-Xcode_12.4_(12D4e)-main.log)

Any input would be appreciated.

[i0ntempest]

For 10.15 use Xcode 11. If you don't know the version you need to build this, take a look at the buildbot log of your system version, here on the right: ​https://ports.macports.org/port/mpv/details/

[Gandoon (Erik Hedlund)]

Replying to i0ntempest:

For 10.15 use Xcode 11. If you don't know the version you need to build this, take a look at the buildbot log of your system version, here on the right: ​https://ports.macports.org/port/mpv/details/

Thank you for input, but it doesn't explain why this is the only port that refuses to build for me when all other builds just fine. The last working mpv (@0.33.1_1+audiocd+bluray+bundle+caca+dvd+jack+libarchive+network+opengl+osd+pulseaudio+python39+rubberband+screenshot+uchardet+x11) I have was built in April this year with this exact Xcode etc. I have been using Xcode 12 for the better part of a year now and 12.4 since soon after its release. I do not see any reason why this would be the point where I would need to downgrade a system that works in all other cases except for mpv.

Do you know what might be the issue here though? Because nothing about the Apple originated build system has changed between the build of 0.33.1_1 and now. Something in the updated port must be at fault here rather than a "too new" Xcode. I have tried to dig around myself, but not really been able to pinpoint the exact issue. I suspect something to do with waf (that I know almost nothing about at this point), but both seem to use wav v2.0.22, so I don't know.

Also, a small update… the outcome looks remarkably similar to this ticket: ​https://trac.macports.org/ticket/60267 regarding someones failure to build a slightly earlier version (mpv-0.31.0_0, note the similarity of the log contents, especially at the end).
The main differences between that build and my build seems to be that Xcode 11.4 and Python 2.7 was used instead of Xcode 12.4 and Python 3.9 in my case, but a few other things were older as well of course, but as I said, I successfully built the previous version of mpv with the present system.

[ShadSterling (Shad Sterling)]

It looks like MacPorts is building for macOS versions ending in ".0"; I'm running macOS 11.6, and after downgrading from Xcode 13.1 to Xcode 12.5.1 I see a lot of warnings about files "built for newer macOS version (11.2) than being linked (11.0)"

It also looks like Xcode only ever ships with an SDK for one version of macOS, which sometimes is a higher version than the host OS - as was the case when my macOS 11.6 was updated to Xcode 13.1 which has the SDK for macOS 12.0

I would think it would be possible to add SDKs for each target version of macOS (especially the host version), but my quick search didn't turn up anything about how to do that

[i0ntempest]

Replying to Gandoon:

Replying to i0ntempest:

For 10.15 use Xcode 11. If you don't know the version you need to build this, take a look at the buildbot log of your system version, here on the right: ​https://ports.macports.org/port/mpv/details/

Thank you for input, but it doesn't explain why this is the only port that refuses to build for me when all other builds just fine. The last working mpv (@0.33.1_1+audiocd+bluray+bundle+caca+dvd+jack+libarchive+network+opengl+osd+pulseaudio+python39+rubberband+screenshot+uchardet+x11) I have was built in April this year with this exact Xcode etc. I have been using Xcode 12 for the better part of a year now and 12.4 since soon after its release. I do not see any reason why this would be the point where I would need to downgrade a system that works in all other cases except for mpv.

Do you know what might be the issue here though? Because nothing about the Apple originated build system has changed between the build of 0.33.1_1 and now. Something in the updated port must be at fault here rather than a "too new" Xcode. I have tried to dig around myself, but not really been able to pinpoint the exact issue. I suspect something to do with waf (that I know almost nothing about at this point), but both seem to use wav v2.0.22, so I don't know.

All I know is something weird could happen when you try building Swift code with mismatched Xcode and/or SDK. Xcode 12 has SDK for macOS 11 and not 10.15, although theoretically you can use new SDKs to target old systems, the changes could still break stuff, which is the case here. Unfortunately I'm not skilled enough to do Swift debugging and the original maintainer isn't really active. I'm thinking maybe I'm gonna shot an email into MP developer list for some help.

Also, a small update… the outcome looks remarkably similar to this ticket: ​https://trac.macports.org/ticket/60267 regarding someones failure to build a slightly earlier version (mpv-0.31.0_0, note the similarity of the log contents, especially at the end).
The main differences between that build and my build seems to be that Xcode 11.4 and Python 2.7 was used instead of Xcode 12.4 and Python 3.9 in my case, but a few other things were older as well of course, but as I said, I successfully built the previous version of mpv with the present system.

[Gandoon (Erik Hedlund)]

Replying to ShadSterling:

It looks like MacPorts is building for macOS versions ending in ".0"; I'm running macOS 11.6, and after downgrading from Xcode 13.1 to Xcode 12.5.1 I see a lot of warnings about files "built for newer macOS version (11.2) than being linked (11.0)"

Yet another reason to not downgrade on behalf of one singular macport that fails consistently whilst all others work perfectly

It also looks like Xcode only ever ships with an SDK for one version of macOS, which sometimes is a higher version than the host OS - as was the case when my macOS 11.6 was updated to Xcode 13.1 which has the SDK for macOS 12.0

This is not strictly true, they do push out the Xcode and SDK for one version up, so that people can start developing for the upcoming system, hence 12.4 being the Xcode that is pushed out to MacOS 10.15 (the one you get if you download it from the Apple).

I would think it would be possible to add SDKs for each target version of macOS (especially the host version), but my quick search didn't turn up anything about how to do that

I may be wrong, but I think there may be some provisions for doing that from within Xcode (target system settings), but I am not sure if that is the issue here.

[Gandoon (Erik Hedlund)]

Replying to i0ntempest:

Replying to Gandoon:

Replying to i0ntempest:

For 10.15 use Xcode 11. If you don't know the version you need to build this, take a look at the buildbot log of your system version, here on the right: ​https://ports.macports.org/port/mpv/details/

. . .

All I know is something weird could happen when you try building Swift code with mismatched Xcode and/or SDK. Xcode 12 has SDK for macOS 11 and not 10.15, although theoretically you can use new SDKs to target old systems, the changes could still break stuff, which is the case here. Unfortunately I'm not skilled enough to do Swift debugging and the original maintainer isn't really active. I'm thinking maybe I'm gonna shot an email into MP developer list for some help.

. . .

As a test I did download mpv directly from the github repository and built that version, and it worked perfectly except for the libjpeg dependency from macports could not be found (all other macports based dependencies were detected and used without problem), and it does not build a .app which is less of a concern to me. However, it is interesting to note that the waf version used there seems to be 2.0.20 rather than 2.0.22 that seems to be what is used in the port. There are also discrepancies in various scripts when referring to the waf version number. Shuffling around a bit, I still can't get the macport to build, but as I said, the github clone I got builds perfectly fine, and it does not complain about Swift.

[jf (Jeffrey 'jf' Lim)]

Replying to Gandoon:

As a test I did download mpv directly from the github repository and built that version, and it worked perfectly except for the libjpeg dependency from macports could not be found (all other macports based dependencies were detected and used without problem), and it does not build a .app which is less of a concern to me. However, it is interesting to note that the waf version used there seems to be 2.0.20 rather than 2.0.22 that seems to be what is used in the port. There are also discrepancies in various scripts when referring to the waf version number. Shuffling around a bit, I still can't get the macport to build, but as I said, the github clone I got builds perfectly fine, and it does not complain about Swift.

Thank you for your report! I was able to successfully compile and use mpv myself as well. Similarly, the configure process was not able to detect libjpeg; but no matter! I mostly never use the screenshot feature, and I more often than not trigger it accidentally... This is my system:

• MacPorts 2.7.1 (with updated tree)
• M1 silicon
• Xcode 13.1
• MacOS 11.6

[Gandoon (Erik Hedlund)]

Replying to jf:

Replying to Gandoon:

As a test I did download mpv directly from the github repository and built that version, and it worked perfectly except for the libjpeg dependency from macports could not be found (all other macports based dependencies were detected and used without problem), and it does not build a .app which is less of a concern to me. However, it is interesting to note that the waf version used there seems to be 2.0.20 rather than 2.0.22 that seems to be what is used in the port. There are also discrepancies in various scripts when referring to the waf version number. Shuffling around a bit, I still can't get the macport to build, but as I said, the github clone I got builds perfectly fine, and it does not complain about Swift.

Thank you for your report! I was able to successfully compile and use mpv myself as well. Similarly, the configure process was not able to detect libjpeg; but no matter! I mostly never use the screenshot feature, and I more often than not trigger it accidentally... This is my system:

• MacPorts 2.7.1 (with updated tree)
• M1 silicon
• Xcode 13.1
• MacOS 11.6

I can give you a tip, for the standalone build I explicitly added a LDFLAGS for the config step:

LDFLAGS='-L/usr/lib -L/opt/local/lib -L/opt/local/lib/lua-5.2' ./waf configure --enable-jpeg [...]

Then the turbojpeg library could be found.
The -L/usr/lib was necessary because for some reason the macports iconv failed on me, so I had to point to the system version, and the lua-5.2 may or may not be necessary, but it gave me some headaches so it does not hurt (I further changed the includes to be <lua-5.2/lua.h> etc. in player/lua.c and the headaches went away). It is quite nice to have lua working since I do want to use the youtube-dl binding from time to time. Also, I changed the jpeglib.h includes in video/image_writer.c to explicit paths and added the turbojpeg.h include. Then it compiled more or less exactly as I wanted it to.
Finally, I built and installed it with:

./waf
sudo ./waf --install

I avoided using the ./waf build construct, as it didn't quite work the way I expected it to.
Slightly more fiddly than the normal macports build, but since at least for the time being, the port is semi-broken for some of us, this is an acceptable workaround for me.

[Gandoon (Erik Hedlund)]

Ok, I have had another go at this… aiming to build the following macports configuration:

port -v install mpv +audiocd +bluray +bundle +caca +dvd +jack +libarchive +libmpv +network +opengl +osd +pulseaudio +python39 +rubberband +screenshot +uchardet +x11

I still get the error as mentioned before. Since the issue seem to stem from the build phase, but also being influenced by the configure phase, I just manually reran the python waf configure step with the same options as the Portfile issued, but adding the LDFLAGS as I mentioned in my previous comment to make it complete without complaining.

/usr/lib/swift]€ LDFLAGS='-L/usr/lib -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64' python ./waf configure --prefix=/opt/local --enable-manpage-build --enable-coreaudio --enable-cocoa --enable-cplugins --enable-zlib --enable-swift --disable-html-build --disable-cuda-hwaccel --disable-opensles --disable-egl-drm --disable-egl-angle-lib --disable-egl-angle-win32 --disable-audiounit --disable-ios-gl --disable-direct3d --disable-android --disable-rpi --disable-dvbin --enable-caca --enable-cdda --disable-clang-database --disable-debug-build --enable-dvdnav --disable-egl-x11 --enable-gl --enable-gl-cocoa --enable-gl-x11 --enable-jack --disable-javascript --enable-jpeg --enable-libarchive --disable-openal --disable-pdf-build --enable-pulse --enable-rubberband --disable-test --disable-tv --enable-uchardet --disable-vapoursynth --enable-videotoolbox-gl --enable-x11 --enable-xv --enable-lua --lua=52fbsd --enable-libmpv-shared

After this, I manually built the project using the same command MacPorts use: /opt/local/bin/python3.9 ./waf build -v --verbose. Now the build phase completed just fine (well, lua52 failed to build in, but that can be fixed). and finally I reran the macports install command again. Since now the build phase was done, the port installed, BUT we get some further hints as to what may be at the core of the problem here, as it reaches the final stage, scanning for linking errors.

--->  Scanning binaries for linking errors
Could not open /usr/lib/swift/libswiftUniformTypeIdentifiers.dylib: Error opening or reading file (referenced from /Applications/MacPorts/mpv.app/Contents/MacOS/mpv)
--->  Found 3 broken files, matching files to ports
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: mpv @0.34.0+audiocd+bluray+bundle+caca+dvd+jack+libarchive+libmpv+network+opengl+osd+pulseaudio+python39+rubberband+screenshot+uchardet+x11

That /usr/lib/swift/libswiftUniformTypeIdentifiers.dylib just does not exist on my system…
So, I did try again: macports -v clean --all and then a new install with the same command as before, but with -bundle instead of +bundle.
Sadly, this did not work either, it fails at the same point.

However, yet another hint may be present at the first error encountered in the build stage (sorry for the formatting, not quite sure how to best format a diff here):

MacPorts build	manual build in MacPorts build folder
[ 25/457] Compiling DOCS/man/mpv.rst	[ 25/457] Compiling DOCS/man/mpv.rst
17:32:00 runner ' /opt/local/bin/rst2man-3.9.py --strip-elements-with-class=contents ../DOCS/man/mpv.rst DOCS/man/mpv.1 '	16:52:53 runner ' /opt/local/bin/rst2man-3.9.py --strip-elements-with-class=contents ../DOCS/man/mpv.rst DOCS/man/mpv.1 '
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/libxml2/libxml/module.modulemap:1:8: error: redefinition of module 'libxml2'	/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_mpv/mpv/work/mpv-player-mpv-79b4060/osdep/macos/libmpv_helper.swift:153:20: warning: 'CGLFlushDrawable' was deprecated in macOS 10.14: OpenGL API deprecated. (Define GL_SILENCE_DEPRECATION to silence these warnings)
module libxml2 [system] [extern_c] {	if !skip { CGLFlushDrawable(ctx) }

To conclude, there may be several weird issues here, but the missing swift libswiftUniformTypeIdentifiers.dylib may be one of the most prominent ones. As it does compile from a git clone, and the MacPorts build directory content does build functioning binaries, and neither method generates a working .app bundle, I dare to say that I may be on to something here.

I am not quite sure where to go from here with regards to MacPorts, but please feel free to suggest something. I have let you all know what I found at least.

[i0ntempest]

A similar (or identical) problem to the one you're getting was discussed here: ​https://trac.macports.org/ticket/60267
When 10.15 got released, Xcode modules were new and had all kinds of problems.

[Gandoon (Erik Hedlund)]

Replying to i0ntempest:

A similar (or identical) problem to the one you're getting was discussed here: ​https://trac.macports.org/ticket/60267
When 10.15 got released, Xcode modules were new and had all kinds of problems.

Yes, I know. I mentioned that ticket earlier, but that ticket is marked as fixed. And I also mentioned that I had no problems until the final 0.33.1_2 version, just before becoming 0.34. The penultimate 0.33.1_1 built fine in April with the same system. It all seems to have started when there was an ffmpeg bump a few weeks ago, and mpv builds have been broken for me (and apparantly a few others) since then.

I shared my experiences, in case they can be helpful to someone.

[jmesmon (Cody Schafer)]

Ok, I've found a Portfile workaround that fixes things: forcing the use of the 12.0 sdk (even when building for macosx 11.6) results in a successful build. It seems that macports forcing an older sdk is breaking things here.

I added configure.sdk_version 12.0 to my Portfile to workaround the issue, but the right choice here is likely filtering out broken sdk versions. Something like this maybe:

    if {[vercmp ${configure.sdk_version} 11.3] == 0} {
       configure.sdk_version 12.0
    }

For the record, here's some of my system info:

• xcode 13.1
• macosx 11.6.1
• MacBookPro11,3 - x86_64
• macosx 12 sdk location: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.0.sdk
• macosx 11.3 sdk location: /Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk

Edit2: another thought about what the issue might be here:

My selected developer directory (xcode-select -switch ...) was /Applications/Xcode.app/Contents/Developer/ when I conducted all this testing. So perhaps macports was looking in the wrong developer directory? It was definitely picking up the old sdk version from /Library/Developer, but I'm not sure if that is intended behavior when the Developer directory is set to another location. (I'm also not familiar with how the sdk_version is normally picked by macports).

Note: using the xcode settings (Xcode Preferences > Locations > Command Line Tools) to set the command line tools to Xcode 13.1 effectively runs xcode-select -switch /Applications/Xcode.app/Contents/Developer/.

Edit3: another thought: possible that this build works if one selects the older command line tools (via xcode-select -switch /Library/Developer) and still uses the older SDK. If so, suggests we should probably try to avoid mixing new SDKs with old command line tools in macports itself (ie: when picking the SDK to use, ensure there's a match with the command line tools in use)

[i0ntempest]

configure.sdk_version hack was used in the portfile before to fix other swift errors, but it could cause other errors and break compatibilities so I'm hesitant about adding it in again.

[Tatsh (Andrew Udvare)]

I am getting this issue on Big Sur after doing a full migration. I added configure.sdk_version 12.1 unconditionally and that made mpv build.

[Ryan Schmidt <git@…>]

In 20d1467595b202addcdd283f0677a00d7f820a21/macports-ports (master):

mpv: Set MACOS_SDK_VERSION and use latest SDK (​https://github.com/macports/macports-ports/pull/14119)

Fixes build on Mac OS X 10.7 and on Xcode versions where the SDK version
does not match the OS version.

Closes: #61733
Closes: #61647
Closes: #62889
Closes: #63694