This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: test_zlib failure
Type: behavior Stage: resolved
Components: Tests Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: nadeem.vawda, python-dev, skrah
Priority: normal Keywords:

Created on 2012-01-25 18:46 by skrah, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (5)
msg151963 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2012-01-25 18:46
test_zlib currently fails on Ubuntu Lucid:

======================================================================
FAIL: test_library_version (test.test_zlib.VersionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/pydev/cpython/Lib/test/test_zlib.py", line 24, in test_library_version
    self.assertEqual(zlib.ZLIB_RUNTIME_VERSION, zlib.ZLIB_VERSION)
AssertionError: '1.2.3.3' != '1.2.5'
- 1.2.3.3
+ 1.2.5
msg151964 - (view) Author: Nadeem Vawda (nadeem.vawda) * (Python committer) Date: 2012-01-25 19:02
Do you have a self-compiled version of zlib (1.2.5) installed on this
system? It looks like this is due to a (benign) version mismatch between
zlib.h and the actual shared lib.
msg151975 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-01-25 21:25
New changeset a5f8611ce81d by Nadeem Vawda in branch 'default':
Issue #13862: Relax zlib version test to avoid spurious failures.
http://hg.python.org/cpython/rev/a5f8611ce81d
msg151976 - (view) Author: Nadeem Vawda (nadeem.vawda) * (Python committer) Date: 2012-01-25 21:26
Either way, the failure should be fixed now.
msg151981 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2012-01-25 22:41
Thanks! There was a 32-bit 1.2.5 version in /usr/local/lib and
a 64-bit 1.2.3.3 version in /lib.

gcc picks up the header from /usr/local/include, while ld is smart
enough to choose the 64-bit version. So it was a multilib issue.


While this is not the most robust setup, it's very convenient on
a dev machine, so I'm glad that this is fixed.
History
Date User Action Args
2022-04-11 14:57:26adminsetgithub: 58070
2012-01-25 22:41:31skrahsetstatus: pending -> closed

messages: + msg151981
2012-01-25 21:26:43nadeem.vawdasetstatus: open -> pending
resolution: fixed
messages: + msg151976

stage: needs patch -> resolved
2012-01-25 21:25:25python-devsetnosy: + python-dev
messages: + msg151975
2012-01-25 19:02:36nadeem.vawdasetmessages: + msg151964
2012-01-25 18:46:37skrahcreate