allegro5: Build failure with OS X 10.11 SDK and earlier

[dionoid (Dionoid)]

Currently the allegro5 MacPorts is failing for macOS El Capitan, while I'm able to compile allegro5 with brew.

When I look into the log files of the failed compilation, I see errors like use of undeclared identifier 'NSWindowStyleMaskTitled', while this Enumeration Case is supported in macOS 10.11.

Looks like maybe something isn't configured correctly?

[ryandesign (Ryan Carsten Schmidt)]

It looks like we see possibly the same error on the 10.11 and earlier buildbot machines, e.g.:

​https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/294560

[ryandesign (Ryan Carsten Schmidt)]

Replying to dionoid:

I see errors like use of undeclared identifier 'NSWindowStyleMaskTitled', while this Enumeration Case is supported in macOS 10.11.

As far as I can tell, NSWindowStyleMaskTitled is only in the macOS 10.12 SDK and later.

[dionoid (Dionoid)]

NSWindowStyleMaskTitled has been available in all macOS SDK's, see ​https://developer.apple.com/documentation/appkit/nswindow/stylemask-swift.struct/titled?language=objc

Maybe there was some confusion with NSTitledWindowMask, which was deprecated in macOS 10.12?

[ryandesign (Ryan Carsten Schmidt)]

Replying to dionoid:

NSWindowStyleMaskTitled has been available in all macOS SDK's, see ​https://developer.apple.com/documentation/appkit/nswindow/stylemask-swift.struct/titled?language=objc

I see no information at that URL that says what versions it's available in.

I based my statement on the results of ​this search.

Looking at NSWindow.h in the 10.11 SDK it says:

enum {
    NSBorderlessWindowMask = 0,
    NSTitledWindowMask = 1 << 0,
    NSClosableWindowMask = 1 << 1,
    NSMiniaturizableWindowMask = 1 << 2,
    NSResizableWindowMask       = 1 << 3,

vs in the 10.12 SDK it says:

typedef NS_OPTIONS(NSUInteger, NSWindowStyleMask) {
    NSWindowStyleMaskBorderless = 0,
    NSWindowStyleMaskTitled = 1 << 0,
    NSWindowStyleMaskClosable = 1 << 1,
    NSWindowStyleMaskMiniaturizable = 1 << 2,
    NSWindowStyleMaskResizable  = 1 << 3,

So if this is to work with the 10.11 SDK or earlier, where NSWindowStyleMaskTitled is not available, the code will need to define NSWindowStyleMaskTitled to be equal to NSTitledWindowMask.

This would be an upstream bug that you could file with the developers of allegro.

I'm not entirely sure why we see this problem on our 10.11 build machine since it has Xcode 8.2.1 installed which has the 10.12 SDK.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

I'm not entirely sure why we see this problem on our 10.11 build machine since it has Xcode 8.2.1 installed which has the 10.12 SDK.

I don't see anything in the log that shows an SDK from Xcode or command line tools actually being used, so it may be using the SDK at / which would match the OS version. MacPorts only forces the use of an Xcode or CLT SDK on macOS 10.14 and later since the SDK at / was removed at that point.

[dionoid (Dionoid)]

Thanks for looking into this!

Ok, now this confuses me. If I take NSWindowStyleMaskFullScreen as another example: According to Apple developer documentation, the Enumeration Case NSWindowStyleMaskFullScreen has been available on macOS 10.7 and later (see ​https://developer.apple.com/documentation/appkit/nswindow/stylemask-swift.struct/fullscreen?language=objc)

However, when I search phracker's MACOSX-SDKs collection, I only see it included in SDKs 10.12 and onwards: ​https://github.com/search?q=repo%3Aphracker%2FMacOSX-SDKs+NSWindowStyleMaskFullScreen&type=code

Maybe I confused "available on macOS 10.x" with "supported in macOS 10.x SDK"?

Btw: the MacPorts logs for the 10.11 build shows usage of -mmacosx-version-min=10.11, which I think is the correct way of building for macOS 10.11 using a more recent SDK.

[dionoid (Dionoid)]

I'm not entirely sure why we see this problem on our 10.11 build machine since it has Xcode 8.2.1 installed which has the 10.12 SDK.

I don't see anything in the log that shows an SDK from Xcode or command line tools actually being used, so it may be using the SDK at / which would match the OS version. MacPorts only forces the use of an Xcode or CLT SDK on macOS 10.14 and later since the SDK at / was removed at that point.

With the 10.12 SDK available on the 10.11 build machine, it should indeed be able to build correctly —> which gives me hope!

I think you're probably right that it has fallen back to using the system headers & libs at /, instead of the 10.12 SDK.

[dionoid (Dionoid)]

Note that I managed to do a successfull MacPorts build of allegro5 on my MacBook (10.11 El Capitan) which has the 10.12 SDK (Xcode CLT) installed. I did that by passing the CMAKE_OSX_SYSROOT like this:

export SDKROOT=$(xcrun --sdk macosx --show-sdk-path)
sudo port install allegro5 configure.args="-DCMAKE_OSX_SYSROOT=$SDKROOT"

I think that Allegro uses CMake and by default falls back to the root / on older versions.

On the MacPorts buildbot machine you probably have a different path to the SDKROOT, as I understand the full Xcode is installed there.

[ryandesign (Ryan Carsten Schmidt)]

Replying to dionoid:

Ok, now this confuses me. If I take NSWindowStyleMaskFullScreen as another example: According to Apple developer documentation, the Enumeration Case NSWindowStyleMaskFullScreen has been available on macOS 10.7 and later (see ​https://developer.apple.com/documentation/appkit/nswindow/stylemask-swift.struct/fullscreen?language=objc)

However, when I search phracker's MACOSX-SDKs collection, I only see it included in SDKs 10.12 and onwards: ​https://github.com/search?q=repo%3Aphracker%2FMacOSX-SDKs+NSWindowStyleMaskFullScreen&type=code

Maybe I confused "available on macOS 10.x" with "supported in macOS 10.x SDK"?

Yes, in Apple documentation the availability information tends to refer to the minimum OS version for which you could set the deployment target, assuming you are using the latest SDK.

This matches Apple's preferred development methodology where the developer uses the latest macOS and Xcode and SDK and sets the deployment target to the oldest macOS version on which they want their binary to work.

This does not match how MacPorts works, however, because it does not work well for software that was not designed for macOS, in other words most open-source software available in MacPorts. MacPorts builds its binaries for each OS version separately and on the OS version that matches the deployment target.

I have filed a bug report with the developers of allegro5: ​https://github.com/liballeg/allegro5/issues/1655

[ryandesign (Ryan Carsten Schmidt)]

Replying to dionoid:

export SDKROOT=$(xcrun --sdk macosx --show-sdk-path)
sudo port install allegro5 configure.args="-DCMAKE_OSX_SYSROOT=$SDKROOT"

Note that by doing this you have replaced all of the configure.args that MacPorts would have set. You may thus have a build that does not match what we intended.

I don't see a benefit to changing the Portfile to use the SDK this way. It would only help the very limited set of users running OS X 10.11 with Xcode 8. It will not help users running OS X 10.11 with Xcode 7 nor users running OS X 10.10 or earlier. The correct fix that should help everyone is for the developers to use the old constants when building with old SDKs.

[dionoid (Dionoid)]

The correct fix that should help everyone is for the developers to use the old constants when building with old SDKs.

Agree

I have filed a bug report with the developers of allegro5: ​​https://github.com/liballeg/allegro5/issues/1655

Thanks for taking the time to file a bug report!