I need to run a set of tests against the same ruby version and same gemset but with different versions of a .so library.
Therefor I need to have two ruby installations (for the same version 1.8.7), each one pointing to a different set of .so files. How can I do that?
Gemset usage is already too late because library binding is done when rvm install installs a ruby version.
Thanks Rishav, I got the answer through twitter from god himself (aka rvm creator), I can download the real version and the version tagged 1_8_7 on the repository.
Its a hack and will work fine with up to 4~5 different configurations (using tag, revision number, revision date and so on)
Problema solved
Related
tldr: Ruby is reporting an illegal instruction when I try to update my pod, maybe because I’m using two different versions of it.
I am not sure what my problem is, and I’ll happily add more information should it be helpful.
I got a new M1 Pro Mac and have been trying to get an XCode project (an iOS app) to work on it. It happily builds for my phone but fails to build for simulators. Based on this answer, I tried to update cocoapods and then the pods I’m using for my project (some of the Google Firebase pods). When I run pod update, I get the following result:
Update all pods
Updating local specs repositories
/Library/Ruby/Gems/2.6.0/gems/ethon-0.15.0/lib/ethon/curls/classes.rb:36: [BUG] Illegal instruction at 0x0000000100224000
ruby 2.6.8p205 (2021-07-07 revision 67951) [universal.arm64e-darwin21]
This is then followed by several hundred lines of reporting (saved here). It also saves a diagnostic report (here). I believe that both of these are red herrings, but I wanted to include them just in case.
My guess for what’s going wrong is that the library is 2.6.0, while ruby itself is version 2.6.8. Both of these are old, and they’re also different versions. I tried to update ruby, gem, and reinstalled cocoapods, but none of these changed these version numbers. Any help getting these versions updated would be appreciated.
My apologies for such an indirect question; if I were more sure what the problem was, I probably would have solved it.
If you are on an M1 chip, uninstall the cocoapods package through gem (sudo gem uninstall cocoapods) and reinstalling it with homebrew (brew install cocoapods), this fixed my problem.
I believe the issue was that my newly updated ruby versions weren’t being copied to my homebrew path. This command (from this answer) ended up solving it!
PATH=/usr/local/opt/ruby/bin:$PATH
GEMSDIR=$(gem environment gemdir)/bin
PATH=$GEMSDIR:$PATH
export PATH
I found many questions here about installing multiple versions of Python on the same machine, but I could not find a solution to my issue. I have Python 2.7.9 already installed (in c:\python27) and I want to perform some tests with Python 2.7.6, so I have also installed this version (in c:\python276). I run c:\Python276\python.exe --version but I am still getting Python 2.7.9
It's more likely that
c:\windows\system32\python27.dll is the Python 2.7.9 version, and that's what is getting loaded by Python.exe (any 2.7.x version). I've never tried to have multiple 2.7.x versions at the same time, but since I can't find any copies of python27.dll in under c:\Python27\, my best suggestion is to completely uninstall all Python versions, then install them in ascending version order (i.e., 2.7.6, then 2.7.9), saving copies of c:\windows\system32\python27.dll at each step. To run a particular minor version, make sure the appropriate python27.dll is the first one found on your path; you may want to capture all of c:\python27\ as well, just to be sure you have consistent versions.
Is there a legacy mode for Cocoapods that allows a user to use a version of Cocoapods as if it was an older one? Eg use 1.0.0 as if it was 0.39 via a command line argument to avoid downloading legacy versions.
You will need the version to be installed. However, there is nothing wrong with having multiple versions installed. You can also delete them if you no longer need a specific version.
Once installed, run the version you want with this:
pod _0.39.0_ YourCommandHere
Change the version number as needed.
Until recently I used to have Xcode 4.2 with the osx-gcc-installer installed on top of it, which worked quite well for older versions of Ruby.
The thing is, that now that I installed Xcode 4.3 with the command line tools (for homebrew), I found that I don't have gcc-4.2 on my system.
From what I was able to find, the usual way to install pre 1.9.3 is to either get an older version of Xcode, or using the osx-gcc-installer. I also found a warning saying that if I install osx-gcc-installer over Xcode 4.3, it will cause problems with node.js.
As I'm currently doing both iOS and node.js development alongside Ruby, I can't really do any of these things. Which means I can only work with 1.9.3, which is the only Ruby version that can be compiled with LLVM.
Is there a clean way to install any older version of Ruby without sacrificing Xcode 4.3? The solution that comes to my mind is having gcc-4.2 in some kind of non-system-wide sandbox and specify it's path when installing Ruby, but I'm not really sure how to do this properly.
Update:
See this link for the process required to get GCC-4.2 onto a machine with Xcode 4.3 without overwriting other components.
Xcode 4.3, Homebrew, and Ruby
It will obviate the need for the instructions below:
RVM should work if you set the default compiler for RVM to gcc. Place this in your .bashrc or .zshrc.
export CC=/usr/bin/gcc-4.2
RVM should then use GCC to compile.
If you don't want to have CC set permanently then you could try installing with:
CC=/usr/bin/gcc-4.2 rvm install 1.8.7
I've installed Snow Leopard over Leopard with macports and rubygems already installed. This was regular install, not a clean "archive and erase" install.
It turned out, that SL has 64bit versions of shared libraries and many development utilities do not work. For example, "port" command complains on incompatible tcl library, or ruby cannot load 32bit bundles.
What is the easiest way to solve these issues?
I was googling for the answer for about 4 days already and finally came up with a step-by-step manual on fixing macports and rubygems:
http://oleganza.tumblr.com/post/127709563/snow-leopard-with-legacy-macports-and-rubygems
In short: for proper use of macports and rubygems you would have to:
Install trunk macports from source (or use 1.8 version when it is released)
Add alias for "gem install with 64bit architecture"
Reinstall all ports (not automated yet)
Reinstall all gems (100% automated)
This would take 10-20 minutes of your personal time and another 20
minutes of machine time in order to build and install stuff.
I would be glad to get more answers in order to fix other issues we might meet later.
Since it's really hard to force MacPorts to recompile all ports (in the proper order), I just did:
mv /opt /opt.old
Then install MacPorts 1.8, and bring back any configs you need from /opt.old/local/etc/
Otherwise, you'll get assorted errors complaining about your existing libs' architecture, (e.g. "Command output: ld: warning: in /opt/local/lib/libz.dylib, file is not of required architecture").
This isn't as clean as 'port uninstall installed' but works fast and good enough for me.
Richard Dooling's MacPorts On Snow Leopard explains that to fix the older install of MacPorts, which is broken after the upgrade to Snow Leopard, you should just download and install the new compatible version over the old one and then simply follow the migration instructions - which also say the same.