Closed jayshepherd closed 8 years ago
tenshiemi
commented
9 years ago I'm seeing the same issue, tried a few things that didn't work:
sudo env ARCHFLAGS="-arch i386 -arch x86_64" gem install scrypt
(in irb) gem list.each_line {|line| sudo env ARCHFLAGS="-arch x86_64" gem install #{line.split.first}}
and lots of uninstall and reinstall different versions :(
tenshiemi
commented
9 years ago I just tried following these instructions and now my rails app is working again: http://sublimecoding.com/blog/2014/10/12/scrypt-gem-native-extension-build-errors/
skull-squadron
commented
9 years ago I would not install the ancient apple gcc formula, it's riddled with security vulnerabilities, it's unmaintained. If you absolutely have to have gcc, run brew install gcc. But for scrypt, it's unnecessary. Also, you have to recompile ruby anyhow when upgrading to Yosemite or upgrading CLT's because shared libraries change (note: Ruby compiles in OpenSSL statically by default, so recompile Ruby when there's an OpenSSL vulnerability patch released.)
0 ~ git:master ❯❯❯ gem install scrypt
Fetching: ffi-1.9.6.gem (100%)
Building native extensions. This could take a while...
Successfully installed ffi-1.9.6
Fetching: ffi-compiler-0.1.3.gem (100%)
Successfully installed ffi-compiler-0.1.3
Fetching: scrypt-2.0.0.gem (100%)
Building native extensions. This could take a while...
Successfully installed scrypt-2.0.0
3 gems installed
0 ~ git:master ❯❯❯ sw_vers
ProductName: Mac OS X
ProductVersion: 10.10.1
BuildVersion: 14B25
0 ~ git:master ❯❯❯ ruby -e 'puts RUBY_VERSION'
2.2.0
0 ~ git:master ❯❯❯ which gcc-4.2
gcc-4.2 not found
1 ~ git:master ❯❯❯(And latest stable Xcode CLT.)
tenshiemi
commented
9 years ago Well I spent at least 6 hours trying different things and nothing else worked. Clean install just recently upgraded to Yosemite.
skull-squadron
commented
9 years ago gem uninstall -ax scrypt ffi-compiler ffi; gem install scryptrm -rf ~/.rvm ~/.rbenv ~/.rubies and recompile a modern Ruby, not 1.9.x. (I use chruby and ruby-install as opposed to rbenv or rvm.)I also tried ruby-1.9.3-p550, it worked fine, but I wouldn't use it for new development.
https://www.ruby-lang.org/en/news/2014/01/10/ruby-1-9-3-will-end-on-2015/
skull-squadron
commented
9 years ago @tenshiemi Grr, upgrading is a hassle. Install the latest CLT? I have Yosemite 10.10.1, Xcode 6.1.1 CLT from here. When you upgrade CLT, usually have to recompile everything 3rd-party that is compiled or depends on shared stuff, which often includes compiled Ruby and almost all gems that have native extensions (they're compiled too).
In other words: just reinstall friggin' every 3rd-party command-line package to be sure when changing CLT versions. That means rerunning all those brew install whatever, rvm install 2.2.0 and so forth commands, or else get bit by shared-library incompatibility nonsense (i.e., ABI mismatch).
If a home directory was imported or copied from an older Mac, that will often drag along old, compiled Rubies and gems in ~/.rvm, ~/.rbenv or ~/.rubies.
(Don't install gems or hardly anything with sudo, this modifies your system and can break it.)
skull-squadron
commented
9 years ago Normally, on a modern OS X laptop or desktop, it actually loads x86_64, which doesn't require anything special. System binaries include both x86_64 for new machines and i386 for older machines.
But if for some weird reason, here's how force building multi-architecture native extension gems (OS X only) :
[sudo] env ARCHFLAGS='-m32 -arch i386 -m64 -arch x86_64' gem install scrypt^-- unnecessary for built-in Ruby, which compiles multi-arch by default. So really, this should never be necessary, because library architecture issues indicates broken gems or a broken Ruby.
Don't use sudo, because problems will follow.
Testing with naughty sudo on built-in system Ruby:
0 ~ git:master ❯❯❯ gem install scrypt
Fetching: ffi-1.9.6.gem (100%)
Building native extensions. This could take a while...
Successfully installed ffi-1.9.6
Fetching: ffi-compiler-0.1.3.gem (100%)
Successfully installed ffi-compiler-0.1.3
Fetching: scrypt-2.0.0.gem (100%)
Building native extensions. This could take a while...
Successfully installed scrypt-2.0.0
3 gems installed
0 ~ git:master ❯❯❯ file /Library/Ruby/Gems/2.0.0/gems/scrypt-2.0.0/ext/scrypt/x86_64-darwin/libscrypt_ext.bundle
/Library/Ruby/Gems/2.0.0/gems/scrypt-2.0.0/ext/scrypt/x86_64-darwin/libscrypt_ext.bundle: Mach-O universal binary with 2 architectures
/Library/Ruby/Gems/2.0.0/gems/scrypt-2.0.0/ext/scrypt/x86_64-darwin/libscrypt_ext.bundle (for architecture x86_64): Mach-O 64-bit bundle x86_64
/Library/Ruby/Gems/2.0.0/gems/scrypt-2.0.0/ext/scrypt/x86_64-darwin/libscrypt_ext.bundle (for architecture i386): Mach-O bundle i386
0 ~ git:master ❯❯❯ which ruby
/usr/bin/ruby
0 ~ git:master ❯❯❯
0 ~ git:master ❯❯❯ ruby -rscrypt -e 'puts SCrypt::Password.create("my grand secret")'
400$8$29$198b2e629fe4109f$7dabf3a55966df8e82ef85d09bfad7509d9cf96d655e03793a8e6a720a36c734
0 ~ git:master ❯❯❯ sudo gem uninstall -ax scrypt ffi-compiler ffi
Password:
Successfully uninstalled scrypt-2.0.0
Successfully uninstalled ffi-compiler-0.1.3
Successfully uninstalled ffi-1.9.6
0 ~ git:master ❯❯❯@jayshepherd
This can happen when upgrading to a machine because only one architecture was compiled (i386/ppc/ppc64) but the current one needs x86_64. Removing and recreating the gemset should fix it.
If not, could you post the output of each of these?
file `which ruby`
file /Users/jshepherd/.rvm/gems/ruby-1.9.3-p547@myproject/gems/scrypt-2.0.0/ext/scrypt/x86_64-darwin/libscrypt_ext.bundle
jayshepherd
commented
9 years ago This is on a MacBook Pro (Retina, 15-inch, Mid 2014). Clean install (not an update over Mavericks) of Yosemite currently running 10.10.1 (14B25)
/Users/jshepherd/.rvm/rubies/ruby-1.9.3-p547/bin/ruby: Mach-O 64-bit executable x86_64
/Users/jshepherd/.rvm/gems/ruby-1.9.3-p547@myproject/gems/scrypt-2.0.0/ext/scrypt/x86_64-darwin/libscrypt_ext.bundle: Mach-O bundle i386@jayshepherd There's the symptom: 64-bit only ruby can't load a 32-bit bundle. It should say x86_64 on both.
This usually happens if someone copied their home directory from an older to a newer machine (i.e., Migration Assistant, rsync, Time Machine, copy from another machine, etc.).
cd path/to/myproject
rvm gemset delete myproject
rvm gemset create myproject
bundleThis was a clean Yosemite install with no copying of anything. Gemset was created from scratch and all rubies installed.
skull-squadron
commented
9 years ago Post the output of ls -la of those files if you would.
— Sent from Mailbox
On Wed, Feb 11, 2015 at 9:28 AM, Jay Shepherd notifications@github.com wrote:
This was a clean Yosemite install with no copying of anything. Gemset was created from scratch and all rubies installed.
Reply to this email directly or view it on GitHub: https://github.com/pbhogan/scrypt/issues/36#issuecomment-73924053
skull-squadron
commented
9 years ago The ruby binary and the .bundle
— Sent from Mailbox
On Wed, Feb 11, 2015 at 9:28 AM, Jay Shepherd notifications@github.com wrote:
This was a clean Yosemite install with no copying of anything. Gemset was created from scratch and all rubies installed.
Reply to this email directly or view it on GitHub: https://github.com/pbhogan/scrypt/issues/36#issuecomment-73924053
jayshepherd
commented
9 years ago @tenshiemi's solution just worked perfectly for me:
http://sublimecoding.com/blog/2014/10/12/scrypt-gem-native-extension-build-errors/
skull-squadron
commented
9 years ago That installs an ancient and unmaintained gcc that has security vulnerabilities, will break future brew formulas and doesn't solve the underlying issue.
— Sent from Mailbox
On Wed, Feb 11, 2015 at 9:34 AM, Jay Shepherd notifications@github.com wrote:
@tenshiemi's solution just worked perfectly for me:
http://sublimecoding.com/blog/2014/10/12/scrypt-gem-native-extension-build-errors/
Reply to this email directly or view it on GitHub: https://github.com/pbhogan/scrypt/issues/36#issuecomment-73925169
jayshepherd
commented
9 years ago Is this what you are requesting?
➜ bin ls -la ruby
-rwxr-xr-x 1 jshepherd staff 9024 Nov 11 20:29 ruby✗ ls -la .bundle
total 8
drwxr-xr-x 3 jshepherd staff 102 Nov 11 23:01 .
drwxr-xr-x 30 jshepherd staff 1020 Feb 11 11:36 ..
-rw-r--r-- 1 jshepherd staff 8 Nov 11 23:01 configBoth look old. I would nuke ~/.rvm and ~/.gem from orbit, unless you have some massive production environment that has to be supported, update it and rebuild Ruby 2.2.0 from source. Every time OpenSSL is updated, Ruby should be rebuilt too (because OpenSSL is statically linked in to Ruby by default.). Script it so you can rebuild your environment cleanly and repeatably, like ~/bin/reinstall_all_rubies.
I use ruby-install instead of RVM because it compiles production-grade Ruby that usually Just Works.
If you can't get it going, might just setup local dev virtualbox, vagrant, docker and just push to a Linux box if that's what you're deploying to... 12factors'-style develop on what you'd use in production. Might save some OS X vs. Linux gotchas pain.
— Sent from Mailbox
On Wed, Feb 11, 2015 at 9:45 AM, Jay Shepherd notifications@github.com wrote:
Is this what you are requesting?
➜ bin ls -la ruby -rwxr-xr-x 1 jshepherd staff 9024 Nov 11 20:29 ruby✗ ls -la .bundle total 8 drwxr-xr-x 3 jshepherd staff 102 Nov 11 23:01 . drwxr-xr-x 30 jshepherd staff 1020 Feb 11 11:36 .. -rw-r--r-- 1 jshepherd staff 8 Nov 11 23:01 config
Reply to this email directly or view it on GitHub: https://github.com/pbhogan/scrypt/issues/36#issuecomment-73927287
skull-squadron
commented
9 years ago Also, here's a hacky, pre-built libscrypt_ext.bundle that will work on both x86_64 & i386 for Ruby 1.9.3 through 2.2.0 inclusive if it's a blocker issue.
sikachu
commented
8 years ago @steakknife excuse me for commenting on this old issue.
I'm currently upgrading my client's app to Rails 4.0 and run into an issue installing scrypt on El Capitan 10.11.3 and Ruby 1.9.3. I tried the steps above to see if I could force it to compile x86_64 binary, but seems like it didn't want to.
[~] rvm use 1.9.3
Using /Users/sikachu/.rvm/gems/ruby-1.9.3-p551
[~] gem install scrypt
Fetching: ffi-1.9.10.gem (100%)
Building native extensions. This could take a while...
Successfully installed ffi-1.9.10
Fetching: ffi-compiler-0.1.3.gem (100%)
Successfully installed ffi-compiler-0.1.3
Fetching: scrypt-2.1.1.gem (100%)
Building native extensions. This could take a while...
Successfully installed scrypt-2.1.1
3 gems installed
[~] file ~/.rvm/gems/ruby-1.9.3-p551/gems/scrypt-2.1.1/ext/scrypt/x86_64-darwin/libscrypt_ext.bundle
/Users/sikachu/.rvm/gems/ruby-1.9.3-p551/gems/scrypt-2.1.1/ext/scrypt/x86_64-darwin/libscrypt_ext.bundle: Mach-O bundle i386
[~] gem uninstall -ax scrypt ffi-compiler ffi
Successfully uninstalled scrypt-2.1.1
Successfully uninstalled ffi-compiler-0.1.3
Successfully uninstalled ffi-1.9.10
[~] env ARCHFLAGS='-m32 -arch i386 -m64 -arch x86_64' gem install scrypt
Fetching: ffi-1.9.10.gem (100%)
Building native extensions. This could take a while...
Successfully installed ffi-1.9.10
Fetching: ffi-compiler-0.1.3.gem (100%)
Successfully installed ffi-compiler-0.1.3
Fetching: scrypt-2.1.1.gem (100%)
Building native extensions. This could take a while...
Successfully installed scrypt-2.1.1
3 gems installed
[~] file ~/.rvm/gems/ruby-1.9.3-p551/gems/scrypt-2.1.1/ext/scrypt/x86_64-darwin/libscrypt_ext.bundle
/Users/sikachu/.rvm/gems/ruby-1.9.3-p551/gems/scrypt-2.1.1/ext/scrypt/x86_64-darwin/libscrypt_ext.bundle: Mach-O bundle i386
[~] file `which ruby`
/Users/sikachu/.rvm/rubies/ruby-1.9.3-p551/bin/ruby: Mach-O 64-bit executable x86_64I'm thinking about trying to use your binary in your previous comment for now, but I just want to reach out first in case I'm missing something. Thank you.
skull-squadron
commented
8 years ago Ruby 1.9.3 is unsupported and insecure, don't use it... upgrade that first to the latest stable (currently 2.3.0) may solve it. Don't build universal binaries because it just causes unnecessary problems. For properly installed Ruby, no magic environment variables are needed. I only use and recommend chruby+ruby-install, use anything else at your own, unsupported peril.
0 ~ git:master ❯❯❯ file `which ruby` ✖ ✱ ◼
/usr/local/ruby/ruby-2.3.0/bin/ruby: Mach-O 64-bit executable x86_64
0 ~ git:master ❯❯❯ gem uninstall -Iax scrypt ✖ ✱ ◼
Successfully uninstalled scrypt-2.1.1
0 ~ git:master ❯❯❯ gem install scrypt ✖ ✱ ◼
Fetching: scrypt-2.1.1.gem (100%)
Building native extensions. This could take a while...
Successfully installed scrypt-2.1.1
1 gem installed
0 ~ git:master ❯❯❯ cat ~/.bundle/config ✖ ✱ ◼
---
BUNDLE_BUILD__RKERBEROS: "--with-rkerberos-dir=/usr/local/opt/krb5"
0 ~ git:master ❯❯❯ cat ~/.gemrc ✖ ✱ ◼
---
gem: --no-document
0 ~ git:master ❯❯❯ gem env ⏎ ✖ ✱ ◼
RubyGems Environment:
- RUBYGEMS VERSION: 2.6.2
- RUBY VERSION: 2.3.0 (2015-12-25 patchlevel 0) [x86_64-darwin15]
- INSTALLATION DIRECTORY: {{redacted}}/.gem/ruby/2.3.0
- USER INSTALLATION DIRECTORY: {{redacted}}/.gem/ruby/2.3.0
- RUBY EXECUTABLE: /usr/local/ruby/ruby-2.3.0/bin/ruby
- EXECUTABLE DIRECTORY: {{redacted}}/.gem/ruby/2.3.0/bin
- SPEC CACHE DIRECTORY: {{redacted}}/.gem/specs
- SYSTEM CONFIGURATION DIRECTORY: /usr/local/ruby/ruby-2.3.0/etc
- RUBYGEMS PLATFORMS:
- ruby
- x86_64-darwin-15
- GEM PATHS:
- {{redacted}}/.gem/ruby/2.3.0
- /usr/local/ruby/ruby-2.3.0/lib/ruby/gems/2.3.0
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :backtrace => false
- :bulk_threshold => 1000
- "gem" => "--no-document"
- REMOTE SOURCES:
- https://rubygems.org/
- SHELL PATH:
- {{redacted}}/.gem/ruby/2.3.0/bin
- /usr/local/ruby/ruby-2.3.0/lib/ruby/gems/2.3.0/bin
- /usr/local/ruby/ruby-2.3.0/bin
- /usr/local/bin
- /usr/local/sbin
- /usr/bin
- /bin
- /usr/local/MacGPG2/bin
- /Library/TeX/texbin
- /usr/sbin
- /sbin
- /opt/X11/bin
- {{redacted}}/bin
- {{redacted}}/perl5/bin
- /usr/local/go/bin
- {{redacted}}/.go/bin
- {{redacted}}/.node/bin
0 ~ git:master ❯❯❯@steakknife I hear you loud and clear. We just want to minimize risk on doing Rails/Ruby upgrade at the same time. I ended up just lock Authlogic to the version that doesn't require scrypt (since we're using bcrypt anyway) to mitigate the issue.
Can't wait for upgrading this project to Rails 4.2/Ruby 2.3, but it is what it is. We just have to do this step by step ...
skull-squadron
commented
8 years ago @sikachu Many shops are still running 1.8.7 (MRI/REE) in production. Maintenance/support of 10k-100k's of customer boxes and dozens-hundreds of apps... tiny differences break everything.
Consultingish work > employment. Especially built beachheads where you can advise them on staff they need to hire or engage additional roles.
brendon
commented
8 years ago @steakknife, I'm having this exact error with El Capitan. I'm using 1.9.3, and can't migrate away from it at this point though it's in the plans. This is a fresh install, brand new install of ruby, clean gemset.
Do you have any other pointers as to why bundle/gem might be compiling this wrong?
skull-squadron
commented
8 years ago Don't use RVM, it's pseudo mconvenience at the expense of stability. Follow recommendations above because your Ruby build, gem/bundler config, environment variables or something else is misconfigured. Check ~/.gemrc ~/.gem/ and ~/.bundlle/
On Wednesday, May 4, 2016, Brendon Muir notifications@github.com wrote:
@steakknife https://github.com/steakknife, I'm having this exact error with El Capitan. I'm using 1.9.3, and can't migrate away from it at this point though it's in the plans. This is a fresh install, brand new install of ruby, clean gemset.
Do you have any other pointers as to why bundle/gem might be compiling this wrong?
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/pbhogan/scrypt/issues/36#issuecomment-217070600
brendon
commented
8 years ago Thanks for that. Yea I've been feeling more and more uncomfortable about RVM lately. I don't use it in production (ruby-build instead) so I should probably make the transition.
stakach
commented
8 years ago Please re-open this issue if you have any issues with the latest release v3.0.0
brendon
commented
8 years ago Thanks @stakach, my issue was resolved by ditching RVM and using rbenv instead.
Since moving to Yosemite, I've been getting the following error with Scrypt 1.2.1 and 2.0.0. Any ideas?