Bug #9624: Unrecognized command-line option (CLANG/Xcode 5.1) "-multiply_definedsuppress" prevents installation of gems / ruby on OS X

• Status: Third Party's Issue
• Assignee: macos
• Target version: -
• ruby -v: ruby 2.0.0p247 (2013-06-27 revision 41674) [universal.x86_64-darwin13]
• Backport: 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: REQUIRED

[mmannerm (Mika Mannermaa)]

Currently there is a single unrecognized command-line option configure.in:L2707 that should be removed in order for the ruby/gems native extensions to compile on OS X with XCode 5.1 onwards (new CLANG version). The release went live on 11th March 2014, and broke all ruby gems with native extensions.

From Apple XCode Release Notes:

The Apple LLVM compiler in Xcode 5.1 treats unrecognized command-line options as errors. This issue has been seen when building both Python native extensions and Ruby Gems, where some invalid compiler options are currently specified.
Projects using invalid compiler options will need to be changed to remove those options. To help ease that transition, the compiler will temporarily accept an option to downgrade the error to a warning:

-Wno-error=unused-command-line-argument-hard-error-in-future

Note: This option will not be supported in the future.
To workaround this issue, set the ARCHFLAGS environment variable to downgrade the error to a warning. For example, you can install a Python native extension with:
$ ARCHFLAGS=-Wno-error=unused-command-line-argument-hard-error-in-future easy_install ExtensionName

Similarly, you can install a Ruby Gem with:

$ ARCHFLAGS=-Wno-error=unused-command-line-argument-hard-error-in-future gem install GemName 16214764 updated

[mmannerm (Mika Mannermaa)]

Adding a link to a specific commit instead of trunk to prevent further commits from changing the line number: configure.in:L2707

[luislavena (Luis Lavena)]

• Category set to build
• Status changed from Open to Assigned
• Assignee set to macos
• Priority changed from 7 to Normal

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

Applied in changeset r45339.

---

configure.in: check symbol resolution options

• configure.in (DLDFLAGS): check for each options to control
  symbol resolution. [ruby-core:61429] [Bug #9624]

[nagachika (Tomoyuki Chikanaga)]

• Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN to 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: REQUIRED

[nobu (Nobuyoshi Nakada)]

• Status changed from Closed to Feedback

I might have misread this issue.

Doesn't DLDFLAGS in rbconfig.rb start with "-Wl,"?
Then it means CLANG 5.1 is not detected as GCC.

Could you show the result of:

ruby -e 'p RbConfig::CONFIG.values_at(*%w[GCC DLDFLAGS])'

[nobu (Nobuyoshi Nakada)]

• Status changed from Feedback to Closed

Applied in changeset r45348.

---

configure.in: insert a space for non-GCC

• configure.in (DLDFLAGS): insert a space between option and its
  argument for non-GCC compilers. [ruby-core:61429] [Bug #9624]

[nobu (Nobuyoshi Nakada)]

• Status changed from Closed to Feedback

[mmannerm (Mika Mannermaa)]

Nobuyoshi Nakada wrote:

I might have misread this issue.

Doesn't DLDFLAGS in rbconfig.rb start with "-Wl,"?
Then it means CLANG 5.1 is not detected as GCC.

Could you show the result of:

ruby -e 'p RbConfig::CONFIG.values_at(*%w[GCC DLDFLAGS])'

$ ruby -e 'p RbConfig::CONFIG.values_at(*%w[GCC DLDFLAGS])'
["", "-undefineddynamic_lookup -multiply_definedsuppress"]

$ clang -v
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix

Please note that the ruby is the system ruby compiled and installed by Apple before the clang version was updated.

$ ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [universal.x86_64-darwin13]

Would I need to compile the ruby from source to verify if this issue is detecting the clang version?

[mmannerm (Mika Mannermaa)]

Mika Mannermaa wrote:

Would I need to compile the ruby from source to verify if this issue is detecting the clang version?

Downloaded the tar files for ruby-2.0.0-p451 and ran the configure script, the following line is from the generated Makefile:

DLDFLAGS = -Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress $(XLDFLAGS) $(ARCH_FLAG)

And here for 1.9.3-p545:

DLDFLAGS = -Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress -Wl,-flat_namespace $(EXTLDFLAGS) $(ARCH_FLAG)

And here for 2.1.1

DLDFLAGS = -Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress $(XLDFLAGS) $(ARCH_FLAG)

The machine is a clean install of OS X Mavericks with all updates installed.

[nobu (Nobuyoshi Nakada)]

• Status changed from Feedback to Third Party's Issue

Mika Mannermaa wrote:

Please note that the ruby is the system ruby compiled and installed by Apple before the clang version was updated.

$ ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [universal.x86_64-darwin13]

Thank you, I could confirm it, but when configured from the p247 source:

$ grep -w -e GCC -e DLDFLAGS config.status
S["DLDFLAGS"]="-Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress"
S["GCC"]="yes"

Would I need to compile the ruby from source to verify if this issue is detecting the clang version?

Seems that Apple did something wrong again.

[mmannerm (Mika Mannermaa)]

Nobuyoshi Nakada wrote:

Mika Mannermaa wrote:

Please note that the ruby is the system ruby compiled and installed by Apple before the clang version was updated.

$ ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [universal.x86_64-darwin13]

Thank you, I could confirm it, but when configured from the p247 source:

$ grep -w -e GCC -e DLDFLAGS config.status
S["DLDFLAGS"]="-Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress"
S["GCC"]="yes"

Would I need to compile the ruby from source to verify if this issue is detecting the clang version?

Seems that Apple did something wrong again.

Yup, installed rbenv and compiled ruby 2.1.1 from source.

$ ruby -e 'p RbConfig::CONFIG.values_at(*%w[GCC DLDFLAGS])'
["yes", "-Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress"]
$ ruby -v
ruby: warning: -K is specified; it is for 1.8 compatibility and may cause odd behavior
ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-darwin13.0]

So Apple has somehow managed to remove the comma in their version, so this bug should be reported to them instead of upstream, now I wonder how to do that...

[mmannerm (Mika Mannermaa)]

Mika Mannermaa wrote:

Yup, installed rbenv and compiled ruby 2.1.1 from source.

$ ruby -e 'p RbConfig::CONFIG.values_at(*%w[GCC DLDFLAGS])'
["yes", "-Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress"]
$ ruby -v
ruby: warning: -K is specified; it is for 1.8 compatibility and may cause odd behavior
ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-darwin13.0]

So Apple has somehow managed to remove the comma in their version, so this bug should be reported to them instead of upstream, now I wonder how to do that...

And just to confirm with 2.0.0-p247:

$ ruby -e 'p RbConfig::CONFIG.values_at(*%w[GCC DLDFLAGS])'
["yes", "-Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress"]
$ ruby -v
ruby: warning: -K is specified; it is for 1.8 compatibility and may cause odd behavior
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin13.1.0]

[nagachika (Tomoyuki Chikanaga)]

Then, should I backport r45339, r45340, r45348 into 2.1?
In other words, these changesets solve any problems?