MoarVM: fix build with gcc14

[barracuda156]

Description

Looks like what we have with clangs is now also an issue with gcc.

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 10.6
Xcode 3.2

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL in commit message?
• checked your Portfile with port lint --nitpick?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[aeiouaeiouaeiouaeiouaeiouaeiou]

@barracuda156 Lion also is broken with this error: https://build.macports.org/builders/ports-10.7_x86_64-builder/builds/197160/steps/install-port/logs/stdio

/opt/local/bin/clang-mp-16 -c -fno-omit-frame-pointer -fno-optimize-sibling-calls -Werror=vla -O3 -DNDEBUG -Wno-logical-op-parentheses -D_DARWIN_USE_64_BIT_INODE=1  -DMVM_HEAPSNAPSHOT_FORMAT=2 -pipe -Os -I/opt/local/include/libtommath -arch x86_64 -isystem/opt/local/include/LegacySupport -D_GNU_SOURCE -DMVM_TRACING=0 -DMVM_CGOTO=1 -DMVM_BUILD_SHARED  -I3rdparty/libuv/include -I3rdparty/libuv/src -I3rdparty/sha1 -isystem3rdparty/ryu -isystem3rdparty/dynasm -isystem3rdparty/cmp -isystem3rdparty -I/opt/local/include -Isrc -o 3rdparty/libuv/src/unix/fs.o 3rdparty/libuv/src/unix/fs.c
/opt/local/bin/clang-mp-16 -c -fno-omit-frame-pointer -fno-optimize-sibling-calls -Werror=vla -O3 -DNDEBUG -Wno-logical-op-parentheses -D_DARWIN_USE_64_BIT_INODE=1  -DMVM_HEAPSNAPSHOT_FORMAT=2 -pipe -Os -I/opt/local/include/libtommath -arch x86_64 -isystem/opt/local/include/LegacySupport -D_GNU_SOURCE -DMVM_TRACING=0 -DMVM_CGOTO=1 -DMVM_BUILD_SHARED  -I3rdparty/libuv/include -I3rdparty/libuv/src -I3rdparty/sha1 -isystem3rdparty/ryu -isystem3rdparty/dynasm -isystem3rdparty/cmp -isystem3rdparty -I/opt/local/include -Isrc -o 3rdparty/libuv/src/unix/loop-watcher.o 3rdparty/libuv/src/unix/loop-watcher.c
3rdparty/libuv/src/unix/fs.c:478:34: error: incompatible function pointer types passing 'int (const uv__dirent_t *)' (aka 'int (const struct dirent *)') to parameter of type 'int (*)(struct dirent *)' [-Wincompatible-function-pointer-types]
  n = scandir(req->path, &dents, uv__fs_scandir_filter, uv__fs_scandir_sort);
                                 ^~~~~~~~~~~~~~~~~~~~~
/usr/include/dirent.h:129:11: note: passing argument to parameter here
    int (*)(struct dirent *), int (*)(const void *, const void *)) __DARWIN_INODE64(scandir);
          ^
3rdparty/libuv/src/unix/fs.c:478:57: error: incompatible function pointer types passing 'int (const uv__dirent_t **, const uv__dirent_t **)' (aka 'int (const struct dirent **, const struct dirent **)') to parameter of type 'int (*)(const void *, const void *)' [-Wincompatible-function-pointer-types]
  n = scandir(req->path, &dents, uv__fs_scandir_filter, uv__fs_scandir_sort);
                                                        ^~~~~~~~~~~~~~~~~~~
/usr/include/dirent.h:129:37: note: passing argument to parameter here
    int (*)(struct dirent *), int (*)(const void *, const void *)) __DARWIN_INODE64(scandir);
                                    ^

[barracuda156]

@aeiouaeiouaeiouaeiouaeiouaeiou It may be OS-dependent, but I cannot verify that. Should we add the flag on everything < 10.8 regardless of compiler?

[aeiouaeiouaeiouaeiouaeiouaeiou]

@barracuda156 maybe apply this flag globally to the build? I see in the mosml portfile that it only applies to the Clang compiler, while it is slightly different for GCC.

[barracuda156]

@barracuda156 maybe apply this flag globally to the build? I see in the mosml portfile that it only applies to the Clang compiler, while it is slightly different for GCC.

@aeiouaeiouaeiouaeiouaeiouaeiou The current GCC is fine with -Wno-error= forms. I am not sure whether there was some specific reason to make flags different in a case of MosML or I just borrowed what worked from elsewhere.
Perhaps using it globally is okay.

[pmetzger]

Have you reported the problem to upstream?

[barracuda156]

@pmetzger I am not sure they will bother to add conditional flags for a combo of old macOS and a bleeding-edge gcc version, but I can open an issue there.

[pmetzger]

There should be no circumstance in which incompatible pointer types are being assigned to each other regardless.

[pmetzger]

Just to be clear: the problem isn't the lack of the flag on the compiler, it's the code. (Really this should have been fixed by patching the code.)

[barracuda156]

Just to be clear: the problem isn't the lack of the flag on the compiler, it's the code. (Really this should have been fixed by patching the code.)

MoarVM/MoarVM#1821

[pmetzger]

There have been similar issues in other ports as well.