I have a site running older versions of Ruby and Rails. It's running
Ruby 1.8.4 and Rails 1.2.2.
It's working fine, but I've set up a new desktop and now I need a
development environment for it.
I look at the latest version of Ruby and Rails and it's not
compatible, so I'm left with two choices.
1. Match the ruby and rails in production for now, while I plan for an
upgrade. The only problem here is that I can't seem to find older
releases of ruby on the ruby website, and the online documentation
doesn't seem to track anything but the latest versions anyway.
2. Upgrade production to the latest, but I'm unsure of the best
procedure to do this. Right now the current boot.rb and environment.rb
files are not even compatible so I'm assuming that I'd start there.
So, what is the recommended upgrade procedure, and where do I find
older copies of Ruby? I'm assuming that I can still find older copies
of rails by specifying the version to gem install.
To add to the good advice you already got -- I would seriously think
about creating a virtualized environment to replicate production's
ruby/rails/gems setup rather than changing your desktop system's
base install.
You might even create other VMs for the intermediate steps of the
upgrade -- no unexpected conflicts, disposable when finished.
I don't think so since 1.8.7 builds fine. My desktop is gentoo so
there are no dev packages, it's all here.
Post the error. And can this gentoo thing get an older openssl and put it where Ruby 1.8.4 can find it?
But stop screwing with your production server to try things!
That's a joke right? No way do I touch production. That's why I'm
trying to recreate production on my desktop.
Did not read closely.
I'm thinking of a new O'Reilly book. "Maintaining Rails applications
in the real world".
Yay. Ain't gonna write it! Too busy maintaining Rails apps in the real world.
Oh, and Rails 3 is secretly gonna be Merb configured to look like Rails. Joy. If too few established rails sites use it (like >100,000 users), then maybe Rails 2 will never go out of maintenance, despite my blog entry!
Post the error. And can this gentoo thing get an older openssl and put it where
Ruby 1.8.4 can find it?
I'll have to investigate. It's running openssl 0.9.8j, which is likely
too new for the older ruby.
Maybe it's just time to upgrade everything and once I figure out the
steps, do it in production.
Yay. Ain't gonna write it! Too busy maintaining Rails apps in the real world.
I Just wish all the Rails books I read mentioned how difficult this
kind of thing can be. They always make working with these new
frameworks look so attractive without mentioning that if you don't
move forward in production quickly enough then you'll find yourself
left behind.
Oh, and Rails 3 is secretly gonna be Merb configured to look like Rails. Joy. If
too few established rails sites use it (like >100,000 users), then maybe Rails 2
will never go out of maintenance, despite my blog entry!
openssl_missing.h:119: error: conflicting types for 'BN_rand_range'
/usr/include/openssl/bn.h:411: error: previous declaration of
'BN_rand_range' was here
openssl_missing.h:120: error: conflicting types for
'BN_pseudo_rand_range'
If I were on my own notebook, I would just pick one of those header files and edit it.
The point is C++ "recently" (meaning "recently" in glacial C++ time) became more restrictive around pointer types. Foo * cannot silently cast to Foo const * anymore, despite the latter is more restrictive. So one function prototype cannot match the other.
But the linker can't see these details, so if you just tweak the headers, the compiler was the last chance to catch this non-error, and if you thwart it, you will have your executables.
Or you could try the next tick of Ruby & the next tick of Rails...