Prev: Setting IRB Configurations using env variables?
Next: change gem user agent
From: Dave Howell on 17 Jun 2010 18:00

On Jun 17, 2010, at 13:11 , Shashank Tiwari wrote:

> As a first step reinstall your macports for the right architecture and
> uninstall your 32 bit ports and then install all 64 bit ports. Then install
> the zlib port and then go from there. Read
> http://trac.macports.org/wiki/Migration to reinstall macports and the
> installed ports.
>
> If you built Ruby from source then after upgrading to Snow Leopard, please
> uninstall all gems and reinstall them as well, to be on the safe side. This
> is specially relevant for all gems that rely on native extensions, which are
> OS architecture dependent.

As you've hopefully read, the solution was to move the MacPorts directory so it couldn't be found by Rubygems.

For the sake of other people who might find this thread later, though:
All of my MacPorts files were already 64-bit.
I was using the version of ruby installed in /system/library/frameworks/Ruby.framework; the one installed with Snow Leopard.
From: Shashank Tiwari on 17 Jun 2010 18:07
[Note: parts of this message were removed to make it a legal post.]

do you use rvm to manage multiple versions of ruby on your machine?

On Thu, Jun 17, 2010 at 6:00 PM, Dave Howell
<groups.2009a(a)grandfenwick.net>wrote:

>
> On Jun 17, 2010, at 13:11 , Shashank Tiwari wrote:
>
> > As a first step reinstall your macports for the right architecture and
> > uninstall your 32 bit ports and then install all 64 bit ports. Then
> install
> > the zlib port and then go from there. Read
> > http://trac.macports.org/wiki/Migration to reinstall macports and the
> > installed ports.
> >
> > If you built Ruby from source then after upgrading to Snow Leopard,
> please
> > uninstall all gems and reinstall them as well, to be on the safe side.
> This
> > is specially relevant for all gems that rely on native extensions, which
> are
> > OS architecture dependent.
>
> As you've hopefully read, the solution was to move the MacPorts directory
> so it couldn't be found by Rubygems.
>
> For the sake of other people who might find this thread later, though:
> All of my MacPorts files were already 64-bit.
> I was using the version of ruby installed in
> /system/library/frameworks/Ruby.framework; the one installed with Snow
> Leopard.
>

From: Ben Bleything on 17 Jun 2010 18:17
On Thu, Jun 17, 2010 at 12:57 PM, Dave Howell
<groups.2009a(a)grandfenwick.net> wrote:
> Actually, this WAS a clean install. It took me over a month to
> get all my tools re-installed. However, not all of the installers
> correctly installed 64-bit versions. Postgres was a particular
> nightmare. Because it stuffed 32-bit libraries all over the place,
> everything that linked to it automatically degraded to 32-bit, and I
> ended up with all kinds of stuff that didn't work.

My mistake. Jumped to conclusions there.

Your experience is why I don't use installers anymore, though... I
used to build postgres from macports, then from source, but these
days I use homebrew... if you haven't heard of it, you should
check it out... it's sort of the sane macports, works with what
you've already got so the dependency situation is much, much nicer.
http://github.com/mxcl/homebrew

> Oh, I know, I know. I HATE MacPorts. I hate hate hate having to
> install something that is already on my system, but is 'too old' or
> the 'wrong version,' because I have wasted many hours chasing down
> problems from my command line using one version and XCode-developed
> apps using another.

Yeah. Homebrew :D

> In fact, it was impossible to get all this fixed without MacPorts,
> because that was the only way I could get a 64-bit version of
> Postgres. The packaged binary installer gave me 32-bit. I tried
> recompiling from the source version I had already, and it blew up in
> every direction with unfulfilled dependencies.

Homebrew :D

> I suspect zlib and libxml were dependencies of Postgres, and,
> of course, MacPorts would never link to the existing system
> libraries. Ewww. {roll eyes}

Macports sucks in this particular way.:(

> But that certainly suggests a possible solution. "Erase" the MacPorts tree.
>
> $ mv /opt /non-opt
> $ gem install nokogiri
> Building native extensions.  This could take a while...
> Successfully installed nokogiri-1.4.2
> 1 gem installed
> $ file .../lib/nokogiri/nokogiri.bundle
> lib/nokogiri/nokogiri.bundle: Mach-O universal binary with 2 architectures
> lib/nokogiri/nokogiri.bundle (for architecture i386):   Mach-O bundle i386
> lib/nokogiri/nokogiri.bundle (for architecture x86_64): Mach-O 64-bit bundle x86_64
>
> Bloody hell. Thanks, Ben, you rock.

I'm really glad that worked!

Ben

From: Dave Howell on 17 Jun 2010 18:36

On Jun 17, 2010, at 15:07 , Shashank Tiwari wrote:

> do you use rvm to manage multiple versions of ruby on your machine?

No. The only other version I had of ruby on my machine had specifically been renamed "ruby32" so I could make the 32-bit version run as needed. Now it's gone again, so there's only one version.


From: Dave Howell on 17 Jun 2010 18:40

On Jun 17, 2010, at 15:17 , Ben Bleything wrote:
>
> Your experience is why I don't use installers anymore, though... I
> used to build postgres from macports, then from source, but these
> days I use homebrew... if you haven't heard of it, you should
> check it out...

As a matter of fact, I have. It's not currently on my system, so I think I downloaded it to install something specific, but it didn't have that package in the repository? Something went wrong, or failed, and I trashed it. Not because I hated it, but because that would ensure I downloaded what would undoubtably be a newer version next time I needed it.



First  |  Prev  | 
Pages: 1 2 3
Prev: Setting IRB Configurations using env variables?
Next: change gem user agent