Bug 221876 - multimedia/mpv: Build fails with ZSH=on
Summary: multimedia/mpv: Build fails with ZSH=on
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Carlos J. Puga Medina
URL: https://github.com/mpv-player/mpv/iss...
Depends on:
Reported: 2017-08-28 08:27 UTC by VK
Modified: 2017-09-13 14:50 UTC (History)
1 user (show)

See Also:
cpm: maintainer-feedback+

mpv build log (699.72 KB, text/plain)
2017-08-28 08:27 UTC, VK
no flags Details
gdb backtrace of dumped mpv.core (14.79 KB, text/plain)
2017-08-30 23:03 UTC, VK
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description VK freebsd_triage 2017-08-28 08:27:40 UTC
Created attachment 185838 [details]
mpv build log

mpv fails to build with ZSH option enabled. This seems to be the culprit (full log attached): I've looked at zsh.pl, and there's a die() in there at line 30 if `--list-options` returns empty, but I didn't look beyond that.

> [449/449] Compiling TOOLS/zsh.pl
> 22:46:08 runner ' "/usr/local/bin/perl" "/wrkdirs/usr/ports/multimedia/mpv/work/mpv-0.26.0/TOOLS/zsh.pl" "/wrkdirs/usr/ports/multimedia/mpv/work/mpv-0.26.0/build/mpv" > "etc/_mpv" '
> Couldn't find any options at /wrkdirs/usr/ports/multimedia/mpv/work/mpv-0.26.0/TOOLS/zsh.pl line 30.

Building with MAKE_JOBS_UNSAFE=yes yields the same result.
Comment 1 Carlos J. Puga Medina freebsd_committer 2017-08-28 18:45:20 UTC
Yes, the following commit introduced the issue:

Comment 2 VK freebsd_triage 2017-08-28 19:30:11 UTC
I guess that commit exposed a deeper issue. I'm not familiar with ZSH completion to be able to dig into this.

What do you recommend be done? Patch that out, or mark the port broken when ZSH=on for now?
Comment 3 Carlos J. Puga Medina freebsd_committer 2017-08-29 11:23:38 UTC
(In reply to Vladimir Krstulja from comment #2)

I recommend to disable ZSH option while the issue is fixed.

FYI this bug has been reported upstream.

Comment 4 VK freebsd_triage 2017-08-30 23:03:12 UTC
Created attachment 185940 [details]
gdb backtrace of dumped mpv.core

Upon further inspection, `mpv --list-options` is failing with

> Illegal instruction (core dumped)

when I run it in the Poudriere builder jail provided with `poudriere testport -i`, when built without ZSH=on.

I've attached gdb output run on dumped core.

I don't know what could be causing this. The build server is a sandybridge Xeon, and I've tried removing the CPUTYPE completely (see build log), dropped ccache, and rebuilt the entire repository over again, still fails.

I suppose it doesn't like something about that build environment. Maybe it requires full X + OpenGL + ... suite be available and running?
Comment 5 Philip Sequeira 2017-08-31 03:34:50 UTC
Is this a cross compile (i.e. you're not planning to run it on the machine thats compiling it)? Generating zsh completion doesn't generally work in that case since it requires running the compiled program. This isn't optimal anyway and I've got an idea of fixing it, but in the mean time you can run TOOLS/zsh.pl on the target machine and write its output to /usr/share/zsh/site-functions/_mpv or /usr/local/share/zsh/site-functions/_mpv, depending on where you have zsh installed.

If, on the other hand, you get the illegal instruction message even on the target machine, then this problem isn't related to the zsh completion at all. It looks like the crashing code isn't actually mpv's. You said you recompiled mpv for generic CPU, but did you rebuild all its dependencies the same way? That would be necessary if compiler flags were the problem. (But again, if you're compiling for another machine, it isn't worth that trouble; just use the workaround of manually generating the completion on the target machine for now. There's a decent chance the next release of mpv won't need to run the compiled executable on the build machine for zsh completion.)
Comment 6 VK freebsd_triage 2017-08-31 08:39:15 UTC
(In reply to Philip Sequeira from comment #5)

The build server (sandybridge) is not the same machine, but they're all amd64. On the target machine (haswell) mpv runs fine.

I've rebuilt the entire poudriere repo anew after removing CPUTYPE and dropping ccache.

I actually don't plan to use ZSH. I missed to disable it the first time and then found this problem. Even so, regardless of stopgap solutions, this must build in poudriere.
Comment 7 Philip Sequeira 2017-09-01 03:55:45 UTC
(In reply to Vladimir Krstulja from comment #6)

Okay, I'm not sure what part of your build process is still targeting Haswell, but that's not really an mpv issue, and in general you want your build to target Haswell anyway, right?

The way we currently generate ZSH completion is known to be incompatible with cross-compilation, which is actually why it's disabled by default upstream, IIRC. I hope to change that soon, at which point it should build in poudriere as well as it does now without that feature. If you aren't even using ZSH, just disable the feature for the time being.
Comment 8 commit-hook freebsd_committer 2017-09-13 13:37:14 UTC
A commit references this bug:

Author: cpm
Date: Wed Sep 13 13:35:58 UTC 2017
New revision: 449784
URL: https://svnweb.freebsd.org/changeset/ports/449784

  multimedia/mpv: update to 0.27.0

  - Remove patch (added upstream)
  - Disable ZSH completion option for the time being. The way we currently generate
    ZSH completion is known to be incompatible with cross-compilation, which is
    actually why it's disabled by default upstream [1]

  Changelog: https://github.com/mpv-player/mpv/releases/tag/v0.27.0

  PR:		221876 [1]
  Reported by:	Vladimir Krstulja <vlad-fbsd@acheronmedia.com>

Comment 9 Carlos J. Puga Medina freebsd_committer 2017-09-13 13:39:13 UTC
Thanks for your help, Philip!
Comment 10 VK freebsd_triage 2017-09-13 14:50:36 UTC
I do feel inclined to point out that this particular case that hit me is not cross compilation, like I've mentioned several times. As far as that poudriere box is concerned, it builds for local use on that machine.

This patch completely disables ZSH (instead of marking it broken conditionally), even though it builds fine on a newer (amd64) CPU. At least have an UPDATING entry so you don't silently pull the rug from under systems where it builds and runs fine.