MPlayer @1.5.0_1 won't build on ARM64 macOS Sequoia

[wdormann]

Upon trying to rebuild mplayer after an os update to Sequoia:

:info:build libvo/gl_common.c:2757:24: error: incompatible function pointer types assigning to 'void (*)(struct MPGLContext *)' from 'void (void)' [-Wincompatible-function-pointer-types]
:info:build  2757 |     ctx->swapGlBuffers = vo_osx_swap_buffers;
:info:build       |                        ^ ~~~~~~~~~~~~~~~~~~~

[wdormann]

Build log

[kencu (Ken)]

this is a workaround to get MPlayer built on Sequoia:

# fix i386 builds
patchfiles          patch-mplayer-i386.diff

+ # https://trac.macports.org/ticket/70804
+ configure.cflags-append -Wno-incompatible-function-pointer-types -Wno-int-conversion
+ configure.env-append    HCFLAGS=${configure.cflags}

depends_build-append \

% port -v installed mplayer
The following ports are currently installed:
  MPlayer @1.5.0_1 (active) requested_variants='' platform='darwin 24' archs='arm64' date='2024-09-21T12:03:33-0700'

And it works fine, with brief testing.

Obviously, this just turns the errors off, and lets it build as it has been building on systems up until now.

There are a number of proper fixes in the MPlayer svn trunk, and mplayer-devel can be updated to a new version to pick those up. However, even when I did that, and mplayer-devel is updated to current commits, it still won't build and needs more work done.

The above flags disabling the errors seem to be needed only on Sequoia so far. I would imagine they are needed on all newer clang versions as well, though. I haven't tested what gcc thinks of those flags.

So if it is decided to go with disabling the flags, it might be limited in some way to the systems that are likely affected.

[kencu (Ken)]

Homebrew has also just disabled the warning for now:

​https://github.com/Homebrew/homebrew-core/blob/57aecc6a141d90a46b29e0fe35dfd023099a8ded/Formula/m/mplayer.rb

    # Work around build failure with newer Clang
    if DevelopmentTools.clang_build_version >= 1500
      ENV.append_to_cflags "-Wno-int-conversion -Wno-incompatible-function-pointer-types"
    end

I'm not sure why we also need the HCFLAGS part -- it sends the right flags into the ffmpeg part of the build on macports, whereas they don't get sent with the configure.cflags-append. Some weirdness that no doubt makes sense when you know exactly how the CFLAGS are affected by configure.cflags-append.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

Some weirdness that no doubt makes sense when you know exactly how the CFLAGS are affected by configure.cflags-append.

It works exactly as you think it would: Any items given to configure.cflags-append are appended to the configure.cflags option. And during the configure phase, the entire contents of the configure.cflags option are put into the CFLAGS environment variable.

[kencu (Ken)]

I tried it again just now, and (as happens sometimes) this is all that is needed:

+ configure.cflags-append -Wno-incompatible-function-pointer-types -Wno-int-conversion

previously, for some reason, I seemed to need to add

configure.env-append    HCFLAGS=${configure.cflags}

but that appears to have been a Heisenberg, so things make sense again.

[ShadSterling (Shad Sterling)]

I'm getting the same error on my 2018 Intel MacBook Pro, doesn't look like it's limited to ARM

[kencu (Ken)]

In 644c4a7e920604a4ec33f09d0e47cafb9c94701d/macports-ports (master):

Mplayer: disable several errors that stumle clang

until these are properly fixed upstream, disable the errors
close: #70804

[kencu (Ken)]

In 4b188be25c4a868f88ccf45a239740e70c097917/macports-ports (master):

mplayer-devel: fix build with newer clangs

see: #70804

[ShadSterling (Shad Sterling)]

Similar errors on dia, not sure if this is a more general sequoia problem

[kencu (Ken)]

the default setting for errors by the compiler is ever-stricter.

[barracuda156]

Replying to kencu:

In 644c4a7e920604a4ec33f09d0e47cafb9c94701d/macports-ports (master):

Mplayer: disable several errors that stumle clang

until these are properly fixed upstream, disable the errors
close: #70804

This added a clang-only flag unconditionally, am I right? )

[kencu (Ken)]

Replying to barracuda156:

This added a clang-only flag unconditionally, am I right?

Only on the very newest of MacOS systems, yes, where generally speaking nobody would ever try to use gcc. :>

I don't know if gcc supports those flag or not, but with a few moments of casual googling, it looks like gcc does:

​https://stackoverflow.com/questions/34116536/gcc-how-to-suppress-incompatible-pointer-type-warning

​https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html