Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#55404 closed defect (fixed)

mpv @0.26.0: You manually enabled the feature 'cocoa', but the autodetection check failed

Reported by: mrkapqa Owned by: Ionic (Mihai Moldovan)
Priority: Normal Milestone:
Component: ports Version: 2.4.2
Keywords: lion Cc: mrkapqa, ryandesign (Ryan Carsten Schmidt)
Port: mpv

Description (last modified by ryandesign (Ryan Carsten Schmidt))

Hello ,

i get the following error when installing mpv on osx lion 10.7.4

--->  Attempting to fetch waf-1.9.8 from https://waf.io/
--->  Verifying checksums for mpv
--->  Extracting mpv
--->  Applying patches to mpv
--->  Configuring mpv
Error: Failed to configure mpv: configure failure: command execution failed

in the log it says

Cocoa                                                : no 
:info:configure You manually enabled the feature 'cocoa', but the autodetection check failed.

i have freshly installed osx lion 10.7.4 with xcode 4.6.3 and cclinetools from march 2013

thanks

rich

Attachments (2)

log.log (436.5 KB) - added by mrkapqa 7 years ago.
config.log (111.5 KB) - added by mrkapqa 7 years ago.

Download all attachments as: .zip

Change History (9)

Changed 7 years ago by mrkapqa

Attachment: log.log added

comment:1 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Keywords: mpv cocoa removed

Could you please attach the config.log file?

Changed 7 years ago by mrkapqa

Attachment: config.log added

comment:2 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: mrkapqa ryandesign added
Owner: set to Ionic
Status: newassigned
Summary: Failed to configure mpv: configure failure: command execution failedmpv @0.26.0: You manually enabled the feature 'cocoa', but the autodetection check failed

Ok, from the config.log, the reason why this configure check failed is:

../test.m:12:41: error: expected method to read array element not found on object of type 'NSArray *'
        NSLog(@"test subscripting: %@", ary[0]);
                                        ^

We may need to enforce the use of the 10.8 SDK on 10.7 to fix this. I can test this later.

For good measure, please update to OS X 10.7.5 with all security updates, and update to Command Line Tools (OS X Lion) for Xcode - April 2013.

Has duplicate #54597.

comment:3 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: assignedclosed

In dd1798d2db713194e2c483c0d76267282e9e966a/macports-ports:

mpv: Use 10.8 SDK on 10.7

Fixes build failure on Lion.

Closes: #55404

comment:4 Changed 7 years ago by Ionic (Mihai Moldovan)

Are you positive that this is a good idea?

Compiling against a newer SDK version might work for the build itself, but the resulting binaries may not work correctly or at all on an older platform?

Besides, libarclite from the 10.7 SDK should provide subscripting on OS X 10.7 (for x86_64 only).

comment:5 in reply to:  4 ; Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to Ionic:

Are you positive that this is a good idea?

Compiling against a newer SDK version might work for the build itself, but the resulting binaries may not work correctly or at all on an older platform?

That's not accurate. Using the latest available SDK is the current best practice recommended by Apple, as evidenced by the fact that for the past several years the last version of Xcode for a particular version of macOS doesn't even contain an SDK version that matches that OS. For example, Xcode 7 is compatible with OS X 10.10 but only contains the 10.11 SDK.

We do this in other ports as well. In the mongodb port we force the use of the 10.8 SDK on 10.7. In the libsdl2 port we force the use of the 10.7 SDK on 10.6.

Using a newer SDK has no effect on what versions of macOS the resulting binary can run on. That's controlled separately, by the MACOSX_DEPLOYMENT_TARGET environment variable which MacPorts sets for you.

Besides, libarclite from the 10.7 SDK should provide subscripting on OS X 10.7 (for x86_64 only).

I have no information on this topic.

comment:6 in reply to:  5 Changed 7 years ago by Ionic (Mihai Moldovan)

Replying to ryandesign:

That's not accurate. Using the latest available SDK is the current best practice recommended by Apple, as evidenced by the fact that for the past several years the last version of Xcode for a particular version of macOS doesn't even contain an SDK version that matches that OS. For example, Xcode 7 is compatible with OS X 10.10 but only contains the 10.11 SDK.

I always wondered why Apple does that, but I assumed it is for easier migration to new OS X versions (i.e., so, that developers can build new versions of their software using the current stable or oldstable OS X versions without having to upgrade to a beta first.)

I never thought such should be actually used on older versions than the SDK target version.

Xcode and SDKs are a never-ending world of pain anyway. 7.3 for instance only works on 10.11 and up, so 10.10 is stuck on 7.2. Previously, Apple released a new major Xcode version with each new OS release, but that watered down at some point.

I guess it's fine if it works, but I have no idea if the resulting binaries actually run. Guess we'll have to wait and see.

I have no information on this topic.

That's what I figured out when I still had access to a 10.7 machine. That was quite some time ago and I since lost access to this machine, so I don't have a way to recheck.

That'salso why I wonder why it failed on 10.7 x86_64 in the first place, but maybe my memory is fuzzy.

Anyway, thanks for coming up with that in any case!

comment:7 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)

Suppose Apple introduces a new feature in macOS. For example, in Sierra they introduced automatic window tabbing. An app may wish to do something with that feature if it is available. For example, the web browser QupZilla implements its own tab system, so it wants to opt out of automatic window tabbing if running on a system with that feature.

The way Apple wants you to do that is to test whether an object responds to a particular selector, and if so, then you know that the new OS feature is available and you can run the code that requires it. For example, if NSWindow responds to the allowsAutomaticWindowTabbing selector, that tells you that NSWindow has an allowsAutomaticWindowTabbing property that you can set. But a selector is a runtime check. At compile time, the compiler still has to be able to understand all the code inside that conditional block, and if you're using an old SDK created before automatic window tabbing was invented, then the NSWindow object described in the SDK won't have an allowsAutomaticWindowTabbing property and the build will fail. So you need to use a newer SDK (or use #ifdefs to hide the new code when compiling on older SDKs, as QupZilla did.)

libsdl2 had already been coded to produce a working binary for 10.6 if compiled with the 10.7 or later SDK (and MACOSX_DEPLOYMENT_TARGET=10.6 of course). Mojca did an extensive analysis of all the reasons why libsdl2 needed the 10.7 SDK.

In the case of mpv it's not a new selector they're using but some other new behavior that is apparently coupled with the 10.8 SDK. I don't claim to understand it all, I can only say that I confirmed the build failure on 10.7 when using the system SDK, and the build failure was resolved by using the 10.8 SDK.

Note: See TracTickets for help on using tickets.