Opened 3 years ago

Closed 2 years ago

#52200 closed defect (fixed)

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

Reported by: howarth.at.macports@… Owned by: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: sierra Cc: jeremyhu (Jeremy Huddleston Sequoia), gallafent, szhorvat (Szabolcs Horvát), torstenb@…, mamoll (Mark Moll), MacPorts@…, mkae (Marko Käning), RJVB (René Bertin), chutzpah (Christopher Hansen), mapsmehere@…, rickyzhang82 (Ricky Zhang), mojca (Mojca Miklavec), maehne (Torsten Maehne)
Port: qt5 qt5-qtbase qt5-mysql-plugin

Description

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.

Attachments (3)

Portfile.diff (603 bytes) - added by howarth.at.macports@… 3 years ago.
fix for xcrun deprecation in Xcode 8
patch-no-xcrun.diff (2.0 KB) - added by raimue (Rainer Müller) 3 years ago.
qt5-xcrun.patch (2.9 KB) - added by larryv (Lawrence Velázquez) 3 years ago.
patch to apply the other patch

Download all attachments as: .zip

Change History (35)

Changed 3 years ago by howarth.at.macports@…

Attachment: Portfile.diff added

fix for xcrun deprecation in Xcode 8

comment:1 Changed 3 years ago by mf2k (Frank Schima)

Cc: mcalhoun@… removed
Keywords: sierra added
Owner: changed from macports-tickets@… to mcalhoun@…

comment:2 in reply to:  description Changed 3 years ago by larryv (Lawrence Velázquez)

Cc: jeremyhu@… added

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?

comment:3 Changed 3 years ago by 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.

Last edited 3 years ago by jeremyhu (Jeremy Huddleston Sequoia) (previous) (diff)

comment:4 Changed 3 years ago by 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

Changed 3 years ago by raimue (Rainer Müller)

Attachment: patch-no-xcrun.diff added

comment:5 Changed 3 years ago by 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.

comment:6 Changed 3 years ago by 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?

comment:7 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by gallafent

Cc: william@… added

Cc Me!

comment:9 Changed 3 years ago by chris+macports@…

This also prevents the phantomjs port from building on Sierra.

comment:10 Changed 3 years ago by szhorvat (Szabolcs Horvát)

Cc: szhorvat@… added

Cc Me!

comment:11 Changed 3 years ago by larryv (Lawrence Velázquez)

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

comment:12 Changed 3 years ago by torstenb@…

Cc: torstenb@… added

Cc Me!

comment:13 Changed 3 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Summary: Xcode 8 deprecation of xcrun breaks qt5 buildXcode 8 removal of xcrun breaks qt5 build

comment:14 Changed 3 years ago by mamoll (Mark Moll)

Cc: mmoll@… added

Cc Me!

comment:15 Changed 3 years ago by larryv (Lawrence Velázquez)

Cc: MacPorts@… mk@… rjvbertin@… cphansen@… mapsmehere@… zhangchaowang@… added
Port: qt5-qtbase qt5-mysql-plugin added

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

comment:16 Changed 3 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:17 in reply to:  6 Changed 3 years ago by 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.

comment:18 Changed 3 years ago by 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)

comment:19 Changed 3 years ago by larryv (Lawrence Velázquez)

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

Changed 3 years ago by larryv (Lawrence Velázquez)

Attachment: qt5-xcrun.patch added

patch to apply the other patch

comment:20 Changed 3 years ago by 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>

comment:21 Changed 3 years ago by 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 .

comment:22 Changed 3 years ago by 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".

comment:23 Changed 3 years ago by 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).

comment:24 Changed 3 years ago by 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.

comment:25 Changed 3 years ago by mojca (Mojca Miklavec)

Cc: mojca@… added

Cc Me!

comment:26 Changed 3 years ago by 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.

comment:27 Changed 3 years ago by 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.

comment:28 Changed 3 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: newclosed

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

comment:29 in reply to:  28 Changed 3 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: closedreopened

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.

comment:30 Changed 2 years ago by mkae (Marko Käning)

What's blocking this revbump?

comment:31 Changed 2 years ago by maehne (Torsten Maehne)

Cc: maehne added

comment:32 Changed 2 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.