You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm getting this error message when trying to get the atomic gem -- looks like it might be a problem with GCC (which was part of the last pull request). Any ideas how to fix this?
checking for libkern/OSAtomic.h... yes
creating Makefile
make "DESTDIR="
compiling atomic_reference.c
atomic_reference.c:57:59: warning: incompatible pointer types passing 'void *' to parameter of type 'volatile int64_t *' (aka 'volatile long long *') [-Wincompatible-pointer-types]
if (OSAtomicCompareAndSwap64(expect_value, new_value, &DATA_PTR(self))) {
^~~~~~~~~~~~~~~
/usr/include/libkern/OSAtomic.h:507:93: note: passing argument to parameter '__theValue' here
bool OSAtomicCompareAndSwap64( int64_t __oldValue, int64_t __newValue, volatile int64_t *__theValue );
^
1 warning generated.
linking shared-object atomic_reference.bundle
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: ** [atomic_reference.bundle] Error 1
When you run bundle install bundler is using your system ruby to create the makefile for atomic, which is most likely very old. I use rbenv to manage my rubies, so the following corrected the issue for me:
# ensure correct ruby is set
$ rbenv global 2.1.1
$ gem install bundler
$ rbenv rehash
$ bundle install
Now bunder uses the correct gem binary, which doesn't pass unknown arguments to clang.
Here's a comparison of the output from gem env. The first using the system ruby, which yielded the error, and the second with Ruby 2.1.1, which works fine for me. Using bundler and gem install.
Also, using the system ruby, the error was originating from: /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/universal-darwin13/rbconfig.rb
Removing the references to the clang flag multiply_definedsuppress on lines 82 and 125 fixed the issue as well.
No, it might not be very old, but ruby 2.0.x does use deprecated flags.
+1 for the solution by @richardcalahan. Odd though when I use bundler, it uses system Ruby to compile vs the one I compiled in ~/.rubies. I'm using chruby.
Activity
chdiza commentedon Mar 18, 2014
I get this too; it's the fault of the latest clang that comes with Xcode 5.1.
But I have no idea what to do about it.
headius commentedon Mar 18, 2014
I have an xcode 5.1 update in process...will try to reproduce on my end once that happens.
slanand commentedon Mar 18, 2014
Thank you!
Iteratix commentedon Mar 20, 2014
+1 for this, unable to build on latest Mavericks with latest Xcode.
richardcalahan commentedon Mar 20, 2014
This is a red flag:
When you run
bundle installbundler is using your system ruby to create the makefile for atomic, which is most likely very old. I use rbenv to manage my rubies, so the following corrected the issue for me:Now bunder uses the correct gem binary, which doesn't pass unknown arguments to clang.
chdiza commentedon Mar 20, 2014
@richardcalahan I didn't run
bundle install(it wasgem install), and the system ruby on OSX 10.9.2 is not "very old" (2.0.0).Also, I got this error wtih system ruby and with 2.1.
richardcalahan commentedon Mar 20, 2014
Here's a comparison of the output from
gem env. The first using the system ruby, which yielded the error, and the second with Ruby 2.1.1, which works fine for me. Using bundler and gem install.Clang Error
No Clang Error
richardcalahan commentedon Mar 20, 2014
Also, using the system ruby, the error was originating from: /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/universal-darwin13/rbconfig.rb
Removing the references to the clang flag
multiply_definedsuppresson lines 82 and 125 fixed the issue as well.No, it might not be very old, but ruby 2.0.x does use deprecated flags.
dpehrson commentedon Mar 21, 2014
The solution offered by @richardcalahan is the only one that actually worked for me.
Iteratix commentedon Mar 26, 2014
+1 for the solution by @richardcalahan. Odd though when I use bundler, it uses system Ruby to compile vs the one I compiled in ~/.rubies. I'm using chruby.