Dear gem: still no zlib.

[Dave Howell]

I really really regret ever installing SnowLeopard.=20

I'm trying to build some HTML. I'd been using LibXML, but it's getting =
seriously anal-retentive on me, escaping stuff that I don't want escaped =
and complaining about not mixing documents. I figured I'd look for =
something that wouldn't keep interfering with me getting my work done.=20=


Hmm! Looks like Nokogiri might do that, and it's already installed. =
Let's try that.=20
...no suitable image found. Did find: . . ./nokogiri.bundle: mach-o, =
but wrong architecture=20

$*@*X&#&%&*#&*@#*$*#&

Stupid SnowLeopard.=20

Fine!

$ gem uninstall nokogiri
[But lots of things depend on this!]
Yea, I know. Delete it anyway.

$ gem install nokogiri
zlib is missing. please visit =
http://nokogiri.org/tutorials/installing_nokogiri.html for help with =
installing dependencies.

[bang head on desk]

[visit nokogiri.org]

"Because Nokogiri needs to be compiled and dynamically linked against =
both libxml2 and libxslt, it has gained a reputation for being =
complicated to install. Let=92s wrassle this little myth to the ground, =
shall we?
The following should work on both Leopard and Snow Leopard:
sudo port install libxml2 libxslt
sudo gem install nokogiri"

I'm pretty sure I already did this. . . .

$ sudo port install libxml2 libxslt
---> Computing dependencies for libxml2
---> Cleaning libxml2
---> Computing dependencies for libxslt
---> Cleaning libxslt
$ sudo gem install nokogiri
zlib is missing.=20

Newsflash: Myth that nokogiri hard to install? Not wrassled to ground.=20=

News Addenda: *Anything* that requires a port install is NOT easy to =
install. Installing MacPorts (a few months ago) was a nightmare.=20

gem tells me that I have some options:
--with-zlib-include
--without-zlib-include=3D${zlib-dir}/include
--with-zlib-lib
--without-zlib-lib=3D${zlib-dir}/lib

These absolutely mystify me. If i'm going to tell it I want it to =
install a gem WITHOUT a library, why would I tell it where the library =
is? I want to tell it to build WITH the library. THAT library. The one =
sitting RIGHT OVER THERE.=20

Well, at least I *think* it's over there. I have =
/opt/local/lib/libz.dylib -> libz.1.2.5.dylib. Is that some other =
library that does some other z-shaped thing? If not, how the heck do I =
make rubygems USE it?=20

$*@(#*$&*%)~!($ 64-bit library hell.=20

 

[Ben Bleything]

I really really regret ever installing SnowLeopard.

None of this is Snow Leopard's fault. Nokogiri works fine for me. Are
you using the stock Ruby? It doesn't look like it... and you should
be. The Ruby that ships with Snow Leopard just works.

Ben

 

[John W Higgins]

[Note: parts of this message were removed to make it a legal post.]

Afternoon Dave,

wrote:

I really really regret ever installing SnowLeopard.

Watch your tongue here Dave - you are insulting an Apple product - you have
been warned!

I found a note about building curb which had the following as part of the
fix

sudo port install zlib +universal

Potentially that will get zlib in the right spot for you.

John

 

[Dave Howell]

=20
None of this is Snow Leopard's fault. Nokogiri works fine for me. Are
you using the stock Ruby? It doesn't look like it... and you should
be. The Ruby that ships with Snow Leopard just works.

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.=20

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.=20

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.=20

I've been trying to get things migrated to 64-bit. I thought I'd finally =
gotten that taken care of, until I tried to require 'nokogiri'

See original post.=20

 

[Dave Howell]

Afternoon Dave,
=20

=20
Watch your tongue here Dave - you are insulting an Apple product - you = have
been warned!
=20
I found a note about building curb which had the following as part of = the
fix
=20
sudo port install zlib +universal
=20
Potentially that will get zlib in the right spot for you.

$ 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.

 

[Dave Howell]

=20
On Jun 17, 2010, at 12:14 , John W Higgins wrote:
=20
=20
$ file /opt/local/lib/libz.dylib
libz.dylib: Mach-O 64-bit dynamically linked shared library x86_64
=20
So I have a 64-bit libz.dylib. Gem is ignoring my /opt tree.

But what the heck, I guess it's worth a try.

. .
---> Deactivating zlib @1.2.5_0
---> Activating zlib @1.2.5_0+universal
. .

$ file /opt/local/lib/libz.dylib
/opt/local/lib/libz.dylib: Mach-O universal binary with 2 architectures
/opt/local/lib/libz.dylib (for architecture x86_64): Mach-O 64-bit =
dynamically linked shared library x86_64
/opt/local/lib/libz.dylib (for architecture i386): Mach-O =
dynamically linked shared library i386


Well, that certainly confirms that "libz.dylib" is the zlib library, =
since now mine is multi-architecture.


$ gem install nokogiri
libxml2 is missing. please visit =
http://nokogiri.org/tutorials/installing_nokogiri.html for help with =
installing dependencies.


{stunned silence}

WTF? But libxml2 is what I installed LAST time it didn't work!

$sudo port install libxml2
---> Computing dependencies for libxml2
---> Cleaning libxml2

As expected. Nothing was installed because it's as up to date as it =
gets.=20

$ gem install nokogiri
libxml2 is missing. please visit =
http://nokogiri.org/tutorials/installing_nokogiri.html for help with =
installing dependencies.

[bangs head on table]

 

[Dave Howell]

=20
$ gem install nokogiri
zlib is missing. please visit =

http://nokogiri.org/tutorials/installing_nokogiri.html for help with =
installing dependencies.

=20
Reinstall zlib as +universal
=20
$ gem install nokogiri
libxml2 is missing. please visit =

http://nokogiri.org/tutorials/installing_nokogiri.html for help with =
installing dependencies.

=20

Oh, of course.=20

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.=20

[bangs nokogiri on tablej]

 

[Ben Bleything]

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

 

[Florian Gilcher]

Ah, okay. So you did an upgrade install, and are now surprised that
sweeping architectural changes affected software you already had
installed.


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: (e-mail address removed)
jabber: (e-mail address removed)
gpg: 533148E2

 

[Dave Howell]

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.=20

=20
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.=20=

=46rom your other post:
=20
=20
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.=20=

You already have a
universal libz:
=20
$ 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.=20

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.=20

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.=20

$ 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.=20


Note to self: when Gem says "blahblahblah is missing" it's probably =
lying. Missing !=3D wrong architecture.=20=

 

[Shashank Tiwari]

[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

 

[Dave Howell]

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.
=20
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.=20

For the sake of other people who might find this thread later, though:
All of my MacPorts files were already 64-bit.=20
I was using the version of ruby installed in =
/system/library/frameworks/Ruby.framework; the one installed with Snow =
Leopard.=

 

[Shashank Tiwari]

[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?

 

[Ben Bleything]

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

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

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 tre= e.

$ mv /opt /non-opt
$ gem install nokogiri
Building native extensions. =A0This 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 architecture= s
lib/nokogiri/nokogiri.bundle (for architecture i386): =A0 Mach-O bundle i= 386
lib/nokogiri/nokogiri.bundle (for architecture x86_64): Mach-O 64-bit bun= dle x86_64

Bloody hell. Thanks, Ben, you rock.

I'm really glad that worked!

Ben

 

[Dave Howell]

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.=20

 

[Dave Howell]

=20
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...=20

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.=20