Project

General

Profile

Actions

Bug #9624

closed

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

Added by mmannerm (Mika Mannermaa) about 10 years ago. Updated over 9 years ago.

Status:
Third Party's Issue
Assignee:
Target version:
-
ruby -v:
ruby 2.0.0p247 (2013-06-27 revision 41674) [universal.x86_64-darwin13]
[ruby-core:61429]

Description

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

Updated by mmannerm (Mika Mannermaa) about 10 years ago

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

Updated by luislavena (Luis Lavena) about 10 years ago

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

Updated by nobu (Nobuyoshi Nakada) about 10 years ago

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

Applied in changeset r45339.


configure.in: check symbol resolution options

Updated by nagachika (Tomoyuki Chikanaga) about 10 years ago

  • 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

Updated by nobu (Nobuyoshi Nakada) about 10 years ago

  • 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])'

Updated by nobu (Nobuyoshi Nakada) about 10 years ago

  • 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]

Updated by nobu (Nobuyoshi Nakada) about 10 years ago

  • Status changed from Closed to Feedback

Updated by mmannerm (Mika Mannermaa) about 10 years ago

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?

Updated by mmannerm (Mika Mannermaa) about 10 years ago

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.

Updated by nobu (Nobuyoshi Nakada) about 10 years ago

  • 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.

Updated by mmannerm (Mika Mannermaa) about 10 years ago

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...

Updated by mmannerm (Mika Mannermaa) about 10 years ago

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]

Updated by nagachika (Tomoyuki Chikanaga) over 9 years ago

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

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0