Dear gem: still no zlib

Ruby
1

I really really regret ever installing SnowLeopard.

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.

Hmm! Looks like Nokogiri might do that, and it’s already installed.
Let’s try that.

require ‘nokogiri’
…no suitable image found. Did find: . . ./nokogiri.bundle: mach-o,
but wrong architecture

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

Stupid SnowLeopard.

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
Installing Nokogiri - Nokogiri 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’s 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.

Newsflash: Myth that nokogiri hard to install? Not wrassled to ground.
News Addenda: Anything that requires a port install is NOT easy to
install. Installing MacPorts (a few months ago) was a nightmare.

gem tells me that I have some options:
–with-zlib-include
–without-zlib-include=${zlib-dir}/include
–with-zlib-lib
–without-zlib-lib=${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.

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?

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

2

On Thu, Jun 17, 2010 at 11:46 AM, Dave H.
[email protected] wrote:

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

3

Afternoon Dave,

On Thu, Jun 17, 2010 at 11:46 AM, Dave H.
<[email protected]

wrote:

I really really regret ever installing SnowLeopard.

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

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

4

On Jun 17, 2010, at 11:51 , Ben B. wrote:

On Thu, Jun 17, 2010 at 11:46 AM, Dave H.
[email protected] wrote:

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.

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.

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.

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.

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.

5

On Jun 17, 2010, at 12:14 , John W Higgins wrote:

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.

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

6

On Jun 17, 2010, at 12:29 , Dave H. wrote:

$ gem install nokogiri
zlib is missing. please visit Installing Nokogiri - Nokogiri for help with installing dependencies.

Reinstall zlib as +universal

$ gem install nokogiri
libxml2 is missing. please visit Installing Nokogiri - Nokogiri 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]

7

On Jun 17, 2010, at 12:18 , Dave H. wrote:

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

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
Installing Nokogiri - Nokogiri 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.

$ gem install nokogiri
libxml2 is missing. please visit
Installing Nokogiri - Nokogiri for help with
installing dependencies.

[bangs head on table]

8

On Thu, Jun 17, 2010 at 12:16 PM, Dave H.
[email protected] 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

9

On Jun 17, 2010, at 12:34 , Ben B. 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.

10

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
Migration – MacPorts 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:
Shashank Tiwari
Twitter : tshanky

11

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
Migration – MacPorts 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.

12

On Jun 17, 2010, at 9:34 PM, Ben B. wrote:

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

smtp: [email protected]
jabber: [email protected]
gpg: 533148E2

13

On Thu, Jun 17, 2010 at 12:57 PM, Dave H.
[email protected] 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.

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 :smiley:

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 :smiley:

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.:frowning:

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

14

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.

15

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

On Thu, Jun 17, 2010 at 6:00 PM, Dave H.

16

On Jun 17, 2010, at 15:17 , Ben B. 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.