sqlitebrowser @ 3.12.2: Could not resolve SDK Path for 'macosx10.11'

[thetrial (alabay)]

This seems to be something known with other ports (#62857, #54044 and #53597). I got this now with sqlitebrowser.

Maybe a little problem? I hope so.

[i0ntempest]

Check your Xcode and command line tools are properly installed and try again, also upload your main.log please.

[i0ntempest]

Old versions of Qt seem to record SDK version and path, you're on 10.11 so maybe you're using one of these versions.

[thetrial (alabay)]

Xcode and the clt are installed properly for years. This happens on two machines. Qt-related software is not new in this environment – owncloud-client, KeePassXC, wireshark etc.

I tried again, it failed, I’ll attach the main log.

[i0ntempest]

What does xcrun --sdk macosx10.11 --show-sdk-path gives you? I don't think Xcode 8.2 has 10.11 SDK.

[thetrial (alabay)]

No, it doesn’t.

xcodebuild: error: SDK "macosx10.11" cannot be located. xcodebuild: error: SDK "macosx10.11" cannot be located. xcrun: error: unable to lookup item 'Path' in SDK 'macosx10.11'

But … is that, was that necessary?

[i0ntempest]

Some build systems don't know to look for the general MacOSX.sdk, just the version they want and that'll likely be you system version. You might try symlinking MacOSX10.12.sdk to MacOSX10.11.sdk in your Xcode SDK directory to force a build.

[thetrial (alabay)]

sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk

But the error remains. It seems this is not found.

[i0ntempest]

Then try downgrading to Xcode 7 and run the xcrun command above again, see if it picks the 10.11 SDK up. If yes then try again.

[thetrial (alabay)]

I’ve never downgraded Xcode yet. I even don’t know if this would not start other problems. Is there no other way or workaround? I don’t have version 7, if I obtain it and deinstall, reinstall, this would interfere with lots of other things.

This is the first time I see this problem. Why? The installations of sqlitebrowser worked before, with everything the same except macports (2.6.4) and sqlitebrowser itself.

[i0ntempest]

MacPorts 2.7 seems to have changed the way it finds SDKs, because the way Apple versions and puts SDKs in Xcode and CLTs changed when macOS 11 came out. Yes downgrading the whole Xcode installation might create problems with other ports. If you don't want to do that you might try downloading from ​https://xcodereleases.com and extract the 10.11 SDK only then put it into your current Xcode (and CLT) but I have no idea if that'll work. The sqlitebrowser port itself did not have any changes other than upgrading. Other than these I can't offer much help as a newbie maintainer, especially on older OSes.

[thetrial (alabay)]

I see. I guess this is a MacPorts related issue. We shouuld add MacPorts itself as problem. Though I don’’t know how at the moment, it is not a port.

[i0ntempest]

Just to make sure you could grab the old Portfile of sqlitebrowser and see if that builds with MP 2.7.0: ​https://raw.githubusercontent.com/macports/macports-ports/b044fe2e8f3681a0c90afed15fadf0f067ddec6e/databases/sqlitebrowser/Portfile
If still fails then it's most likely a problem in MP.

[thetrial (alabay)]

Due to I have the old 3.12.1 version installed … could you tell me how I manage that? Deinstalling the built build could be risky, ain’t that so? And how to use the old portfile?

[i0ntempest]

port file sqlitebrowser will tell you the file you'll need to replace, then run port clean sqlitebrowser, port build sqlitebrowser.
port selfupdate will revert the file you replaced.

[thetrial (alabay)]

I get a checksum error!

:debug:checksum checksum phase started at Fri May 21 09:57:51 CEST 2021
:notice:checksum --->  Verifying checksums for sqlitebrowser
:debug:checksum Executing org.macports.checksum (sqlitebrowser)
:info:checksum --->  Checksumming sqlitebrowser-3.12.1.tar.gz
:debug:checksum Calculated (rmd160) is b730772f6c34c2936480fcae51ea05b4989b0a06
:error:checksum Checksum (rmd160) mismatch for sqlitebrowser-3.12.1.tar.gz
:info:checksum Portfile checksum: sqlitebrowser-3.12.1.tar.gz rmd160 7ae35b7e1fee54df06764ee8934b347a73128cdc
:info:checksum Distfile checksum: sqlitebrowser-3.12.1.tar.gz rmd160 b730772f6c34c2936480fcae51ea05b4989b0a06
:debug:checksum Calculated (sha256) is 7abcf719fc83148ab116463fc63f498acc6e9bebd6fa9a8c2153c7351da7fb97
:error:checksum Checksum (sha256) mismatch for sqlitebrowser-3.12.1.tar.gz
:info:checksum Portfile checksum: sqlitebrowser-3.12.1.tar.gz sha256 7125cf77ef9f5eaa59aa5a4f0ae205a6d481246c333516e40b1bf24a606d9c17
:info:checksum Distfile checksum: sqlitebrowser-3.12.1.tar.gz sha256 7abcf719fc83148ab116463fc63f498acc6e9bebd6fa9a8c2153c7351da7fb97
:debug:checksum Calculated (size) is 3991068
:error:checksum Checksum (size) mismatch for sqlitebrowser-3.12.1.tar.gz
:info:checksum Portfile checksum: sqlitebrowser-3.12.1.tar.gz size 3990999
:info:checksum Distfile checksum: sqlitebrowser-3.12.1.tar.gz size 3991068
:info:checksum The correct checksum line may be:
:info:checksum checksums           rmd160  b730772f6c34c2936480fcae51ea05b4989b0a06 \
:info:checksum                     sha256  7abcf719fc83148ab116463fc63f498acc6e9bebd6fa9a8c2153c7351da7fb97 \
:info:checksum                     size    3991068
:error:checksum Failed to checksum sqlitebrowser: Unable to verify file checksums
:debug:checksum Error code: NONE
:debug:checksum Backtrace: Unable to verify file checksums

[i0ntempest]

Well that's weird, I'm getting it aswell. Try port clean --all sqlitebrowser before doing another build, if you still get the error manually edit the port file with these checksums, there might be a stealth upgrade.

[thetrial (alabay)]

Well, this problem now also occurs with 3.12.1.

:info:configure Project ERROR: Could not resolve SDK Path for 'macosx10.11' using --show-sdk-path
:info:configure Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_sqlitebrowser/sqlitebrowser/work/sqlitebrowser-3.12.1" && /opt/local/libexec/qt5/bin/qmake PREFIX=/opt/local CONFIG+=c++11 INCLUDEPATH+=/opt/local/libexec/qt5/include QMAKE_LIBDIR+=/opt/local/libexec/qt5/lib -spec macx-clang 

So it seems to be a MP issue, indeed. With 2.6.4 sqlitebrowser ran through.

[thetrial (alabay)]

After the update of macports from 2.6.4 to 2.7 mentioned problem occurs.

To verify we tried to reinstall a port that ran through with MP 2.6.4 – and the same problem occured. So it seems this is a MP issue.

I don’t know to whom this should be reassigned? Ports base is no port?

[jmroot (Joshua Root)]

Replying to i0ntempest:

Just to make sure you could grab the old Portfile of sqlitebrowser and see if that builds with MP 2.7.0: ​https://raw.githubusercontent.com/macports/macports-ports/b044fe2e8f3681a0c90afed15fadf0f067ddec6e/databases/sqlitebrowser/Portfile
If still fails then it's most likely a problem in MP.

Or one of the portgroups that this port uses.

[thetrial (alabay)]

With MacPorts 2.7.1 the problem still persists.

[ryandesign (Ryan Carsten Schmidt)]

Replying to i0ntempest:

You might try symlinking MacOSX10.12.sdk to MacOSX10.11.sdk in your Xcode SDK directory to force a build.

Doing that is not recommended. We should not be suggesting that to users. If you did that, please undo it.

[ryandesign (Ryan Carsten Schmidt)]

Replying to i0ntempest:

MacPorts 2.7 seems to have changed the way it finds SDKs, because the way Apple versions and puts SDKs in Xcode and CLTs changed when macOS 11 came out.

The SDK-finding fixes in MacPorts 2.7 should have had no effect for macOS 10.x. They were only to fix mistaken assumptions about how macOS 11 SDKs would be versioned that were released in MacPorts 2.6.4.

[kencu (Ken)]

see also #63061

[thetrial (alabay)]

Nothing new?

Is there any prospect? Or can we at least make sure sqlitebrowser stays out of the upgrade process?

[sambthompson (Sam Thompson)]

For what it's worth, I'm also seeing this problem with Xcode 8.2.1, but running the check gets the following:

% xcodebuild -version 
Xcode 8.2.1
Build version 8C1002
% xcrun --sdk macosx10.11 --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk

So not sure if there's any workaround? Log attached for comparison.

[sambthompson (Sam Thompson)]

xcode 8.2.1 on 10.11.6 main.log

[sambthompson (Sam Thompson)]

Replying to sambthompson:

For what it's worth, I'm also seeing this problem with Xcode 8.2.1, but running the check gets the following:

% xcodebuild -version 
Xcode 8.2.1
Build version 8C1002
% xcrun --sdk macosx10.11 --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk

So not sure if there's any workaround? Log attached for comparison.

Additional data point, not sure if I'm not now just masking the problem, but further investigation showed that while I had the 10.11 sdk installed inside the Xcode.app, and the xcode-select path was pointing to the app, I did not have the 10.11 sdk installed at /Library/Developer/CommandLineTools/SDKs. Copying this across from the app and then running sudo port clean sqlitebrowser then sudo port upgrade sqlitebrowser yielded a successful build and install. This also fixed a similar error I was having building qscintilla-qt5.

[thetrial (alabay)]

Replying to ryandesign:

Replying to i0ntempest:

You might try symlinking MacOSX10.12.sdk to MacOSX10.11.sdk in your Xcode SDK directory to force a build.

Doing that is not recommended. We should not be suggesting that to users. If you did that, please undo it.

I’ve symlinked MacOSX.sdk to MacOSX10.11.sdk … after that sqlitebrowser built. But I’m not sure if this is a clean solution. I see, that this error accumulates.

A little issue is that the app now states Error opening the remote file at https://download.sqlitebrowser.org/currentrelease. The certificate of the issuer of a locally found certificate could not be found when starting.

[thetrial (alabay)]

Oh, caveat. When using ln -s I get the error back again. It has to be done via Finder! So not symlinking but aliasing seems to work as a hack.

[jmroot (Joshua Root)]

I'll say it again: look at the portgroups. At least qmake5 underwent some SDK-related changes not long before this ticket was opened.

[i0ntempest]

Should be fixed with the configure.sdk_version workaround. If not please reopen.

[jmroot (Joshua Root)]

Suspect that's unnecessary as of [fbdae6e6c2cc9c2a8b8a625e322aeee6bd00e610/macports-ports].

[i0ntempest]

For me it's still required on macOS 12. I tried running xcrun --sdk macosx$VER --find ld in my terminal, it only works if I use 12.3. Neither 12 and 12.0 works.

[kencu (Ken)]

I am also kinda surprised this is still happening in this port, and not as yet 100% sure why... I thought we had made progress with that last commit to the qmake5 PortGroup, but there appears to be still more work to be done.