GNOME Bugzilla – Bug 773423
cerbero: Build fixes on macOS Sierra and Xcode 8
Last modified: 2016-10-27 20:04:15 UTC
I found these two were needed. Rebuilding everything from scratch to make sure nothing else is broken.
Created attachment 338351 [details] [review] osx: Fix CMake build when CFLAGS doesn't have -isysroot We now look for -isysroot in CFLAGS, CXXFLAGS and CPPFLAGS (which did have it in this case). The build was otherwise broken for taglib with macOS Sierra and Xcode 8.
Created attachment 338352 [details] [review] osx: Update min SDK version on XCode 8 With Xcode 8, building C++ code and targetting earlier than OS X 10.8 causes build failures, because older code is expected to use libstdc++ and the newly built code is built against libc++.
Comment on attachment 338352 [details] [review] osx: Update min SDK version on XCode 8 This means that if we build with old XCode we will support old OSX, otherwise not. Should we drop support for old versions? Does anybody care about old versions? 10.9 is October 2013, 10.8 July 2012.
My worry here is that we will accidentially drop 10.8 support later without noticing, so maybe should better do it intentionally here now.
Comment on attachment 338351 [details] [review] osx: Fix CMake build when CFLAGS doesn't have -isysroot I broke this by moving `-isysroot` from CFLAGS to CPPFLAGS in both darwin.config and ios.config, and I did a partial fix by reverting it in ios.config. I think a better fix is to do the same revert in darwin.config since there might be other (custom Makefile, f.ex) build systems that just read CFLAGS and ignore CPPFLAGS. I've just committed this fix to Cerbero.
FTR: commit 231ff5b54753b53743ed6135063c9bffdb8deddd Author: Nirbheek Chauhan <nirbheek@centricular.com> Date: Mon Oct 24 20:34:32 2016 +0530 darwin.config: Add -isysroot and to CFLAGS and arch_flags to CPPFLAGS Not all build systems read CPPFLAGS (some only read CFLAGS and friends) and arch cflags are sometimes needed by header checks Related to a6e18924d422d91eb076bed61baca1203591764f Partially fixes https://bugzilla.gnome.org/show_bug.cgi?id=773423
(In reply to Sebastian Dröge (slomo) from comment #4) > My worry here is that we will accidentially drop 10.8 support later without > noticing, so maybe should better do it intentionally here now. That sounds reasonable. I'll modify the commit accordingly (just change the minimum version to 10.9), finish making sure it all builds fine locally, and then push it.
Ok, go ahead
I pushed an update to change the min sdk version to 10.9.
Comment on attachment 338352 [details] [review] osx: Update min SDK version on XCode 8 I'm applying this to the 1.8 stable branch of Cerbero. Don't want to unilaterally change the min ios version in stable.
That doesn't sound ideal. Why do we explicitly need 8?
As discussed on IRC with slomo, that patch is fine to go into stable: <nirbheek> slomo, Updating that to 9 might break someone's use-case or break partial builds for them <nirbheek> slomo, I thought it would be unwise to push that as part of a minor stable update <slomo> nirbheek: yes but do we need to do that? <nirbheek> slomo, Yes, because people might build with XCode 8 now <nirbheek> So we need to cater to both people using older XCode and upgrading, and people doing new builds with XCode 8 <slomo> nirbheek: and what do we need to do for that? <nirbheek> slomo, That patch that Arun made does that With this, in the 1.8 branch, people using older XCode will use min version 10.8 and people using XCode 8 will use min version 10.9.
Comment on attachment 338352 [details] [review] osx: Update min SDK version on XCode 8 Committed to the 1.8 branch