Hi Francesc,
On 5/22/2010 5:52 AM, Francesc Alted wrote:
> Hi Christoph,
>
> 2010/5/21 Christoph Gohlke <cgoh...@uci.edu <mailto:cgoh...@uci.edu>>
>
> Dear PyTables developers,
>
> I ran into two problems with 64-bit tables-2.2rc1.win-amd64-py2.6.
> Pytables and all its dependencies were built from sources using Visual
> Studio 2008. There were no build errors. Part of the test_all.py output
> is attached.
>
> 1) Even though the bzip2 and lzo libraries are present and apparently
> linked to the pyd extensions, filters.py claims that those compression
> methods are not available.
>
>
> There could be a couple of reasons for this:
>
> 1.- Python 64-bit on Win64 does not assert os.name <http://os.name> ==
> 'nt'. In case os.name <http://os.name> is different than 'nt', you may
> want to update the line 283 in setup.py:
os.name == 'nt' is True on 32 and 64-bit Python for Windows (except when
run on cygwin)
>
> 2.- In order to load DLLs, PyTables uses a the `LoadLibrary` function to
> check whether the DLL is available or not (see `getLibrary` function in
> src/utils.c for details). Perhaps `LoadLibrary` Win call does not work
> the same in Python 64/Win 64?
Thanks for the hint. Turns out that the 64 bit DLL name is "libbz2" on
my system, while utilsExtension.pyx hard-codes the name "bzip2". Also,
while "import tables._comp_lzo" succeeds, LoadLibrary("lzo2") does not
because the Python\Lib\site-packages\tables directory, where I place the
DLLs, is not in the system path. Easy to fix...
>
> 2) Many (all?) hdf5 file write operations fail during the tests. Dozens
> of h5 files are created in the %TEMP% directory before the python
> process would eventually crash in hdf5dll.dll.
>
> For comparison, the 32-bit version, tables-2.2rc1.win32-py2.6, built
> from exactly the same sources, passes all tests and bzip2 and lzo are
> getting used.
>
> I have tried the following without success:
>
> 1) using the official HDF5 1.8.4-patch1 libraries and DLLs
> 2) using a 64 bit pthreads patch from
> http://old.nabble.com/Pthreads-64bit-patches-td27399857.html
> 3) test the binaries on another Windows 7 computer.
>
> I read that the hdf write problem might be due to a zlib/hdf5 version
> mismatch. However, the hdf5 binaries test OK and do work with the h5py
> and netcdf4 packages.
>
>
> To say the truth, I don't know what is happening here. Could you try
> running a single example (say, `examples/table1.py`), and switch
> compression on and off? Please, could you also try with zlib, lzo and
> blosc to see if there is any difference? That could shed some light on
> what is going on.
I ran examples/table1.py with no compression, zlib, lzo, blosc, and
bzip2 just fine.
I have recompiled everything using the following version, but the tests
still fail as before. Zlib shows as version 1.2.3 (that's what Python is
using internally) event though I am now linking against 1.2.5.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
PyTables version: 2.2rc1
HDF5 version: 1.8.5-pre1
NumPy version: 2.0.0.dev8426
Numexpr version: 1.3.1 (not using Intel's VML/MKL)
Zlib version: 1.2.3
LZO version: 2.03 (Apr 30 2008)
BZIP2 version: 1.0.5 (10-Dec-2007)
Blosc version: 0.9.0 (2010-05-04)
Python version: 2.7b2 (r27b2:81019, May 9 2010, 10:33:25) [MSC
v.1500 64 bit (AMD64)]
Byte-ordering: little
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The following examples fail/crash:
array1.py
array3.py
array4.py
attributes1.py
table-tree.py
tutorial1-1.py
tutorial1-2.py
tutorial3-1.py
tutorial3-2.py
undo-redo.py
--
Christoph
------------------------------------------------------------------------------
_______________________________________________
Pytables-users mailing list
Pytables-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pytables-users
