qt5-qtwebkit fails to build on Big Sur 11.1 with Apple silicon

[dfleck]

This bug is now apparently about qt5-qtwebkit failing to build on arm64. mythtv is only incidental at this point.

[ctreleaven (Craig Treleaven)]

AFAIK, you are the first person to attempt to build Myth 0.28 on Apple Silicon.

You could try adding arm64 to the supported_archs (line 26 of the Portfile). The build dependency on yasm will then be superfluous, I believe.

Are you looking to try running mythbackend on an M1 Mac? I'll be glad to offer what advice I can but I don't have such hardware myself.

[dfleck]

Actually I *have* mythbackend (and mythweb) running on the M1. I installed a v28 app package I found somewhere. But I'd like to get it running "properly" as a service thru MacPorts (plus the webbackend server isn't working right with the app).

I'll try to modify the Portfile - but so far I've been flummoxed with updating the checksums.

[dfleck]

Modifying the Portfiles as suggested results in a different error:

Error: Cannot install mythtv.28 for the arch 'arm64' because
Error: its dependency qt5-qtbase only supports the arch 'x86_64'.

[ctreleaven (Craig Treleaven)]

Interesting. I would guess that you installed from the all-in-one installer and are therefore running Myth under Rosetta2 emulation. First report I've heard of that.

I'm not sure what the status is on qt5 on Apple silicon. I think it might be best to send a query to the macports-dev mailing list, copying the qt5 maintainers, and ask what the plan is to bring Qt up. I did notice that Qt6 was released recently. The indication was that Qt6 was not a major departure from Qt5 so maybe it won't be hard to add to MacPorts. OTOH, Qt is a massive, complicated suite of software and making it work in a MacPorts-context has been far from trivial.

Please feel free to contact me directly at my macports.org address if you'd like to discuss further.

[ILMostro (ILMostro)]

Yeah, the same issue with qt5-base is the blocker for the current release of mythtv; version 0.31. I had brought it up in the IRC at the time. Actually, the specific package, as far as I could tell, was qt5-qtwebkit.

[ILMostro (ILMostro)]

main.log from port install qt5-qtwebkit

[kencu (Ken)]

I fixed most of qt5 to work on arm64, but qt5-qtwebkit is not fixed. It's a upstream issue, and I haven't heard when or if they plan on getting it fixed.

[ctreleaven (Craig Treleaven)]

@ILMostro, what is your objective? If you are looking to install a full Myth system (front & backend), then 0.28 is not a great choice. It is no longer supported upstream and version 32 is going to be released in a few weeks/months.

However, AFAIK, qtwebkit is only used for plugins (like MythNews & MythBrowser). You could try deleting qtwebkit as a dependency and see if the build gets much further. Myth frontend, at least, does build and run on Android so it is conceivable that it could be made to build and run on Apple Silicon.

Also, I could not find a ticket or pull request regarding qt5-qtwebkit not building on arm64. Another ticket should be opened. @kencu, is there an upstream Qt ticket regarding building on arm64?

[jhoyt4]

@ILMostro @kencu - it looks like the qtwebkit compile is failing where we had to patch recently in FastMalloc.cpp for Big Sur back in Nov/Dec.

The related patch is patch-qtwebkit-FastMalloc.diff

Basically, Apple changed from using the PAGE_SHIFT variable to I386_PGSHIFT for x86 and I believe PGSHIFT for ARM. Modding the patch to change PAGE_SHIFT to PGSHIT should fix the initial compile issue.

#if OS(DARWIN)
#    if CPU(X86_64)
#        define K_PAGE_SHIFT I386_PGSHIFT
#    else
#        define K_PAGE_SHIFT PGSHIFT
#    endif

The portfile is currently setup only to patch os.major > 20 so this should not hurt anyone else.

I've attached a new patch file. If this works, I'd be happy to make up a new PR.

I'd test myself - but unfortunately I don't have any computers with Apple Silicon.

[kencu (Ken)]

nb #62139.

[kencu (Ken)]

this is the one for qtwebengine.

<​https://bugreports.qt.io/browse/QTBUG-85537>

It's been a couple of months since I worked on this, and qt5 has several different web-related packages...might have to check again to be certain exactly where each package got to in terms of build status.

[kencu (Ken)]

Here are the qt5 ports we have installed on arm64 so far:

% port -v installed | grep qt5
  qt5 @5.15.2_0 (active) platform='darwin 20' archs='noarch' date='2020-12-20T02:51:37-0500'
  qt5-qt3d @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T02:42:11-0500'
  qt5-qtbase @5.15.2_2+openssl (active) platform='darwin 20' archs='arm64' date='2021-01-21T20:16:44-0500'
  qt5-qtconnectivity @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T02:50:52-0500'
  qt5-qtcreator @4.12.4_0 (active) platform='darwin 20' archs='arm64' date='2021-01-14T03:35:10-0500'
  qt5-qtdeclarative @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:19:58-0500'
  qt5-qtgamepad @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:34:47-0500'
  qt5-qtgraphicaleffects @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:24:01-0500'
  qt5-qtimageformats @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:24:17-0500'
  qt5-qtlocation @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:30:48-0500'
  qt5-qtmacextras @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:26:56-0500'
  qt5-qtmultimedia @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:33:48-0500'
  qt5-qtnetworkauth @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:33:56-0500'
  qt5-qtquickcontrols @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:27:38-0500'
  qt5-qtquickcontrols2 @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:25:55-0500'
  qt5-qtremoteobjects @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:34:17-0500'
  qt5-qtscript @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2021-01-06T11:00:04-0500'
  qt5-qtscxml @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:34:35-0500'
  qt5-qtsensors @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:26:31-0500'
  qt5-qtserialbus @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:32:41-0500'
  qt5-qtserialport @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:26:03-0500'
  qt5-qtspeech @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T02:51:02-0500'
  qt5-qtsvg @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:15:18-0500'
  qt5-qttools @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:23:23-0500'
  qt5-qttranslations @5.15.2_0 (active) platform='darwin 20' archs='noarch' date='2020-12-20T02:51:21-0500'
  qt5-qtwebchannel @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:26:50-0500'
  qt5-qtwebsockets @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:26:42-0500'
  qt5-qtxmlpatterns @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T01:32:22-0500'
  qt5-sqlite-plugin @5.15.2_0 (active) platform='darwin 20' archs='arm64' date='2020-12-20T02:51:36-0500'

And here's what the buildbot has made wrt to qt5-qtwebkit

<​http://packages.macports.org/qt5-qtwebkit/>

[kencu (Ken)]

Replying to jhoyt4:

@ILMostro @kencu - it looks like the qtwebkit compile is failing where we had to patch recently in FastMalloc.cpp for Big Sur back in Nov/Dec.

That patch is already in the qt5-qtwebit build.

<​https://github.com/macports/macports-ports/blob/master/aqua/qt5/files/patch-qtwebkit-FastMalloc.diff>

and should be being used already:

<​https://github.com/macports/macports-ports/blob/396d56f67cd6bc62a6ab49fff279fa83c7098032/aqua/qt5/Portfile#L1533>

[jhoyt4]

Replying to kencu:

Replying to jhoyt4:

@ILMostro @kencu - it looks like the qtwebkit compile is failing where we had to patch recently in FastMalloc.cpp for Big Sur back in Nov/Dec.

That patch is already in the qt5-qtwebit build.

Ken - check again.  I modded line 11 from "PAGE_SHIFT" to "PGSHIFT" the new variable.

Sorry - should have made a new file name...

Once K_PAGE_SHIFT gets set to PGSHIFT, K_PAGE_SHIFT and K_NUM_CLASSES should now be set appropriately and get you past that error.

[jhoyt4]

I could also be wrong about PGSHIFT :)

[jhoyt4]

% grep -r PGSHIFT /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk                                                                    
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/i386/param.h:#define PGSHIFT         12              /* LOG2(NBPG) */
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/i386/param.h:#define ctod(x) ((x)<<(PGSHIFT-DEV_BSHIFT))
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/i386/param.h:#define dtoc(x) ((x)>>(PGSHIFT-DEV_BSHIFT))
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/i386/param.h:#define ctob(x) ((x)<<PGSHIFT)
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/i386/param.h:#define btoc(x) (((unsigned)(x)+(NBPG-1))>>PGSHIFT)
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/sys/param.h:#define CLSHIFT         (PGSHIFT+CLSIZELOG2)
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/mach/i386/vm_param.h:#define I386_PGSHIFT            12              /* bitshift for pages */
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/mach/i386/vm_param.h:#define PAGE_SHIFT              I386_PGSHIFT
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/arm/param.h:#define PGSHIFT         12              /* LOG2(NBPG) */
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/arm/param.h:#define ctod(x) ((x)<<(PGSHIFT-DEV_BSHIFT))
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/arm/param.h:#define dtoc(x) ((x)>>(PGSHIFT-DEV_BSHIFT))
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/arm/param.h:#define ctob(x) ((x)<<PGSHIFT)
/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/arm/param.h:#define btoc(x) (((unsigned)(x)+(NBPG-1))>>PGSHIFT)

This is the one :)

/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/include/arm/param.h:#define PGSHIFT         12              /* LOG2(NBPG) */

It looks like Apple removed PAGE_SHIFT from the mach headers for arm...

[jhoyt4]

Another option it to change it to PAGE_SHIFT_CONST

/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/System/Library/Frameworks/Kernel.framework/Versions/A/Headers/mach/arm/vm_param.h:#define PAGE_SHIFT_CONST        12

[kencu (Ken)]

We're in the right section, for sure. I guess we need an arm section for this patch:

--- Source/WTF/wtf/FastMalloc.cpp
+++ Source/WTF/wtf/FastMalloc.cpp
@@ -628,7 +628,11 @@
 // sense.  In particular, if kMaxSize increases, you may have to
 // increase kNumClasses as well.
 #if OS(DARWIN)
-#    define K_PAGE_SHIFT PAGE_SHIFT
+#    if CPU(X86_64)
+#        define K_PAGE_SHIFT I386_PGSHIFT
+#    else
+#        define K_PAGE_SHIFT PAGE_SHIFT
+#    endif
 #    if (K_PAGE_SHIFT == 12)
 #        define K_NUM_CLASSES 68
 #    elif (K_PAGE_SHIFT == 14)

but -- I feel we have been down this exact road before in some port or ticket.... maybe not.

[jhoyt4]

Replying to kencu:

We're in the right section, for sure. I guess we need an arm section for this patch:

makes sense, when I tossed it together I couldn't remember the switch value for arm - ARM or ARM64 or ... then again, this only triggers for dawrin >=20 - so if it's not X86 then it has to be ARM (at this point in time...)

but -- I feel we have been down this exact road before in some port or ticket.... maybe not.

I think when I wrote the original patch, PAGE_SHIFT was still in the 11.0 SDK for ARM. Apple keeps changing things around with that add of PAGE_SHIFT_CONST - but PGSHIFT seems to consistently be there.

Again, would be happy to test and hack away until I got the correct answer, I just don't have any Apple Silicon to play around with...

[ILMostro (ILMostro)]

Thank you all for the ongoing work. I'm not sure if the patch is in the tree already. I tried to test it now, but the failure is still there. I am returning the device, so I won't be able to contribute much more after today.

As for the mythtv build. I was trying to build mythtv-0.31 using the ​https://github.com/MythTV/packaging/blob/master/OSX/build/macports_ansible/compileMythfrontendAnsible.zsh script.

[jhoyt4]

@ILMostro - the patchfile is not in git (the original that works for x86 is, but not the minor ARM tweak). You could copy the one I posted earlier into your port tree to test.

Sorry to hear you're returning the device - if you get to hold onto it for longer and need help troubleshooting the build script, I am very happy to help there (I'm the author). As far as I know, you're the first to try it on ARM.

[ILMostro (ILMostro)]

Thank you, I appreciate it. I did try the patch just now, but it's reported as failed to apply the patch. I'm assuming that it was just a matter of downloading the patch file in original format and placing it in "/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/aqua/qt5/files/". I'm attaching the main log here. The output of the FastMalloc.cpp.rej file is shown below.

cat var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/aqua/qt5/work/qtwebkit-opensource-src-5.9.2/Source/WTF/wtf/FastMalloc.cpp.rej 
***************
*** 628,634 ****
  // sense.  In particular, if kMaxSize increases, you may have to
  // increase kNumClasses as well.
  #if OS(DARWIN)
- #    define K_PAGE_SHIFT PAGE_SHIFT
  #    if (K_PAGE_SHIFT == 12)
  #        define K_NUM_CLASSES 68
  #    elif (K_PAGE_SHIFT == 14)
--- 628,638 ----
  // sense.  In particular, if kMaxSize increases, you may have to
  // increase kNumClasses as well.
  #if OS(DARWIN)
+ #    if CPU(X86_64)
+ #        define K_PAGE_SHIFT I386_PGSHIFT
+ #    else
+ #        define K_PAGE_SHIFT PGSHIFT
+ #    endif
  #    if (K_PAGE_SHIFT == 12)
  #        define K_NUM_CLASSES 68
  #    elif (K_PAGE_SHIFT == 14)

[jhoyt4]

sorry - broken patch file (serious apologies). Working on a fix now.

[jhoyt4]

darn, now have a new bug... working to squash it

[jhoyt4]

Corrected patch file (really I mean it this time...)

[jhoyt4]

Sorry - now the patch file is fixed.

Sorry for two patch files (they are both the same) - the web interface didn't take the "replace file" checkbox on one of my uploads for some reason.

[ILMostro (ILMostro)]

No worries. Unfortunately, though, it still fails to build. I've attached the latest build log, replacing the previous one.

[jhoyt4]

Thanks!

That tells me the compiler isn't picking up the header file that delcares PGSHIFT - probably because Apple moved it from "mach/vm_param.h" to "mach/i386/vm_param.h" and "mach/arm/vm_param.h" - but arm has no value included. Instead we now find PGSHIFT in "arm/param.h".

This may also mean a lot more to do in the background to get qtwebkit up and running - but let's try this as a first attempt to fix.

Here's a patch file that ::hopefully:: adds arm/param.h to the include list and switched over to PGSIZE.

There's a good chance this patch will fail as well as I added if statements to check for CPU(ARM64) - I may have guessed the architecture label incorrectly.

[ILMostro (ILMostro)]

All right,

The failure occurs later on in the process now, it seems. I'm not sure if it's meant to be arm64 or aarch64. Let me know if/how I can help.

I've added the log here.

[jhoyt4]

The good / bad news is that it's still tripping in the same place:

:info:build wtf/FastMalloc.cpp:641:10: error: "Unsupported PAGE_SHIFT amount"
:info:build #        error "Unsupported PAGE_SHIFT amount"
:info:build          ^
:info:build wtf/FastMalloc.cpp:652:35: error: use of undeclared identifier 'K_NUM_CLASSES'
:info:build static const size_t kNumClasses = K_NUM_CLASSES;
:info:build

Basically my logic in the patch fails to set K_PAGE_SHIFT which then is used to set K_NUM_CLASSES

One more patch file, hopefully this gets us past this error.

[ILMostro (ILMostro)]

no dice; along with the continuing failure regarding K_PAGE_SHIFT, I do see errors about "unknown architecture" as well.

[jhoyt4]

If you're up for one more round of trial and error, this replacement patch brute forces K_PAGE_SHIFT to 12. I'm curious if it at least makes the K_NUM_CLASSES / K_PAGE_SHIFT errors go away.

Given that qtwebkit is pretty much abandoned by qt for qtwebengine, it may be worth investigating compiling mythtv without qtwebkit. This should work for v31/master - but will break the plugins which may not be a deal breaker for you.

If you choose to go down that route, it's probably worth us shifting to another venue (email or mythtv forums/mailing list) to help you troubleshoot the compileMythfrontendAnsible.zsh script (you can skip the ansible port install with the --skip-ansible=true flag) assuming you have all of the necessary ports already installed (for qt: qt5, qt5-qtscript, qt5-mysql-plugin +mariadb-10.2).

As for v31 in macports, I know @ctreleaven was working on a new port for either v31 or master. The only solution for ARM may be to abandon mythtv-plugins until someone updates them to qtwebengine

[ILMostro (ILMostro)]

yeah, honestly, I'm not even sure what the plugins do. As far as I can tell, my gentoo system never has any plugins active/available. I am merely interested in compiling mythfrontend on the macbook pro arm64. Although, while I'm doing so, I thought I'd help out resolve any issues along the way. I'll try the latest patch and report back soon.

Thanks again.

[jhoyt4]

Thanks for posting that last log. I'm surprised that the PAGE_SIZE issue persists - it's definitely something more complicated than I had hoped for and this is probably the rabbit hole @kencu warned about. Unfortunately, I'm probably tapped for ideas that are easy to bounce back and forth with patch files (I'd need to get my hands on an M1 chip to push further).

As for compiling mythtv with the compileMythfrontendAnsible.zsh script, I've created a new forum post on the MythTv forums here ​https://forum.mythtv.org/viewtopic.php?f=26&t=4337 to try to get through the compile process (no longer appropriate for this trac ticket).

[ILMostro (ILMostro)]

All right,

Thanks a lot. Sorry, I was not able to help resolve this issue with qtwebkit. Although, it sounds like it may be a deprecated item anyway. Thanks, again.

[jhoyt4]

ok - so I now have this compiling on ARM.

I needed to patch FastMalloc.cpp for ARM

Also needed to patch Source/WTF/wtf/Platform.h to add logic for ARM64 aarch64 (thanks to a pointer from apple here: ​https://opensource.apple.com/source/WTF/WTF-7601.1.46.42/wtf/Platform.h.auto.html

Finally needed to patch Source/JavaScriptCore/heap/MachineStackMarker.cpp to accept the new CPU(ARM64) call put into Platform.h.

I'm still having issues getting mythtv to compile so I have not been able to test beyond compiling. I'm going to post a PR soon and hopefully I can get some help from someone to fully test this.

[jhoyt4]

fixed - requires MachineStackMarker.cpp.diff and Platform.h.diff patches

[kencu (Ken)]

Looking quite good there!

[jhoyt4]

patches and PR ​https://github.com/macports/macports-ports/pull/10119 for qtwebkit on ARM64 now tested and verified to work with mythfrontend v31 and mythweb.

I suspect the older versions of mythtv may work as well assuming those versions have had the ARM updates added to them. The key is adding the the --disable-lirc flag to configure since the ARM pieces seem to activate it.

[jhoyt4]

PR 10119 was accepted and merged with commit [a110ec094fdeb1e5b720f9e092fab557ee9785e4/macports-ports].

Hopefully this gets folks a little further along.

[ILMostro (ILMostro)]

Much better. Thank you!

There is yet another issue now while trying to compile mythfrontend v31.

ccache clang -c -pipe -D_FILE_OFFSET_BITS=64 -D_DARWIN_C_SOURCE -I/compat/dispatch_semaphore -DPIC -DZLIB_CONST -std=c11 -mdynamic-no-pic -DNDEBUG -fomit-frame-pointer -fPIC -pthread -I/opt/local/include/libxml2 -I/opt/local/include/ossp -I/opt/local/include/freetype2 -I/opt/local/include/libpng16 -g -Wall -Wextra -Wdisabled-optimization -Wpointer-arith -Wwrite-strings -Wundef -Wno-pointer-to-int-cast -Wstrict-prototypes -Wno-parentheses -Wno-format-zero-length -Wno-pointer-sign -Wno-unused-const-variable -Wno-bool-operation -O3 -fno-math-errno -fno-signed-zeros -mstack-alignment=16 -Qunused-arguments -Werror=implicit-function-declaration -Werror=return-type -fno-common  -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -mmacosx-version-min=10.13 -w -DUSING_APPLEREMOTE -D_GNU_SOURCE -DHAVE_CONFIG_H -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I. -I/opt/local/libexec/qt5/include -I/opt/local/include/libxml2 -I. -I../.. -I../../libs/libmythbase -I/opt/local/libexec/qt5/lib/QtGui.framework/Headers -I/opt/local/libexec/qt5/lib/QtCore.framework/Headers -Imoc -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/AGL.framework/Headers -I/opt/local/libexec/qt5/mkspecs/macx-clang -F/opt/local/libexec/qt5/lib -o obj/udfread-version.o udfread-version.c
rm -f libmythudfread-32.a
ar rc libmythudfread-32.a obj/default_blockinput.o obj/ecma167.o obj/udfread.o obj/udfread-version.o
ranlib libmythudfread-32.a
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C libmythsoundtouch all
ccache clang++ -c -pipe -stdlib=libc++ -D_FILE_OFFSET_BITS=64 -DPIC -std=c++17 -faligned-new -DNDEBUG -fomit-frame-pointer -fPIC -DQT_DISABLE_DEPRECATED_BEFORE=0x050900 -pthread -g -Wall -Wextra -Wpointer-arith -Wno-constant-logical-operand -Wno-unused-value -Qunused-arguments -Wimplicit-fallthrough -fPIC -std=gnu++1z  -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -mmacosx-version-min=10.13 -w -DUSING_APPLEREMOTE -D_GNU_SOURCE -I. -I/opt/local/libexec/qt5/include -I/opt/local/include/libxml2 -I. -I../.. -I/opt/local/libexec/qt5/mkspecs/macx-clang -o obj/AAFilter.o AAFilter.cpp
In file included from AAFilter.cpp:45:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/math.h:309:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/type_traits:417:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/cstddef:37:
../../version:1:1: error: C++ requires a type specifier for all declarations
SOURCE_VERSION="v32-Pre"
^
../../version:1:25: error: expected ';' after top level declarator
SOURCE_VERSION="v32-Pre"
                        ^
In file included from AAFilter.cpp:45:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/math.h:309:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1/type_traits:418:
../../version:1:1: error: C++ requires a type specifier for all declarations
SOURCE_VERSION="v32-Pre"
^
../../version:1:25: error: expected ';' after top level declarator
SOURCE_VERSION="v32-Pre"
                        ^
4 errors generated.
make[2]: *** [obj/AAFilter.o] Error 1
make[1]: *** [libmythsoundtouch-all] Error 2
make: *** [external] Error 2
    Compiling Mythtv failed

[jhoyt4]

Yep - just stumbled on this myself last week

There is a conflict with the source's VERSION file with the system's version header.

Quick solution - rename VERSION to something else (like VERSION.bak).

I have an issue report open with Apple as I believe this case sensitivity is a new Xcode regression and am typing up an email to the mythtv devs asking for help on how to resolve properly.

Another solution is to downgrade your Xcode version.

[jhoyt4]

SOURCE_VERSION="v32-Pre"

BTW - it looks like you're compiling master and not fixes/31.

No big deal - both should work, but will cause an issue if you're expecting to connect to a fixes/31 backend.

[kencu (Ken)]

there are hundreds if not thousands of ports with this VERSION issue, because c++17 has a header named <version> and autotools long has had a file named VERSION.

We have fixed this dozens and dozens of times already building ports with clang-9.0.

There is no fixing Xcode for this I believe; Xcode finally shipped a clang version with this header, so now there are. more people seeing it, as macOS is usually case-insensitive (that's probably the real error, likely NTBF...)

[jhoyt4]

@kencu - thank you for the additional data. I'll try to get the VERSION file fixed upstream for v31 / master.

[ILMostro (ILMostro)]

Thank you very much for your continued work and details. Thanks for pointing that out @jhoyt4 regarding the git branch. I'll see if I can resolve it locally, as I'm using the z-shell script from mythtv's github page to compile: ​https://github.com/MythTV/packaging/tree/master/OSX/build/macports_ansible

It's always a good idea to review what you're about to execute :D Oops.

[jhoyt4]

I'm familiar with that script. I have an updated copy that works around the VERSION issue here: ​https://sourceforge.net/p/mythtvformacosx/buildScript/ci/master/tree/

I don't have commit writes to the official MythTV packaging git repo, so I tend to post fixes to the build script to SourceForge more regularly since I do have rights there.

BTW - if you're looking for support for that script or MythTV in general, it's probably best to do it on the mythtv forums: ​https://forum.mythtv.org/

For example, some helpful advice on modding the build script to install locally on your system and not the ~/32-osx-64bit can be found at the end of this thread: ​https://forum.mythtv.org/viewtopic.php?f=26&t=3800

Finally - if you do get mythbackend running after compiling with that script (it compiles no issues), please add anything you did to get it working here: ​https://www.mythtv.org/wiki/Building_MythFrontend_on_Mac_OS_X

[chrstphrchvz (Christopher Chavez)]

See #64126: older Qt ports either need to build successfully on newer macOS, or be marked known_fail yes to avoid tying up the buildbots.

phantomjs-qt-qtwebkit and possibly other older qtwebkit ports are likewise affected by the Unsupported PAGE_SHIFT amount issue with macOS 11+ SDKs. Because phantomjs-qt-qtbase and other older qtbase ports will likely never build for ARM64, the x86_64 builds will instead try to be used under Rosetta 2.

Upstream WebKit made changes in 2014 to accommodate variable page size/shift amounts.

Discussion: ​https://bugs.webkit.org/show_bug.cgi?id=129370

Patch for relevant source code file: ​https://trac.webkit.org/changeset?old=164727&old_path=webkit%2Ftrunk%2FSource%2FWTF%2Fwtf%2FFastMalloc.cpp&new=164742&new_path=webkit%2Ftrunk%2FSource%2FWTF%2Fwtf%2FFastMalloc.cpp

I find that applying these changes are enough to allow phantomjs-qt-qtwebkit to build on macOS 12 x86-64.

Unless the qt5-qtwebkit port is updated to newer qtwebkit not affected by this issue, I would suggest that it backport upstream’s proper fix instead of trying to hardcode size/shift amounts to work, even though production Rosetta 2 does not use different page size/shift amounts than actual x86-64.

[jhoyt4]

@chrstphrchvz - this was already fixed in PR 10119 was accepted and merged with commit [a110ec094fdeb1e5b720f9e092fab557ee9785e4/macports-ports].

The mythtv stuff I have since fixed upstream.

[jhoyt4]

also, as this was already fixed, the known_fail is not necessary for this issue.

[chrstphrchvz (Christopher Chavez)]

I am aware the approach used for qt5-qtwebkit was already committed. What I meant by commenting here is that the this ticket’s affected ports should have included other qtwebkit ports (to avoid separate technically-duplicate tickets being opened for other ports with the same issue), and to consider using the upstream approach in qt5-qtwebkit instead of the one it currently uses (to keep fixes consistent between ports affected by an issue).

[chrstphrchvz (Christopher Chavez)]

In c79eda419c3963c074e4e9ce31a95296636bd500/macports-ports (master):

phantomjs-qt-qtwebkit: fix build on macOS 11+

See: #62027#comment:49

[babaz8]

Hi guys, I have issues installing qt5-qtbase on a M1 Pro 12.3 .

I receive these errors

--->  Computing dependencies for qt5-qtbase


--->  Fetching archive for qt5-qtbase


--->  Attempting to fetch qt5-qtbase-5.15.3_0+openssl.darwin_21.arm64.tbz2 from https://nue.de.packages.macports.org/qt5-qtbase


--->  Attempting to fetch qt5-qtbase-5.15.3_0+openssl.darwin_21.arm64.tbz2 from https://fra.de.packages.macports.org/qt5-qtbase


--->  Attempting to fetch qt5-qtbase-5.15.3_0+openssl.darwin_21.arm64.tbz2 from http://fco.it.packages.macports.org/qt5-qtbase


--->  Configuring qt5-qtbase


Error: Failed to configure qt5-qtbase: configure failure: command execution failed


Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt5/qt5-qtbase/main.log for details.


Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.


Error: Processing of port qt5-qtbase failed

Thanks for support.

[chrstphrchvz (Christopher Chavez)]

In a2575d01732589ebaf4bf6e4b151f42cb1c43f45/macports-ports (master):

qt(55|56|57|58|59|511|513)-qtwebkit: macOS 11+ fix

See: #62027#comment:49

[skip ci]

[jhoyt4]

In 8b528349a8adb591352e8a81ec884764c7bb8e65/macports-ports (master):

qt5-qtwebkit: Fix build for Big Sur, Monterey, and Ventura with header conflicts

On case insensitive file systems, the include search path picks up header files from
macports before the local header files causing an error while compiling. This
modification places flags the known conflicting ports with conflicts_build.

Closes: #63877
Closes: #62027
Closes: #66177
Closes: #63566

[skip ci]

fun