http://boinc.berkeley.edu/trac/ticket/537 says
"I think whats happening is a zlib issue...zlib.h converts gzopen over to *64 calls 
when _FILE_OFFSET_BITS is 64 but cant define the prototypes unless _LARGEFILE64_SOURCE 
is also defined...incorrectly calling gzopen64."

This looks like it might be caused by an Ubuntu-specific patch to zlib (?)
  https://bugs.launchpad.net/debian/+source/zlib/+bug/402178
in particular
  https://bugs.launchpad.net/debian/+source/zlib/+bug/402178/comments/6

Actually, I have no idea what I'm talking about, please disregard comment #2 except 
for the links.  :)

Ok, I think the problem is that our zlib does *not* have the Ubuntu patch.

LARGEFILE64_SOURCE means "add extra API for 64-bit access"
FILE_OFFSET_BITS=64 means "make the normal APIs just work for 64-bit access"

zlib deals with this by adding 64-bit functions (which are exposed with LARGEFILE64 
on), and then #define gzopen gzopen64 when FILE_OFFSET_BITS=64.

Is it possible to get upstream zlib to accept that Ubuntu patch?

Actually, even more confusing: our zlib (and upstream zlib) have none of this file 
offset business.  Is this all Debian/Ubuntu patches?

Just to put everything I know on the bug...
The failing libxml line is:
  fd = gzopen(path, "rb");
So gzopen is presumably getting #define'd to gzopen64.  However, the relevant snippet 
of zlib.h is:

#if defined(_LARGEFILE64_SOURCE) || _FILE_OFFSET_BITS == 64
   ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *));
   ...
#endif

#if _FILE_OFFSET_BITS == 64
#  define gzopen gzopen64
...
#endif

So I can't see how gzopen can be getting redefined without the prototype also getting 
exposed.

I tried making a smaller test case here, based on what flag I believe we're setting:
  http://gist.github.com/333055
But fta says that builds fine.

Full failing build log here:
  https://edge.launchpad.net/~chromium-daily/+archive/ppa/+build/1561306

Probably need to set up a lucid box to diagnose it.  :(

fta diffed the zlibs.  The lucid one is actually fine.  The problem was fixed in 
karmic, which just means jaunty doesn't compile.  I suggested a workaround, but I 
don't think there's anything we can fix here.

@evan: why can't you get the fix too? if i move back to system-libs, it's fine, so the 
problem is on your side.

Oh, maybe our copy is of the bad one?  I will investigate again.

Our copy of zlib is fine (no mention of gzopen64).

I am now pretty sure the problem is just the bad system zlib on lucid, but I've been 
wrong a bunch of times now so I am not positive.  :)

There's not much i can do. Your in-source libxml expects an old zlib (1.2.3, released 
in 2005).

Debian/Ubuntu have 1.2.3.3 (also old) + a few x64 patches.

Upstream merged them in 1.2.3.4, then released .5 up to .9 and now 1.2.4 (14 Mar 
2010) with tons of changes compared to your old in-source 1.2.3: see 
http://zlib.net/ChangeLog.txt

as a desperate measure (as i get lots of complains from jaunty x64 users), i can try 
to move to in-source zlib for intrepid and jaunty :(

How does the in-source libxml depend on that older zlib?  (I still don't understand, 
sorry!)

please fix this is affects my erokar on centos

please see here for a fix:
http://code.google.com/p/erokar/issues/detail?id=1

please see here for a fix:
http://pys.me/nme

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.