Breaking Changes: Xcode 5.1 (osx)

Ohai Chefs,

We have a number of OSX users in the community (myself included) and some of you may have recently noticed issues extending Chef functionality by installing ruby gems like berkshelf, chefspec, and foodcritic which require building native extensions. Specifically, this issue crops up if you’re using omnibus or system Ruby along with newly released Xcode5.1 and its CLI tools.

You can check your version of Xcode with this command:

pkgutil --regexp --pkg-info=com.apple.pkg.XcodeMASiOSSDK*

If you see the output below, this bug may apply to you:

package-id: com.apple.pkg.XcodeMASiOSSDK71
version: 5.1.0.0.1.1393561416

Let’s look at an example of the error caused by our bug. You’ll see this error when trying to install ruby gems that require native extensions:

clang: warning: argument unused during compilation: '-L/opt/chef/embedded/lib'
linking shared-object hitimes/1.9/hitimes.bundle
clang: error: unknown argument: '-R/opt/chef/embedded/lib' [-Wunused-command-line-argument-hard-error-in-future]
clang: note: this will be a hard error (cannot be downgraded to a warning) in the future
make: *** [hitimes.bundle] Error 1

The implementation of the GCC compatibility frontend in Xcode 5.1 (clang for LLVM) introduces a breaking change. In previous versions of Xcode, clang would accept unknown command line flags with a warning. As of Xcode 5.1, passing unknown flags causes rejection with an error. Clearly, rejecting unknown flags is sane behavior and Xcode is now arguably doing the right thing. This change highlights a bug that has been generating a mostly quiet failure for far too long.

Great. But how can you get back to a working state?

There are at least two known workarounds:

  1. Remove the Xcode 5.1 Application and downgrade to Xcode 5.0.2 (you don’t have to worry about downgrading the CLI tools add-on)

  2. Continue to use Xcode 5.1 and alter the ldflags being passed to clang by setting them prior to building your gem:

    CONFIGUREARGS="--with-ldflags='-Wno-error=unused-command-line-argument-hard-error-in-future'" sudo -E /opt/chef/embedded/bin/gem install [gem name]

For example:

CONFIGUREARGS="--with-ldflags='-Wno-error=unused-command-line-argument-hard-error-in-future'" sudo -E /opt/chef/embedded/bin/gem install berkshelf

A patch for this bug has been merged into upstream source and if you build Ruby from recent source on 1.9.3, you can bypass the issue entirely. However, there is not an official Ruby release containing this patch available yet.

Which ruby to use?

As a Consultant for Chef, customers often ask me if they should manage a separate Ruby environment or use the omnibus ruby packaged with Chef for their development needs. The advice I typically give is to start by using omnibus ruby until your needs outgrow it. This tends to be sufficient for many Chef users, especially newer ones. You don’t really need Ruby to get started with Chef out of the box. When you find yourself wanting to color outside the lines, having a bit of Ruby really helps.

If you’ve used Chef’s embedded omnibus ruby, you know that upgrading your omnibus installation of Chef will blow away any of your customizations. If your ruby needs have expanded enough, it may be more appealing to manage that environment outside of Chef. Once Chef users become familiar with their ruby development needs, I then recommend looking at one of the many ways to manage them (such as chruby or rbenv). For those managing their own ruby environments, patch your ruby distributions before upgrading to Xcode 5.1.

For those using omnibus ruby, the best advice is to use one of the two workarounds listed above until we resolve that issue in a chef client release. We’ll be making changes to the way Chef Client omnibus packages are built for OSX to incorporate fixes to this issue. Our plan around addressing this in omnibus ruby can be referenced in this gist from Serdar Sutay.

George is a Partner Engineer and Evangelist with Chef. He worked in webops for over 15 years at a variety of small dotcoms and large enterprises before delving into Infrastructure as Code. He's an automation junkie that lives to help others solve problems and would love to help you solve yours. He lives in the SF Bay Area and is a sucker for good whiskey.

  • bfancher

    Thanks for the blog post. However, I tried your CONFIGURE_ARGS suggestion and that didn’t work either:

    clang: error: unknown argument: ‘-multiply_definedsuppress’ [-Wunused-command-line-argument-hard-error-in-future]

    clang: note: this will be a hard error (cannot be downgraded to a warning) in the future

    make: *** [ffi_c.bundle] Error 1

    • George Miranda

      My apologies. The original post didn’t have the CONFIGURE_ARGS line formatted with an HTML pre tag. WordPress formatted that and turned the multi-hypen into a single hyphen. Also, the path to gem wasn’t explicit. I’ve corrected those both. Thanks for finding that.

  • George Miranda

    Also, there’s this fix for using Bundler, provided by Nathan Haneysmith:

    For installing gems through bundler, the fix is to update your bundler config like this:

    cat ~/.bundle/config

    BUNDLE_BUILD__GHERKIN: –with-cflags=-Wno-error=unused-command-line-argument-hard-error-in-future –with-ldflags=-Wno-error=unused-command-line-arguement-hard-error-in-future

    BUNDLE_BUILD__NOKOGIRI: –with-cflags=-Wno-error=unused-command-line-argument-hard-error-in-future –with-ldflags=-Wno-error=unused-command-line-arguement-hard-error-in-future

    Note you will need to do this for any gem install that builds native extensions.

    For installing a single gem not through bundler sudo gem install gherkin — –with-cflags=-Wno-error=unused-command-line-argument-hard-error-in-future –with-ldflags=-Wno-error=unused-command-line-arguement-hard-error-in-future

Archives