qt5-kde on MacOS 12.6.2 , SDK 13.1

[21stcaveman]

Been having a bit of an issue when trying to install qt5-kde on a fresh install of Monterey 12.6.2 Installed XCode 14.2 which comes with SDK 13.1 When I get to configure part of qt5-kde, it complains about not finding the SDK for 'macosx12'. I tracked that down to line 719 of the Portfile. 'xcrun --show-sdk-path -sdk macosx12' indeed fails on this system, so I tried 'xcrun --show-sdk-path -sdk macosx' and 'xcrun --show-sdk-path -sdk macosx13.1', they both work fine. I commented everything out from line 719 to line 742 (simply didn't put enough time to understand why it breaks! sorry.) except for this part:

set SDK [exec xcrun -show-sdk-version]
if {[catch {exec xcrun --show-sdk-path -sdk macosx${SDK}} result]} {
    ui_msg "Couldn't find the preferred nor a SDK macosx${SDK}: ${result}"
    ui_msg "WARNING: this has been known to lead to build errors"
} else {
    ui_debug "Using default SDK macosx${SDK}"
    configure.args-append \
            -sdk macosx${SDK}
}

That did fix the configure part.

[RJVB]

Thanks. Could you try to revert the out-commenting and putting the following below the set SDK ... line:

                if {${SDK} >= 12} {
                    # on this (and newer?) OS versions we need to use `-sdk macosx`
                    # see https://github.com/RJVB/macstrop/issues/92
                    set SDK ""
                }

The code around it is for figuring out the SDK to use on older OS versions, and also provides a hook for the user to override the SDK via the commandline.

[21stcaveman]

hmmm.. doesn't seem to work. This is what I did:

...
               # the preferred matching SDK isn't available; check if the default SDK is
                set SDK [exec xcrun -show-sdk-version]
                if {${SDK} >= 12} {
                    # on this (and newer?) OS versions we need to use `-sdk macosx`
                    # see #92
                    set SDK ""
                }
                if {[catch {exec xcrun --show-sdk-path -sdk macosx${SDK}} result]} {
                    ui_msg "Couldn't find the preferred nor a SDK macosx${SDK}: ${result}"
                    ui_msg "WARNING: this has been known to lead to build errors"
...

and I get this in the configure step: Project ERROR: Could not resolve SDK --show-sdk-path for 'macosx12'

[21stcaveman]

well, it turns out it doesn't even get to that. I see:

sdkroot was /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Using SDK from configure.sdkroot= /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk

How is 'sdkroot' set?

[RJVB]

On Tuesday January 03 2023 20:02:18 Hamid wrote:

hmmm.. doesn't seem to work. This is what I did: if {[catch {exec xcrun --show-sdk-path -sdk macosx${SDK}} result]} { ... and I get this in the configure step: Project ERROR: Could not resolve SDK --show-sdk-path for 'macosx12'

It looks like the modification did not do what I intended, i.e. removing the 12 from macosx12.

What output do you get from adding the following line under the set SDK ... command? ui_msg "SDK='${SDK}'"

[21stcaveman]

I won't even see that messgage, because the if in line 719 passes with true (configure.sdkroot is not empty). So it won't even get into the else clause. I'm not passing the sdkroot, and it is not an env variable on my system. if I understand correctly, line 851 clears configure.sdkroot , correct? If that is correct, how is sdkroot set for the 'if' in line 719?

[RJVB]

I won't even see that messgage, because the if in line 719 passes with true (configure.sdkroot is not empty). So it won't even get into the else clause.

Doh, of course. But you could move the set SDK ... line with the subsequent ui_msg command above the if. That shouldn't make a difference.

BTW, can you confirm that os.major is indeed 12 on your system?

I'm not passing the sdkroot, and it is not an env variable on my system. if I understand correctly, line 851 clears configure.sdkroot , correct? If that is correct, how is sdkroot set for the 'if' in line 719?

I'm guessing it's being set by "base", and it's being cleared after line 719 has been seen. This is probably to avoid it being used the usual way.

[21stcaveman]

oh, sure. I've put this before the if:

set SDK [exec xcrun -show-sdk-version]
ui_msg "SDK='${SDK}' , os.major='${os.major}'"

and this is the message it prints out : SDK='13.1' , os.major='21'

I'm on MacOS Monterey, v12.6.2

[RJVB]

On Wednesday January 04 2023 13:23:56 Hamid wrote:

oh, sure. I've put this before the if:

set SDK [exec xcrun -show-sdk-version]
ui_msg "SDK='${SDK}' , os.major='${os.major}'"

and this is the message it prints out : SDK='13.1' , os.major='21'

My bad, I should have asked you to (also) add the if block intended to reset SDK before the printout, to see if that somehow fails.

If you want to know whether configure.sdkroot (or any other variable) is set by "base", the simplest way would be to create a file called Portfile (in a directory which doesn't already have one ;)), containing

PortSystem 1.0

name foo
version 1

ui_msg ${configure.sdkroot}

Then, executing port info inside that directory will print out the value of the variable.

[21stcaveman]

you mean something like this?

set SDK [exec xcrun -show-sdk-version]
if {${SDK} >= 12} {
    set SDK ""
}
ui_msg "SDK='${SDK}' , os.major='${os.major}'"

If I add that, I get: SDK='' , os.major='21' which shows that it works. But in my case, it never actually gets to that point, because sdkroot is set.

Now, as mentioned above, sdkroot is set to /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk. Looking at lines 721 and 722 of the Portfile, we are extracting the last bit (which is macosx12) and passing it to -sdk option if sdkroot is set. I suspect something like this would fix the problem:

...
if {${os.major} >= 21} {
    # on this (and newer?) OS versions we need to use `-sdk macosx`
    # see [#92](https://github.com/RJVB/macstrop/issues/92)
    configure.args-append -sdk macosx
} else {
    if {${configure.sdkroot} ne ""} {
    ...
}
...

[21stcaveman]

also, since we're talking about this port, I had to apply this patch again for it to build. Not sure if that should be included or not, just fyi.

[RJVB]

OK, I think I understand now. The error about a macosx12 SDK that you get is printed by the configure script, I should probably have realised that earlier.

That probably also means you're on one of those OS versions which does not by default have the SDK corresponding to its own version ... and really that configure.sdkroot is set inappropriately in your case. Could you check if indeed you don't have a v12 SDK installed? If not, you could post a question about that on one of the mailing lists.

[RJVB]

also, since we're talking about this port, I had to apply this patch again for it to build. Not sure if that should be included or not, just fyi.

Did you pull since xmas? I fixed that issue that day, from what I can see (or at least tried).

I'm about to push a tentative fix for the current issue; if not successful feel free to reopen!

[21stcaveman]

Did you pull since xmas? I fixed that issue that day, from what I can see (or at least tried). I'm about to push a tentative fix for the current issue; if not successful feel free to reopen!

I did. This is a new laptop, so I pulled the latest. qt-everywhere still failed to build, and I applied that patch to fix it. Sounds good, thanks for all the time you put into this, appreciate it.

[RJVB]

That's weird, so you pulled the ports tree AND did a port clean qt5-kde or at least a port-redo-install-phase -patch qt5-kde? The patch should have been applied automatically in that case!

[RJVB]

That's weird, so you pulled the ports tree AND did a port clean qt5-kde or at least a port-redo-install-phase -patch qt5-kde? The patch should have been applied automatically in that case!

I just saw that I had forgotten (stupidly) that os.major corresponds to the Darwin version, not to the OS major version as we think of it and it should be used here (i.e. 10 for the original Mac OS X). That ought to be fixed now...

[21stcaveman]

fyi, just upgraded to 12.6.7 and rebuilt qt5-kde, the patch was automatically applied.

I did run into another issue, where it tries to compile a VERSION file, and complains about 'This' not being a defined type! had to fix it by commenting the entire file out. Not sure why, but I do run into that here and there with different ports. in this case, it was : qt-everywhere-opensource-src-5.9.8/qtscript/src/3rdparty/javascriptcore/VERSION

[RJVB]

Not sure why, but I do run into that here and there with different ports.

What do you mean with "with different ports"? Not just the qt5-kde ports? And what do those files contain?

My qt-everywhere-opensource-src-5.9.8/qtscript/src/3rdparty/javascriptcore/VERSION contains non-code that should never be compiled:

This is a snapshot of JavaScriptCore from

        git://gitorious.org/qtwebkit/qtwebkit.git

The commit imported was from the

        javascriptcore-snapshot-27012011 branch/tag

and has the sha1 checksum

        3ab0f621048fbeb480b687a28ed31d92d8506150

It'd be interesting to see the logfile around where that error occurs, next time you run into it!

[21stcaveman]

What do you mean with "with different ports"? Not just the qt5-kde ports?

Honestly, it might have been this port before, I just don't remember it. Would need to check my notes.

My qt-everywhere-opensource-src-5.9.8/qtscript/src/3rdparty/javascriptcore/VERSION contains non-code that should never be compiled

Mine as well! that's the thing. It throws an error saying 'This' is not defined in file qtscript/src/3rdparty/javascriptcore/version , where that file shouldn't even be included in the compilation list! as soon as I put that entire file in / /, the error goes away and all is fine. I'll try to post the logfile next time.

[RJVB]

'This' is not defined in file qtscript/src/3rdparty/javascriptcore/version

Wait, version, not VERSION - are you building on a case-insensitive filesystem? Not that I can find a file with the name in all-lowercase letters but who knows if the presence of such a file is taken into account in some way...

[21stcaveman]

Judging by the fact that issue is resolved by commenting out the VERSION file, I would say no. It is the same file.

[RJVB]

Well, that's logical on a case-insensitive filesystem! VERSION and version would both point to the same file.

I've already run into aliasing problems like this with C++ headers in KDE where the devs thought it was clever to put them in include/Foo/ and the C headers in include/foo or some scheme like that.

Anyway, I don't see any evidence in the build system that it would use a file called VERSION (nor version) so I'd really need the relevant part of your main.log in order to triage this further.

[21stcaveman]

SO, had to rebuild today, and got a chance to copy the main.log file. Here is the first error caused by the version file (line 538151):

:info:build cd script/ && ( test -e Makefile || /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde/qt5-kde/work/build/qtbase/bin/qmake -o Makefile /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde/qt5-kde/work/qt-everywhere-opensource-src-5.9.8/qtscript/src/script/script.pro ) && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile :info:build make[3]: Entering directory '/opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde/qt5-kde/work/build/qtscript/src/script' ... :info:build In file included from /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde/qt5-kde/work/qt-everywhere-opensource-src-5.9.8/qtscript/src/3rdparty/javascriptcore/JavaScriptCore/pcre/pcre_compile.cpp:44: :info:build In file included from /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde/qt5-kde/work/qt-everywhere-opensource-src-5.9.8/qtscript/src/3rdparty/javascriptcore/JavaScriptCore/config.h:68: :info:build In file included from /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde/qt5-kde/work/qt-everywhere-opensource-src-5.9.8/qtscript/src/3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.h:27: :info:build In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/c++/v1/new:91: :info:build In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/c++/v1/cstddef:37: :info:build /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde/qt5-kde/work/qt-everywhere-opensource-src-5.9.8/qtscript/src/3rdparty/javascriptcore/version:1:1: error: unknown type name 'This' :info:build This is a snapshot of JavaScriptCore from :info:build ^ :info:build /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde/qt5-kde/work/qt-everywhere-opensource-src-5.9.8/qtscript/src/3rdparty/javascriptcore/version:1:8: error: expected ';' after top level declarator :info:build This is a snapshot of JavaScriptCore from :info:build ^

I can send you the log file, if it would be useful.

[RJVB]

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/usr/include/c++/v1/cstddef:37: :info:build /opt/local/var/macports/build/_opt_local_site-ports_aqua_qt5-kde/qt5-kde/work/qt-everywhere-opensource-src-5.9.8/qtscript/src/3rdparty/javascriptcore/version:1:1: error: unknown type

Hah! You did find a "bug": clearly qtscript predates the existence of the C++ version headerfile of which I had no idea. Or before that file got included indirectly via one of the headerfiles required for building javascriptcore.

In Qt 5.12 that src/3rdparty/javascriptcore/version file is called VERSION.TXT; I'll have to do a renaming. Can I ask you do that on your end and see if that doesn't lead to other issues?

Thanks!

[RJVB]

Looking at this a bit more I see I was right about the fact that this was related to using a case-insensitive filesystem!

Officially that file is called qt-everywhere-opensource-src-5.9.8/qtscript/src/3rdparty/javascriptcore/VERSION so on a "normal" build system the file would never be included through #include <version> !

[RJVB]

FWIW, this is the change that I'd commit if you can confirm it doesn't break anything:

diff --git a/aqua/qt5-kde/Portfile b/aqua/qt5-kde/Portfile
index 798267d5..c8cecdd3 100644
--- a/aqua/qt5-kde/Portfile
+++ b/aqua/qt5-kde/Portfile
@@ -1079,6 +1079,11 @@ if { (${subport} eq ${name}) || (${subport} eq "${name}-x11") } {
                 }
             }
         }
+        # rename a file that can alias a C++ headerfile on case-insensitive filesystems
+        # see https://github.com/RJVB/macstrop/issues/92
+        file delete -force ${worksrcpath}/qtscript/src/3rdparty/javascriptcore/VERSION.TXT
+        file rename ${worksrcpath}/qtscript/src/3rdparty/javascriptcore/VERSION \
+            ${worksrcpath}/qtscript/src/3rdparty/javascriptcore/VERSION.TXT
     }

     if {${os.platform} eq "darwin" && ${os.major} < 17} {

[21stcaveman]

Just rebuilt the port with these changes, all went well. I think you're good to merge that.

[RJVB]

Thanks, will do (when I'm done with updating port:libcxx ...)

[21stcaveman]

What do you mean with "with different ports"? Not just the qt5-kde ports?

Honestly, it might have been this port before, I just don't remember it. Would need to check my notes.

Aha, found the other one! same thing happens to the 'qgpgme' port.

[RJVB]

You mean gpgme-1.10.0/VERSION ?

[21stcaveman]

yup, that's the one.