iTerm2: error: property 'safeAreaInsets' not found on object of type 'iTermRootTerminalView *'

[szhorvat (Szabolcs Horvát)]

iTerm2 fails to build on my system, and no binaries seem to be available. Build log is attached.

I am using:

macOS 10.14.6 18G9323 x86_64 Xcode 11.3.1 11C504

[ryandesign (Ryan Carsten Schmidt)]

The error in the log is:

error: property 'safeAreaInsets' not found on object of type 'iTermRootTerminalView *'

​According to Apple safeAreaInsets is an iOS / iPadOS / tvOS / Mac Catalyst function that is not available on macOS so its use in a Mac project like iTerm2 surprises me. According to the iTerm2 source code, it should only be used on macOS 12 or later. Maybe the function became available in macOS 12 and Apple hasn't updated the documentation. But this means iTerm2 needs the macOS 12 SDK to build, which is of course not available on macOS 10.14.

[szhorvat (Szabolcs Horvát)]

I asked the developer if building on 10.14 is still meant to be supported: ​https://gitlab.com/gnachman/iterm2/-/issues/10034

[markemer (Mark Anderson)]

I'll check it out, but I bet it is - the latest shipping version was built on XCode 13 with the macOS 12 SDK. So it may not be buildable on less than macOS 11 with Xcode 13 - soon to be macOS 12 only I bet. It might still run on older hardware thanks to @available(macOS 12, *)

[markemer (Mark Anderson)]

I'm certain of it now from the release notes:

3.4.12

This is a bugfix release to correct a problem with version 3.4.11 on Macs with a notch.

... snip ...

In order to fix that bug, you're going to need Xcode 13. I'm thinking that maybe we should do build or binary on macOS 12 and maybe just a binary install on 10.14 - 11, and then the last known working version before 10.12 - iTerm2 is getting progressively harder to support building on older machines. There is a part of me that only wants to make it available if you have Xcode 13, but that's against the spirit of macports supporting back to 10.old, so if anyone has a good idea, let me know - the older version is getting trickier to build as well.

Seems this is the version landscape:

• Latest (OS 10.14+) only builds on 11 or 12
• Unknown Version (OS 10.14+) will build on 10.14/10.15
• iTerm2 3.3.12 (OS 10.12+) Does it build on 10.12?
• iTerm2 3.1.7 (OS 10.10+)
• iTerm2 3.0.15 (OS 10.8+)
• iTerm2 2.1.4 (OS 10.7+, Intel-only)
• iTerm2 2.0 (OS 10.5, Intel, PPC)

Do we maybe want to use last checkouts that build on 10.X, 11.X, and latest on latest?

I'm honestly not certain exactly. We officially support back to where in MacPorts? I don't want to support version 2 of iTerm2, but going back to 10.10 would be semi-manageable.

[szhorvat (Szabolcs Horvát)]

Shouldn't it be easy to restore compatibility by making that if (@available(macOS 12, *)) section compile conditionally on the SDK version? Maybe the maintainer of iTerm2 is willing to do it? If not, maybe it can be patched in MacPorts?

[markemer (Mark Anderson)]

I'm willing to bet that's already in there. The problem is that Xcode still compiles those bits - it just leaves them out of the runtime. This comes down to the big problem with building macOS apps in general on unknown - we can get them to run as low as 10.9 (oof) using Xcode 13 - but we can't run Xcode 13 on anything but 11 and maybe soon just 12. And if your app only builds on Xcode 13 - then you're stuck only building them there.

[szhorvat (Szabolcs Horvát)]

It seems the iTerm2 author may not respond to the issue I opened, so the solution has to come from MacPorts. I'd be happy with any solution that keeps iTerm2 installable with MacPorts, even if just an older version.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #63924.

Replying to markemer:

Seems this is the version landscape:

• Latest (OS 10.14+) only builds on 11 or 12
• Unknown Version (OS 10.14+) will build on 10.14/10.15
• iTerm2 3.3.12 (OS 10.12+) Does it build on 10.12?
• iTerm2 3.1.7 (OS 10.10+)
• iTerm2 3.0.15 (OS 10.8+)
• iTerm2 2.1.4 (OS 10.7+, Intel-only)
• iTerm2 2.0 (OS 10.5, Intel, PPC)

Do we maybe want to use last checkouts that build on 10.X, 11.X, and latest on latest?

Please. (By which I mean: for each macOS version, the port should offer the latest version that can build on that OS version.) The port already has several such clauses; hopefully it is not too difficult to add more to at least cover recent OS versions.

[i0ntempest]

Just something I noticed when fixing another problem - if using Xcode pg to build this the error will be different, something related to Metal.

[Gandoon (Erik Hedlund)]

This issue seems to be present on several OS versions. I am using MacOS 10.15 and do also get the "iTerm2SandboxedWorker isn't code signed but requires entitlements" error (the same as in the now marked as duplicate #63924) when trying to build any iTerm2 post v3.4.13. It is not fully clear to me where in the build this signing is performed, but it sure presents problems.

I also tried to build a gitHub clone, and it also fails to build, but with (seemingly) other errors. One prominent issue (that seems to be a recurring theme for software that should end up in .app containers) seems to be swift-related (max version 5.3.2 on 10.15). Mismatched versions always seems to end up in failures. There is limited forward compatibility. If there are frameworks that have been built for v5.5, it most certainly won't work with 5.3.2 for this particular piece of software I noticed.

[Gandoon (Erik Hedlund)]

Replying to Gandoon (myself and everyone else):

This issue seems to be present on several OS versions. I am using MacOS 10.15 and do also get the "iTerm2SandboxedWorker isn't code signed but requires entitlements" error (the same as in the now marked as duplicate #63924) when trying to build any iTerm2 post v3.4.13. It is not fully clear to me where in the build this signing is performed, but it sure presents problems.

I also tried to build a gitHub clone, and it also fails to build, but with (seemingly) other errors. One prominent issue (that seems to be a recurring theme for software that should end up in .app containers) seems to be swift-related (max version 5.3.2 on 10.15). Mismatched versions always seems to end up in failures. There is limited forward compatibility. If there are frameworks that have been built for v5.5, it most certainly won't work with 5.3.2 for this particular piece of software I noticed.

I just want to announce that I found a workaround for my older system. I could confirm that the swift frameworks must indeed be built by the build system, as they do not give any issues with my older (Xcode v12.4 with Swift 5.3.2 on MacOS 10.15.7) system. I now have a working MacPorts build of iTerm2 @3.4.15_1.

However I needed to remove three statements in two .m-files to get it to build. The issue seemed to be statements relating to specific MacOS 12 features (I think they may have something to do with notch handling on the newer Apple silicon machines). The functionalities may indeed only be present in newer variants of the SDKs, thus breaking building on older variants.

The statements in questions are:

In NSScreen+iTerm.m, on lines 97 and 113:

- (CGFloat)notchHeight {
    if (@available(macOS 12.0, *)) {
//        return self.safeAreaInsets.top;
    }
    return 0;
}

. . . 

- (CGFloat)it_menuBarHeight {
    if (@available(macOS 12, *)) {
        // When the "current" screen has a notch, there doesn't seem to be a way to get the height
        // of the menu bar on other screens :(
//        return MAX(24, self.safeAreaInsets.top);
    }
    return NSApp.mainMenu.menuBarHeight;
}

And in iTermRootTerminalView.m, on lines 1257-1258 (I did actually disable the whole if-block here, I could have done that in the previous file as well I guess):

//    if (@available(macOS 12, *)) {
//        // self.safeAreaInsets is all 0s on a notch Mac. Why the hell doesn't anything work right?
//        const NSEdgeInsets safeAreaInsets = self.window.screen.safeAreaInsets;
//        return safeAreaInsets.top;
//    }

I found the root of the issue by making a copy of the build directory and building it with Xcode directly, then making the same modifications in the build directory and running port -v build to confirm that everything worked. Finally a port -v upgrade iTerm2 ran smoothly and the application installed and runs as intended.

There may be a need for a conditional patch that removes/comments out those uses of safeAreaInsets on older systems.

[lordmorgul]

I see this failure to build. My system is a little older but the OS isn't that old (pending an update currently which I will do soon)

MacOS 11.6.2 (20G314) MacBook Pro (Retina, 15-inch, Mid 2014)

version:1
:debug:clean Starting logging for iTerm2 @3.4.14_0
:debug:sysinfo macOS 11.6.1 (darwin/20.6.0) arch i386
:debug:sysinfo MacPorts 2.7.1
:debug:sysinfo Xcode 12.2
:debug:sysinfo SDK 11
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 11.0
:debug:clean iTerm2 has no conflicts

[Gandoon (Erik Hedlund)]

Replying to lordmorgul:

I see this failure to build. My system is a little older but the OS isn't that old (pending an update currently which I will do soon)

MacOS 11.6.2 (20G314) MacBook Pro (Retina, 15-inch, Mid 2014)

I have the same hardware as you, but with the older 10.15 OS. I have the build system Xcode 12.4 Build version 12D4e, and managed to have the version @3.4.15_1 built with the minor edits I referenced above. If you still have issues building iTerm2, try removing the checks for notches I described and see if it works for you then. It may very well be that those specific fields are undefined in systems older than MacOS 12.