Xcode configuration woe

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Xcode configuration woe

vincent habchi-2
Folks,

I try to update QGis to 3.4.1, and stumble on that compilation error:


/opt/local/var/macports/build/_macports-ports_gis_qgis3/qgis3/work/QGIS-3_4_1/src/native/mac/qgsmacnative.mm:125:18: error: property 'effectiveAppearance' not found on object of type '__kindof NSApplication *'
  return ( NSApp.effectiveAppearance.name == NSAppearanceNameDarkAqua );
                 ^
/opt/local/var/macports/build/_macports-ports_gis_qgis3/qgis3/work/QGIS-3_4_1/src/native/mac/qgsmacnative.mm:125:46: error: use of undeclared identifier 'NSAppearanceNameDarkAqua'; did you mean 'NSAppearanceNameAqua'?
  return ( NSApp.effectiveAppearance.name == NSAppearanceNameDarkAqua );
                                             ^~~~~~~~~~~~~~~~~~~~~~~~
                                             NSAppearanceNameAqua
/System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h:56:38: note: 'NSAppearanceNameAqua' declared here
APPKIT_EXTERN NSAppearanceName const NSAppearanceNameAqua NS_AVAILABLE_MAC(10_9);
                                     ^

Alright, when I look at the file /System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h, I get:

-rw-r--r--  1 root  wheel  2699 15 Mar  2018 /System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h

Which means that file is one release behind (10.13 instead of 10.14). However

-rw-r--r--  1 root  wheel  3721 16 Oct 07:20 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h

Is correct. Question: how to make clang use that header instead of the one installed in /System? Also, did I miss something?

Thanks,
Vincent

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woe

Ryan Schmidt-24


On Nov 8, 2018, at 07:16, Vincent Habchi wrote:

> I try to update QGis to 3.4.1, and stumble on that compilation error:
>
> —
> /opt/local/var/macports/build/_macports-ports_gis_qgis3/qgis3/work/QGIS-3_4_1/src/native/mac/qgsmacnative.mm:125:18: error: property 'effectiveAppearance' not found on object of type '__kindof NSApplication *'
>  return ( NSApp.effectiveAppearance.name == NSAppearanceNameDarkAqua );
>                 ^
> /opt/local/var/macports/build/_macports-ports_gis_qgis3/qgis3/work/QGIS-3_4_1/src/native/mac/qgsmacnative.mm:125:46: error: use of undeclared identifier 'NSAppearanceNameDarkAqua'; did you mean 'NSAppearanceNameAqua'?
>  return ( NSApp.effectiveAppearance.name == NSAppearanceNameDarkAqua );
>                                             ^~~~~~~~~~~~~~~~~~~~~~~~
>                                             NSAppearanceNameAqua
> /System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h:56:38: note: 'NSAppearanceNameAqua' declared here
> APPKIT_EXTERN NSAppearanceName const NSAppearanceNameAqua NS_AVAILABLE_MAC(10_9);
>                                     ^
> —

Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.

https://developer.apple.com/documentation/appkit/nsappearancenamedarkaqua?language=objc


> Alright, when I look at the file /System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h, I get:
>
> -rw-r--r--  1 root  wheel  2699 15 Mar  2018 /System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h
>
> Which means that file is one release behind (10.13 instead of 10.14). However
>
> -rw-r--r--  1 root  wheel  3721 16 Oct 07:20 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSAppearance.h
>
> Is correct.

So you must be on macOS 10.13 with Xcode 10.


> Question: how to make clang use that header instead of the one installed in /System? Also, did I miss something?

At present, the macOS 10.14 SDK or newer must be used to compile this software.

MacPorts support for forcing the use a different SDK is not very good at the moment.

You could do something like this:


# On Darwin 17 (macOS 10.13) require Xcode 10 or newer
PortGroup           xcodeversion 1.0
minimum_xcodeversions-append {17 10}

# Require the 10.14 SDK or newer
if {[vercmp ${configure.sdk_version} 10.14] < 0} {
    configure.sdk_version   10.14
}

if {${os.platform} eq "darwin" && ${os.major} < 17} {
    depends_build
    depends_lib
    depends_run
    pre-fetch {
        ui_error "${name} @${version} requires macOS 10.13 or greater."
        return -code error "incompatible macOS version"
    }
}


Ideally, upstream would fix their code so that they don't use symbols not available in the build sdk.

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

vincent habchi-2
Ryan,

> Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.
[…]

> So you must be on macOS 10.13 with Xcode 10.

Unfortunately not :
> uname -a
Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov  3 12:30:49 PDT 2018; root:xnu-4903.231.1~11/RELEASE_X86_64 x86_64

As you can see, I even run a beta of 10.14.2.

Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/
total 43720
-rwxr-xr-x    1 root  wheel  47503104  4 Nov 09:31 AppKit
-rw-r--r--    1 root  wheel    309176 25 Jul 18:33 AppKit.tbd
drwxr-xr-x  259 root  wheel      8288 25 Jul 18:33 Headers
drwxr-xr-x    3 root  wheel        96 25 Jul 18:33 Modules
drwxr-xr-x   77 root  wheel      2464  7 Nov 22:57 Resources
drwxr-xr-x    8 root  wheel       256 21 Sep 05:59 XPCServices
drwxr-xr-x    3 root  wheel        96  7 Nov 22:57 _CodeSignature

Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/Headers/
total 1328
-rw-r--r--  1 root  wheel  301352 15 Mar  2018 AppKit.apinotes
-rw-r--r--  1 root  wheel    8613 15 Mar  2018 AppKit.h
-rw-r--r--  1 root  wheel    1920 15 Mar  2018 AppKitDefines.h
[…]

All headers here are dated 15 Mars 2018, and are obviously 10.13 versions.

I have Xcode 10.1 installed, and:

Air > xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates

Weird, no?

Vincent

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

Christopher Jones


> On 9 Nov 2018, at 7:40 pm, Vincent Habchi <[hidden email]> wrote:
>
> Ryan,
>
>> Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.
> […]
>
>> So you must be on macOS 10.13 with Xcode 10.
>
> Unfortunately not :
>> uname -a
> Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov  3 12:30:49 PDT 2018; root:xnu-4903.231.1~11/RELEASE_X86_64 x86_64
>
> As you can see, I even run a beta of 10.14.2.
>
> Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/
> total 43720
> -rwxr-xr-x    1 root  wheel  47503104  4 Nov 09:31 AppKit
> -rw-r--r--    1 root  wheel    309176 25 Jul 18:33 AppKit.tbd
> drwxr-xr-x  259 root  wheel      8288 25 Jul 18:33 Headers
> drwxr-xr-x    3 root  wheel        96 25 Jul 18:33 Modules
> drwxr-xr-x   77 root  wheel      2464  7 Nov 22:57 Resources
> drwxr-xr-x    8 root  wheel       256 21 Sep 05:59 XPCServices
> drwxr-xr-x    3 root  wheel        96  7 Nov 22:57 _CodeSignature
>
> Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/Headers/
> total 1328
> -rw-r--r--  1 root  wheel  301352 15 Mar  2018 AppKit.apinotes
> -rw-r--r--  1 root  wheel    8613 15 Mar  2018 AppKit.h
> -rw-r--r--  1 root  wheel    1920 15 Mar  2018 AppKitDefines.h
> […]
>
> All headers here are dated 15 Mars 2018, and are obviously 10.13 versions.
>
> I have Xcode 10.1 installed, and:
>
> Air > xcode-select --install
> xcode-select: error: command line tools are already installed, use "Software Update" to install updates
>
> Weird, no?

Not necessarily. You are running beta versions. Anything is possible.

Do you really need do this ? Wouldn't switching to the production version not make sense now ?

Chris
>
> Vincent
>

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

vincent habchi-2
>> Weird, no?
>
> Not necessarily. You are running beta versions. Anything is possible.
>
> Do you really need do this ? Wouldn't switching to the production version not make sense now ?

How do you mean?

V.

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

Christopher Jones


On 9 Nov 2018, at 7:57 pm, Vincent Habchi <[hidden email]> wrote:

>>> Weird, no?
>>
>> Not necessarily. You are running beta versions. Anything is possible.
>>
>> Do you really need do this ? Wouldn't switching to the production version not make sense now ?
>
> How do you mean?

Isn't it obvious ? Beta releases are more likely to have problems...

>
> V.
>

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

vincent habchi-2
Chris,

>
> Isn't it obvious ? Beta releases are more likely to have problems…

I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, the production release.
Also that doesn’t explain why the headers in /System/Library/Frameworks are one version behind…

V.

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

Christopher Jones


> On 9 Nov 2018, at 8:11 pm, Vincent Habchi <[hidden email]> wrote:
>
> Chris,
>
>>
>> Isn't it obvious ? Beta releases are more likely to have problems…
>
> I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, the production release.
> Also that doesn’t explain why the headers in /System/Library/Frameworks are one version behind…

I disagree. You are running a beta OS. Anything is possible.
>
> V.
>

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

vincent habchi-2
Chris,

> On 9 Nov 2018, at 21:12, Chris Jones <[hidden email]> wrote:
>
>> I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, the production release.
>> Also that doesn’t explain why the headers in /System/Library/Frameworks are one version behind…
>
> I disagree. You are running a beta OS. Anything is possible.

That’s a bit of a blanket statement, no? :P

Cheers,
Vincent

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

Christopher Jones


> On 9 Nov 2018, at 8:37 pm, Vincent Habchi <[hidden email]> wrote:
>
> Chris,
>
>>> On 9 Nov 2018, at 21:12, Chris Jones <[hidden email]> wrote:
>>>
>>> I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1, the production release.
>>> Also that doesn’t explain why the headers in /System/Library/Frameworks are one version behind…
>>
>> I disagree. You are running a beta OS. Anything is possible.
>
> That’s a bit of a blanket statement, no? :P

Yes. But also true. Looks to me like you are seeing weirdness in relation to the installation on your system. Could easily be related in someway to the beta OS you are running. They are labelled beta for a reason.

Chris
>
> Cheers,
> Vincent
>

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

Ryan Schmidt-24
In reply to this post by vincent habchi-2
On Nov 9, 2018, at 13:40, Vincent Habchi wrote:

>> Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.
> […]
>
>> So you must be on macOS 10.13 with Xcode 10.
>
> Unfortunately not :
>> uname -a
> Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov  3 12:30:49 PDT 2018; root:xnu-4903.231.1~11/RELEASE_X86_64 x86_64
>
> As you can see, I even run a beta of 10.14.2.
>
> Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/
> total 43720
> -rwxr-xr-x    1 root  wheel  47503104  4 Nov 09:31 AppKit
> -rw-r--r--    1 root  wheel    309176 25 Jul 18:33 AppKit.tbd
> drwxr-xr-x  259 root  wheel      8288 25 Jul 18:33 Headers
> drwxr-xr-x    3 root  wheel        96 25 Jul 18:33 Modules
> drwxr-xr-x   77 root  wheel      2464  7 Nov 22:57 Resources
> drwxr-xr-x    8 root  wheel       256 21 Sep 05:59 XPCServices
> drwxr-xr-x    3 root  wheel        96  7 Nov 22:57 _CodeSignature
>
> Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/Headers/
> total 1328
> -rw-r--r--  1 root  wheel  301352 15 Mar  2018 AppKit.apinotes
> -rw-r--r--  1 root  wheel    8613 15 Mar  2018 AppKit.h
> -rw-r--r--  1 root  wheel    1920 15 Mar  2018 AppKitDefines.h
> […]
>
> All headers here are dated 15 Mars 2018, and are obviously 10.13 versions.
>
> I have Xcode 10.1 installed, and:
>
> Air > xcode-select --install
> xcode-select: error: command line tools are already installed, use "Software Update" to install updates
>
> Weird, no?


Weird indeed, but I can confirm it on the Mojave buildbot worker running 10.14 (which never had the Mojave beta installed) and on my 10.14.1 system (which started out with the public betas). The system headers do not mention NSAppearanceNameDarkAqua but the headers in the 10.14 SDK do.

I don't know why Apple is doing this to us. This contradicts what we previously knew about how SDKs were meant to function. The SDKs are supposed to be the same as the system headers of a particular version. We may want to file a bug report with Apple about this. Maybe then they will fix it in a future version of Mojave.

In its current design, as I recall, MacPorts assumes that if you ask for the 10.X SDK, and you are running on 10.X, then using the SDK would be the same as using the system headers, and therefore MacPorts uses the system headers instead of the SDK.

However, 10.14 does not have the /usr/include portion of the system headers anymore. If MacPorts sees that /usr/include isn't there, then it should always supply the flags that tell it to use the SDK. If we're doing that, then you should not have seen this problem, assuming the build system uses the SDK flags correctly. Looks like this port is using using cmake, which should know how to deal with SDK flags.

Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

vincent habchi-2
Ryan,

> I don't know why Apple is doing this to us. This contradicts what we previously knew about how SDKs were meant to function. The SDKs are supposed to be the same as the system headers of a particular version. We may want to file a bug report with Apple about this. Maybe then they will fix it in a future version of Mojave.

Do you want to proceed as a member of the Apple team, or do you prefer me to do so?

> Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.

Yes, I do. I was not even aware I shouldn’t. TBH, I don’t even remember using a “hidden” installer package.
I will follow your advice and set configure.sdkroot in macports.conf

Thanks for your help, Ryan, as always!

Vincent


Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

vincent habchi-2
In reply to this post by Ryan Schmidt-24
Ryan,

> Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.

Ok, I set configure.sdkroot and it worked fine now. Should I commit it with:

if {${os.platform} eq "darwin" && ${os.major} == 18} {
        configure.sdkroot …
}

?

Thanks,
Vincent


Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

Ryan Schmidt-24
In reply to this post by vincent habchi-2
On Nov 10, 2018, at 02:53, Vincent Habchi wrote:

> Ryan,
>
>> I don't know why Apple is doing this to us. This contradicts what we previously knew about how SDKs were meant to function. The SDKs are supposed to be the same as the system headers of a particular version. We may want to file a bug report with Apple about this. Maybe then they will fix it in a future version of Mojave.
>
> Do you want to proceed as a member of the Apple team, or do you prefer me to do so?
>
>> Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.
>
> Yes, I do. I was not even aware I shouldn’t. TBH, I don’t even remember using a “hidden” installer package.

When Mojave was released, the Xcode command line tools for Mojave did not install /usr/include (unlike all previous versions). They did install an installer pkg somewhere inside /Library/Developer which you could then separately install to get /usr/include. We believed Apple did this because they wanted to phase out the use of /usr/include, and were only keeping this hidden installer pkg around for users who couldn't adapt to its removal so quickly. We assume future versions of Xcode command line tools won't provide this, so we want MacPorts to work when /usr/include isn't there.

However, on my own Mojave test machine, I now have /usr/include. I was playing around with that hidden installer pkg, but I had not intended to install it. Maybe I inadvertently installed it, or maybe a Mojave or Xcode or Xcode command line tools update caused it to be installed automatically. Maybe Apple has changed its mind about removing /usr/include in Mojave. I have not yet updated the Mojave buildbot worker past macOS 10.14.0 and Xcode 10.0, but when I do, I'll check if /usr/include appears there too.


> I will follow your advice and set configure.sdkroot in macports.conf
>
> Thanks for your help, Ryan, as always!
>
> Vincent


On Nov 10, 2018, at 14:19, Vincent Habchi wrote:

> Ryan,
>
>> Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.
>
> Ok, I set configure.sdkroot and it worked fine now. Should I commit it with:
>
> if {${os.platform} eq "darwin" && ${os.major} == 18} {
> configure.sdkroot …
> }
>
> ?


If this code only gets compiled on 10.14, then that would work. But do you think (or have you tested if) this code will compile on 10.13 or earlier without the 10.14 SDK?

\r

Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

Christopher Jones


> On 10 Nov 2018, at 11:02 pm, Ryan Schmidt <[hidden email]> wrote:
>
> On Nov 10, 2018, at 02:53, Vincent Habchi wrote:
>
>> Ryan,
>>
>>> I don't know why Apple is doing this to us. This contradicts what we previously knew about how SDKs were meant to function. The SDKs are supposed to be the same as the system headers of a particular version. We may want to file a bug report with Apple about this. Maybe then they will fix it in a future version of Mojave.
>>
>> Do you want to proceed as a member of the Apple team, or do you prefer me to do so?
>>
>>> Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.
>>
>> Yes, I do. I was not even aware I shouldn’t. TBH, I don’t even remember using a “hidden” installer package.
>
> When Mojave was released, the Xcode command line tools for Mojave did not install /usr/include (unlike all previous versions). They did install an installer pkg somewhere inside /Library/Developer which you could then separately install to get /usr/include. We believed Apple did this because they wanted to phase out the use of /usr/include, and were only keeping this hidden installer pkg around for users who couldn't adapt to its removal so quickly. We assume future versions of Xcode command line tools won't provide this, so we want MacPorts to work when /usr/include isn't there.
>
> However, on my own Mojave test machine, I now have /usr/include. I was playing around with that hidden installer pkg, but I had not intended to install it. Maybe I inadvertently installed it, or maybe a Mojave or Xcode or Xcode command line tools update caused it to be installed automatically. Maybe Apple has changed its mind about removing /usr/include in Mojave. I have not yet updated the Mojave buildbot worker past macOS 10.14.0 and Xcode 10.0, but when I do, I'll check if /usr/include appears there too.
I install 10.14 in a VM yesterday, to get a clean environment to run some tests.

I did this by copying and upgrade my 10.13 VM. It is now running Xcode 10.1, and I don’t have /usr/include in it

cheers Chris

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Xcode configuration woes

Ryan Schmidt-24
On Nov 11, 2018, at 05:15, Christopher Jones wrote:

> On 10 Nov 2018, at 11:02 pm, Ryan Schmidt wrote:
>
>> On Nov 10, 2018, at 02:53, Vincent Habchi wrote:
>>
>>> Ryan,
>>>
>>>> I don't know why Apple is doing this to us. This contradicts what we previously knew about how SDKs were meant to function. The SDKs are supposed to be the same as the system headers of a particular version. We may want to file a bug report with Apple about this. Maybe then they will fix it in a future version of Mojave.
>>>
>>> Do you want to proceed as a member of the Apple team, or do you prefer me to do so?
>>>
>>>> Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.
>>>
>>> Yes, I do. I was not even aware I shouldn’t. TBH, I don’t even remember using a “hidden” installer package.
>>
>> When Mojave was released, the Xcode command line tools for Mojave did not install /usr/include (unlike all previous versions). They did install an installer pkg somewhere inside /Library/Developer which you could then separately install to get /usr/include. We believed Apple did this because they wanted to phase out the use of /usr/include, and were only keeping this hidden installer pkg around for users who couldn't adapt to its removal so quickly. We assume future versions of Xcode command line tools won't provide this, so we want MacPorts to work when /usr/include isn't there.
>>
>> However, on my own Mojave test machine, I now have /usr/include. I was playing around with that hidden installer pkg, but I had not intended to install it. Maybe I inadvertently installed it, or maybe a Mojave or Xcode or Xcode command line tools update caused it to be installed automatically. Maybe Apple has changed its mind about removing /usr/include in Mojave. I have not yet updated the Mojave buildbot worker past macOS 10.14.0 and Xcode 10.0, but when I do, I'll check if /usr/include appears there too.
>
> I install 10.14 in a VM yesterday, to get a clean environment to run some tests.
>
> I did this by copying and upgrade my 10.13 VM. It is now running Xcode 10.1, and I don’t have /usr/include in it

I've updated the buildbot machine, and it also still doesn't have /usr/include. But I also haven't installed the command line tools there. Maybe if I did that, /usr/include would now show up.