Dear gem: still no zlib.
in [Ruby]
|
From: Dave Howell on 17 Jun 2010 15:33 On Jun 17, 2010, at 12:29 , Dave Howell wrote: > > $ gem install nokogiri > zlib is missing. please visit http://nokogiri.org/tutorials/installing_nokogiri.html for help with installing dependencies. > > Reinstall zlib as +universal > > $ gem install nokogiri > libxml2 is missing. please visit http://nokogiri.org/tutorials/installing_nokogiri.html for help with installing dependencies. > Oh, of course. Nokogiri is desperately trying to build a 32-bit version of itself. It can't 'find' libxml2 because I built a 64-bit only version. [bangs nokogiri on tablej]
From: Ben Bleything on 17 Jun 2010 15:34 On Thu, Jun 17, 2010 at 12:16 PM, Dave Howell <groups.2009a(a)grandfenwick.net> wrote: > Um, it's COMPLETELY SnowLeopard's fault. I *am* using the stock Ruby, > which changed from 32-bit in Leopard to 64-bit in SnowLeopard. Ah, okay. So you did an upgrade install, and are now surprised that sweeping architectural changes affected software you already had installed. > Thus rendering every single Ruby program I had non-functional, since > all my gems were 32-bit. And my PostgreSQL. And lots and lots of other > stuff. Including a bunch of system OSAXen that Apple didn't upgrade to > 64-bit. Upgrade installs aren't worth it, particularly from 10.5 -> 10.6. I know that sucks to hear, but doing a clean install *will* fix your problems. > I had to actually go back and pull my own Ruby off my backups so that > I had a 32-bit Ruby just so I could get work done. Perhaps an expedient solution, but not a very clean one. From your other post: > $ file /opt/local/lib/libz.dylib > libz.dylib: Mach-O 64-bit dynamically linked shared library x86_64 > So I have a 64-bit libz.dylib. Gem is ignoring my /opt tree. Why are you using macports for this? Every additional piece you add is making solving your problem so much more complicated. You already have a universal libz: $ file /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib: Mach-O universal binary with 3 architectures /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library stub x86_64 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib (for architecture i386): Mach-O dynamically linked shared library stub i386 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib (for architecture ppc7400): Mach-O dynamically linked shared library stub ppc Bottom line is, your environment is broken. Based on all of the screwing around you've done to fix the situation, I don't know how to recommend you clean it up other than suggesting you do a clean install... which again, I know sucks. But these things *do* work fine on Snow Leopard, using the stock ruby, without macports. You just need to start from a clean spot, which you didn't do when you did the in-place upgrade. Ben
From: Florian Gilcher on 17 Jun 2010 15:55 On Jun 17, 2010, at 9:34 PM, Ben Bleything wrote: > On Thu, Jun 17, 2010 at 12:16 PM, Dave Howell > <groups.2009a(a)grandfenwick.net> wrote: >> Um, it's COMPLETELY SnowLeopard's fault. I *am* using the stock Ruby, >> which changed from 32-bit in Leopard to 64-bit in SnowLeopard. > > Ah, okay. So you did an upgrade install, and are now surprised that > sweeping architectural changes affected software you already had > installed. > >> Thus rendering every single Ruby program I had non-functional, since >> all my gems were 32-bit. And my PostgreSQL. And lots and lots of other >> stuff. Including a bunch of system OSAXen that Apple didn't upgrade to >> 64-bit. > > Upgrade installs aren't worth it, particularly from 10.5 -> 10.6. I > know that sucks to hear, but doing a clean install *will* fix your > problems. I had no problem doing an upgrade install since 2 OS X releases. What I had to do, though: wipe macports of the disk and recompile everything with a +universal flag. Alternatively, try this: http://trac.macports.org/wiki/Migration Regards, Florian -- Florian Gilcher smtp: flo(a)andersground.net jabber: Skade(a)jabber.ccc.de gpg: 533148E2
From: Dave Howell on 17 Jun 2010 15:57 On Jun 17, 2010, at 12:34 , Ben Bleything wrote: > Upgrade installs aren't worth it, particularly from 10.5 -> 10.6. I > know that sucks to hear, but doing a clean install *will* fix your > problems. 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. >> I had to actually go back and pull my own Ruby off my backups so that >> I had a 32-bit Ruby just so I could get work done. > > Perhaps an expedient solution, but not a very clean one. That's why I've been trying to get everything moved back up to 64-bit. > From your other post: > >> $ file /opt/local/lib/libz.dylib >> libz.dylib: Mach-O 64-bit dynamically linked shared library x86_64 >> So I have a 64-bit libz.dylib. Gem is ignoring my /opt tree. > > Why are you using macports for this? Every additional piece you add is > making solving your problem so much more complicated. 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. > You already have a > universal libz: > > $ file /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib > /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib: Mach-O universal > binary with 3 architectures > But these things *do* work fine on Snow Leopard, > using the stock ruby, without macports. You just need to start from a > clean spot, which you didn't do when you did the in-place upgrade. See above. 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. I suspect zlib and libxml were dependencies of Postgres, and, of course, MacPorts would never link to the existing system libraries. Ewww. {roll eyes} 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. Note to self: when Gem says "blahblahblah is missing" it's probably lying. Missing != wrong architecture.
From: Shashank Tiwari on 17 Jun 2010 16:11 [Note: parts of this message were removed to make it a legal post.] 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. Hope this helps. For a developer, the Snow Leopard upgrade as most OS upgrades is full of mess! Thanks, Shashank ************************************************ Shashank Tiwari web: www.shanky.org | www.treasuryofideas.com | blog: http://www.oreillynet.com/pub/au/2799 Twitter : tshanky On Thu, Jun 17, 2010 at 3:34 PM, Ben Bleything <ben(a)bleything.net> wrote: > On Thu, Jun 17, 2010 at 12:16 PM, Dave Howell > <groups.2009a(a)grandfenwick.net> wrote: > > Um, it's COMPLETELY SnowLeopard's fault. I *am* using the stock Ruby, > > which changed from 32-bit in Leopard to 64-bit in SnowLeopard. > > Ah, okay. So you did an upgrade install, and are now surprised that > sweeping architectural changes affected software you already had > installed. > > > Thus rendering every single Ruby program I had non-functional, since > > all my gems were 32-bit. And my PostgreSQL. And lots and lots of other > > stuff. Including a bunch of system OSAXen that Apple didn't upgrade to > > 64-bit. > > Upgrade installs aren't worth it, particularly from 10.5 -> 10.6. I > know that sucks to hear, but doing a clean install *will* fix your > problems. > > > I had to actually go back and pull my own Ruby off my backups so that > > I had a 32-bit Ruby just so I could get work done. > > Perhaps an expedient solution, but not a very clean one. > > From your other post: > > > $ file /opt/local/lib/libz.dylib > > libz.dylib: Mach-O 64-bit dynamically linked shared library x86_64 > > So I have a 64-bit libz.dylib. Gem is ignoring my /opt tree. > > Why are you using macports for this? Every additional piece you add is > making solving your problem so much more complicated. You already have a > universal libz: > > $ file /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib > /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib: Mach-O universal > binary with 3 architectures > /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib (for architecture > x86_64): Mach-O 64-bit dynamically linked shared library stub x86_64 > /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib (for architecture > i386): Mach-O dynamically linked shared library stub i386 > /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib (for architecture > ppc7400): Mach-O dynamically linked shared library stub ppc > > Bottom line is, your environment is broken. Based on all of the screwing > around you've done to fix the situation, I don't know how to recommend > you clean it up other than suggesting you do a clean install... which > again, I know sucks. But these things *do* work fine on Snow Leopard, > using the stock ruby, without macports. You just need to start from a > clean spot, which you didn't do when you did the in-place upgrade. > > Ben > >
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Setting IRB Configurations using env variables? Next: change gem user agent |