qt5 fails to build with Xcode 8 (due to removal of the deprecated xcrun executable)

[howarth.at.macports@…]

The current qt5 Portfile fails to build against Xcode 8 due to its deprecation of xcrun in favor of the system copy....

Xcode not set up properly. You may need to confirm the license agreement by running /usr/bin/xcodebuild without arguments.

This can be fixed with the following change...

--- Portfile.orig	2016-09-09 16:23:31.000000000 -0400
+++ Portfile	2016-09-09 16:28:08.000000000 -0400
@@ -1026,6 +1026,10 @@
                     "s|__MACPORTS_DEPLOYMENT_TARGET__|${macosx_deployment_target}|g" \
                     ${worksrcpath}/mkspecs/${spec}/qmake.conf
             }
+           # Xcode 8 deprecates xcrun in favor of system copy
+	   reinplace \
+                    "s|find xcrun|find /usr/bin/xcrun|g" \
+                    ${worksrcpath}/configure ${worksrcpath}/mkspecs/features/mac/default_pre.prf
         }
 
         # return modified spec files to the default values

which is verified to work on Xcode 6.3 for 10.9 and Xcode 7.3 for 10.10.

[howarth.at.macports@…]

fix for xcrun deprecation in Xcode 8

[larryv (Lawrence Velázquez)]

I don’t know the contents of the files you’re patching, but does this patch just change /usr/bin/xcrun -find xcrun to /usr/bin/xcrun -find /usr/bin/xcrun? Is there a problem with using /usr/bin/xcrun directly?

[jeremyhu (Jeremy Huddleston Sequoia)]

xcrun wasn't deprecated in Xcode 8, it was removed. It was removed from within Xcode.app because it was redundant to the system-provided version.

That particular reinplace isn't optimal. You should be replacing /usr/bin/xcrun -find xcrun with /usr/bin/xcrun rather than /usr/bin/xcrun -find /usr/bin/xcrun

Also, this should be done as a patch instead of a reinplace and upstreamed to benefit others.

[howarth.at.macports@…]

The upstream fix for this is to substitute a check for xcodebuild for that of xcrun.

From 77a71c32c9d19b87f79b208929e71282e8d8b5d9 Mon Sep 17 00:00:00 2001
From: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Date: Thu, 7 Jul 2016 16:00:17 -0700
Subject: configure and mkspecs: Don't try to find xcrun with xcrun
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since Xcode 8 (beta 2) that tool is no longer available
through xcrun. We resort to xcodebuild instead.

Change-Id: If9d7b535c1cbac2caae0112b2003283aeff34fb9
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
---
 configure                            | 2 +-
 mkspecs/features/mac/default_pre.prf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index a1f0a8f..f4c7813 100755
--- a/configure
+++ b/configure
@@ -543,7 +543,7 @@ if [ "$BUILD_ON_MAC" = "yes" ]; then
         exit 2
     fi
 
-    if ! /usr/bin/xcrun -find xcrun >/dev/null 2>&1; then
+    if ! /usr/bin/xcrun -find xcodebuild >/dev/null 2>&1; then
         echo >&2
         echo "   Xcode not set up properly. You may need to confirm the license" >&2
         echo "   agreement by running /usr/bin/xcodebuild without arguments." >&2
diff --git a/mkspecs/features/mac/default_pre.prf b/mkspecs/features/mac/default_pre.prf
index 0cc8cd6..5df99d1 100644
--- a/mkspecs/features/mac/default_pre.prf
+++ b/mkspecs/features/mac/default_pre.prf
@@ -12,7 +12,7 @@ isEmpty(QMAKE_XCODE_DEVELOPER_PATH) {
         error("Xcode is not installed in $${QMAKE_XCODE_DEVELOPER_PATH}. Please use xcode-select to choose Xcode installation path.")
 
     # Make sure Xcode is set up properly
-    isEmpty($$list($$system("/usr/bin/xcrun -find xcrun 2>/dev/null"))): \
+    isEmpty($$list($$system("/usr/bin/xcrun -find xcodebuild 2>/dev/null"))): \
         error("Xcode not set up properly. You may need to confirm the license agreement by running /usr/bin/xcodebuild.")
 }
 
-- 
cgit v1.0-4-g1e03

[raimue (Rainer Müller)]

I attached the patch in compatible format (-p0). However, there are so many subports in this Portfile that I am not sure where this needs to be added to patchfiles.

[jeremyhu (Jeremy Huddleston Sequoia)]

-    isEmpty($$list($$system("/usr/bin/xcrun -find xcrun 2>/dev/null"))): \
+    isEmpty($$list($$system("/usr/bin/xcrun -find xcodebuild 2>/dev/null"))): \

That will fail if the CommandLineTools are selected via xcode-select because they don't contain xcodebuild. Does the build system actually require Xcode? Or just the CLTools?

[howarth.at.macports@…]

On fink, our qt5-base packaging assumes it does as we have both BuildDepends on...

xcode (>= 5.1.1), xcode.app (>= 5.1.1),

to insure both the CLI and Xcode.app are installed.

[gallafent]

Cc Me!

[chris+macports@…]

This also prevents the phantomjs port from building on Sierra.

[szhorvat (Szabolcs Horvát)]

Cc Me!

[larryv (Lawrence Velázquez)]

#52310 and #52352 look very similar. Do all the qt5-* ports need this fix?

[3add3287 (3add3287)]

Cc Me!

[mamoll (Mark Moll)]

Cc Me!

[larryv (Lawrence Velázquez)]

I’ve closed #52310 and #52352 as duplicates.

[larryv (Lawrence Velázquez)]

Replying to jeremyhu@…:

That will fail if the CommandLineTools are selected via xcode-select because they don't contain xcodebuild. Does the build system actually require Xcode? Or just the CLTools?

Upstream states that ​they require Xcode.

[seanfarley (Sean Farley)]

@larryv, it would seem all the qt5-* ports need this (in my limited testing; I can try more after I finish compiling the rest of my ports)

[larryv (Lawrence Velázquez)]

Can someone please apply this​ to their ports tree and test it? I don’t have Qt5 installed.

[larryv (Lawrence Velázquez)]

patch to apply the other patch

[seanfarley (Sean Farley)]

Sadly, no that doesn't work ;_;

The patch fails to apply to qt5-qtconnectivity ... but when I manually removed it for that port it still fails to build:

<snip>
./osx/osxbtcentralmanager_p.h:93:47: error: expected expression
typedef QHash<QLowEnergyHandle, CBDescriptor *> DescHash;
                                              ^
./osx/osxbtcentralmanager_p.h:132:64: error: no type or protocol named 'CBCentralManagerDelegate'
@interface QT_MANGLE_NAMESPACE(OSXBTCentralManager) : NSObject<CBCentralManagerDelegate, CBPeripheralDelegate>
                                                               ^
./osx/osxbtcentralmanager_p.h:135:5: error: unknown type name 'CBCentralManager'; did you mean 'OSXBTCentralManager'?
    CBCentralManager *manager;
    ^~~~~~~~~~~~~~~~
    OSXBTCentralManager
./osx/osxbtcentralmanager_p.h:132:32: note: 'OSXBTCentralManager' declared here
@interface QT_MANGLE_NAMESPACE(OSXBTCentralManager) : NSObject<CBCentralManagerDelegate, CBPeripheralDelegate>
                               ^
./osx/osxbtcentralmanager_p.h:167:5: error: unknown type name 'CBPeripheral'
    CBPeripheral *peripheral;
    ^
9 errors generated.
</snip>

[RJVB (René Bertin)]

First: the patch in question has to be applied to the Qt5 sources, port qt5-qtbase to be exact. Other Qt5 components build using the base libraries and tools installed by that port.

People who installed Xcode 8 after installing Qt5 can edit mkspecs/features/mac/default_pre.prf (in ${prefix}/libexec/qt5, I think) and replace xcrun -find xcrun with xcrun -find xcodebuild by hand.

The error in QtConnectivity appears to be due to another issue. I have had confirmation that the patch I proposed in a different ticket (and which does the same thing as the one attached here) allows Qt5 to build on *10.11* using Xcode 8 .

[Julian.Byrne@…]

Warning: xcrun is doing something funny. These give different results:

/usr/bin/xcrun -find xcrun # fails
/usr/bin/xcrun -find zip # succeeds

despite the fact that both xcrun and zip are on the PATH in /usr/bin/ . Some configure scripts use "/usr/bin/xcrun -find xcrun".

[RJVB (René Bertin)]

Yes, that's the exact problem. xcrun doesn't always look on the PATH, it uses its own path for toolchain elements. You'll probably find that it returns something like

> xcrun -find clang
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang

even though your shell will find clang as /usr/bin/clang .

Incidentally this is also why it's quite tricky to build Qt with a different compiler (ditto for Qt dependents that use QMake).

[jeremyhu (Jeremy Huddleston Sequoia)]

/usr/bin/clang is just a small stub that uses xcrun (which use xcselect) to find the real clang, which is /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang.

[mojca (Mojca Miklavec)]

Cc Me!

[mojca (Mojca Miklavec)]

The qt5-xcrun.patch​ helped me compile qt5-qtbase. I had to remove the patch for qt5-qtscript and I didn't try building anything else.

[RJVB (René Bertin)]

Yes - again, the patch is only for QtBase; installing QtBase installs a patched file used by the QMake build system which should allow all other ports that use QMake to configure and build.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Hopefully, this is fixed in r153389.
For the sake of completeness, here the ​upstream bug report.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mcalhoun@…:

Hopefully, this is fixed in r153389.

As noted in comment:4:ticket:52620, this changes a file (mkspecs/features/mac/default_pre.prf) that gets installed, so the port's revision must be increased.

[mkae (Marko Käning)]

What's blocking this revbump?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Sorry for the delay.
I thought that a revbump in r153389 was not needed since the port either built successfully or not at all.
Hopefully, r154312 really fixes the problem.

[chrstphrchvz (Christopher Chavez)]

In d1aaf0cbc77912f8eff8d9e5cc9e24f181dfeb16/macports-ports (master):

qt55-qtbase-docs: needs patch-xcrun.diff

Not known if also needed for qt53-qtbase-docs,
but apply anyway for consistency
Put URL to ticket in comments
See: #52200

[skip ci]