I am using Anaconda on Ubuntu x64. When I run a simple python program, I get this error message and a [python] kernel dump. I have seen other questions with similar problems, but all the answers I see don't resolve my issue. I have tried removing and reinstalling h5py with both pip and conda, but I get the same error:
idf#DellInsp:~/Documents/Projects/python3$ python3 testtables.py
With this code inside testtables.py
import tables
tables.test()
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
PyTables version: 3.2.2
HDF5 version: 1.8.11
NumPy version: 1.10.1
Numexpr version: 2.4.4 (not using Intel's VML/MKL)
Zlib version: 1.2.8 (in Python interpreter)
Blosc version: 1.4.4 (2015-05-05)
Blosc compressors: blosclz (1.0.2.1), lz4 (1.2.0), lz4hc (1.2.0), snappy (1.1.1), zlib (1.2.8)
Cython version: 0.23.4
Python version: 3.5.0 |Anaconda 2.4.0 (64-bit)| (default, Oct 19 2015, 21:57:25)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]
Platform: Linux-3.19.0-39-lowlatency-x86_64-with-debian-jessie-sid
Byte-ordering: little
Detected cores: 4
Default encoding: utf-8
Default FS encoding: utf-8
Default locale: (en_US, UTF-8)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Performing only a light (yet comprehensive) subset of the test suite.
If you want a more complete test, try passing the --heavy flag to this script
(or set the 'heavy' parameter in case you are using tables.test() call).
The whole suite will take more than 4 hours to complete on a relatively
modern CPU and around 512 MB of main memory.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
/home/idf/anaconda3/lib/python3.5/site-packages/tables/filters.py:292: FiltersWarning: compression library ``bzip2`` is not available; using ``zlib`` instead
% (complib, default_complib), FiltersWarning)
/home/idf/anaconda3/lib/python3.5/site-packages/tables/filters.py:292: FiltersWarning: compression library ``lzo`` is not available; using ``zlib`` instead
% (complib, default_complib), FiltersWarning)
/home/idf/anaconda3/lib/python3.5/site-packages/tables/atom.py:570: DeprecationWarning: inspect.getargspec() is deprecated, use inspect.signature() instead
for arg in inspect.getargspec(self.__init__)[0]
Warning! ***HDF5 library version mismatched error***
The HDF5 header files used to compile this application do not match
the version used by the HDF5 library to which this application is linked.
Data corruption or segmentation faults may occur if the application continues.
This can happen when an application was compiled by one version of HDF5 but
linked with a different version of static or shared HDF5 library.
You should recompile the application or check your shared library related
settings such as 'LD_LIBRARY_PATH'.
You can, at your own risk, disable this warning by setting the environment
variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'.
Setting it to 2 or higher will suppress the warning messages totally.
Headers are 1.8.11, library is 1.8.15
SUMMARY OF THE HDF5 CONFIGURATION
=================================
General Information:
-------------------
HDF5 Version: 1.8.15-patch1
Configured on: Wed Oct 14 16:46:37 CDT 2015
Configured by: ilan#centos5x64.corp.continuum.io
Configure mode: production
Host system: x86_64-unknown-linux-gnu
Uname information: Linux centos5x64.corp.continuum.io 2.6.18-400.1.1.el5 #1 SMP Thu Dec 18 00:59:53 EST 2014 x86_64 x86_64 x86_64 GNU/Linux
Byte sex: little-endian
Libraries: shared
Installation point: /home/ilan/minonda/envs/_build
Compiling Options:
------------------
Compilation Mode: production
C Compiler: /usr/bin/gcc ( gcc (GCC) 4.1.2 20080704 )
CFLAGS:
H5_CFLAGS: -std=c99 -pedantic -Wall -Wextra -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -Wno-long-long -Wfloat-equal -Wmissing-format-attribute -Wmissing-noreturn -Wpacked -Wdisabled-optimization -Wformat=2 -Wunreachable-code -Wendif-labels -Wdeclaration-after-statement -Wold-style-definition -Winvalid-pch -Wvariadic-macros -Wnonnull -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -Wunused-macros -Wunsafe-loop-optimizations -Wc++-compat -Wvolatile-register-var -O3 -fomit-frame-pointer -finline-functions
AM_CFLAGS:
CPPFLAGS:
H5_CPPFLAGS: -D_DEFAULT_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -D_POSIX_C_SOURCE=200112L -DNDEBUG -UH5_DEBUG_API
AM_CPPFLAGS: -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
Shared C Library: yes
Static C Library: no
Statically Linked Executables: no
LDFLAGS:
H5_LDFLAGS:
AM_LDFLAGS:
Extra libraries: -lrt -lz -ldl -lm
Archiver: ar
Ranlib: ranlib
Debugged Packages:
API Tracing: no
Languages:
----------
Fortran: no
C++: yes
C++ Compiler: /usr/bin/g++ ( g++ (GCC) 4.1.2 20080704 )
C++ Flags:
H5 C++ Flags:
AM C++ Flags:
Shared C++ Library: yes
Static C++ Library: no
Features:
---------
Parallel HDF5: no
High Level library: yes
Threadsafety: no
Default API Mapping: v18
With Deprecated Public Symbols: yes
I/O filters (external): deflate(zlib)
MPE: no
Direct VFD: no
dmalloc: no
Clear file buffers before write: yes
Using memory checker: no
Function Stack Tracing: no
Strict File Format Checks: no
Optimization Instrumentation: no
Bye...
Aborted (core dumped)
idf#DellInsp:~/Documents/Projects/python3$
After trying several options, an uninstall followed by re-install solved the problem:
pip uninstall h5py
pip install h5py
I removed then installed version the latest version of Anaconda. This resolved this issues.
I had this same error as well. I was trying to use the default debian package libhdf5-dev. I would encourage debi / pip to update. You have to find the proper version here: https://www.hdfgroup.org/ftp/HDF5/releases/hdf5-1.8.15-patch1/src/ and build it from source. once you have it
tar -xvf hdf5-1.8.15-patch1
cd hdf5-1.8.15-patch1
./configure --prefix=/usr/local/hdf5
make
make check
make install
make check-install
pip install h5py
Please note, this can be done with other versions of hdf5 as well. This is just the one that corresponds to the version from the pip repositories.
Related
Here's what I get when I try to install Ruby 2.2:
$ ruby-install ruby 2.2.10
# ...
>>> Compiling ruby 2.2.10 ...
CC = clang
LD = ld
LDSHARED = clang -dynamic -bundle
CFLAGS = -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement -Wshorten-64-to-32 -Wimplicit-function-declaration -Wdivision-by-zero -Wdeprecated-declarations -Wextra-tokens -pipe
XCFLAGS = -D_FORTIFY_SOURCE=2 -fstack-protector -fno-strict-overflow -fvisibility=hidden -DRUBY_EXPORT -fPIE
CPPFLAGS = -I/opt/X11/include -I/usr/local/opt/openssl#1.1/include -I/usr/local/opt/readline/include -I/usr/local/opt/libyaml/include -I/usr/local/opt/gdbm/include -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -D_DARWIN_UNLIMITED_SELECT -D_REENTRANT -I. -I.ext/include/x86_64-darwin19 -I./include -I.
DLDFLAGS = -Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress -L/usr/local/opt/openssl#1.1/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/gdbm/lib -fstack-protector -Wl,-u,_objc_msgSend -Wl,-pie -framework CoreFoundation
SOLIBS = -lgmp
Apple clang version 12.0.0 (clang-1200.0.31.1)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
translating probes probes.d
. ./vm_opts.h
file2lastrev.rb: does not seem to be under a vcs: .
make: [.revision.time] Error 1 (ignored)
./revision.h unchanged
compiling main.c
compiling dmydln.c
compiling miniinit.c
compiling miniprelude.c
compiling array.c
compiling bignum.c
compiling class.c
compiling compar.c
compiling complex.c
compiling dir.c
compiling dln_find.c
compiling encoding.c
encoding.c:825:2: error: implicit declaration of function 'rb_str_change_terminator_length' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
rb_str_change_terminator_length(obj, oldtermlen, termlen);
^
1 error generated.
make: *** [encoding.o] Error 1
!!! Compiling ruby 2.2.10 failed!
OS Version: 10.15.6
ruby-install version: 0.7.1
Any ideas on how to debug or fix this? I was previously able to install other versions of 2.2 before I upgraded my OS. I'm also able to install later versions like Ruby 2.7 with no problem
After a lot of breaking my head and realizing that the error has to do with the compilation using GCC that is native to macOS, I decided to do a test.
Because older versions of Ruby need instructions that are no longer present in updated make, it is necessary to download an older version of Command Line Tools for Xcode.
First, remove your actual version with:
sudo rm -rf /Library/Developer/CommandLineTools
Ignore the error about missing git.
Proceed to https://developer.apple.com/download/more/ and download 11.x version of Command Line Tools for Xcode.
I downloaded version 11.5 and it worked.
My return when running gcc -v
Configured with: --prefix = / Library / Developer / CommandLineTools / usr --with-gxx-include-dir = / Library / Developer / CommandLineTools / SDKs / MacOSX.sdk / usr / include / c ++ / 4.2.1
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: / Library / Developer / CommandLineTools / usr / bin
To compare, with recent Command Lines, 12.x, you'll see something like:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Apparently ignoring the compiler warning is also an option
export optflags="-Wno-error=implicit-function-declaration"
For further duscussion see Problem when installing Ruby 2.2.9 on Mac Big Sur M1
I was able to install that version on Mac 10.15.7 using rvm.
I have openssl#1.1 installed with homebrew. If you run brew info openssl what do you see? I would try brew upgrade openssl first.
Try running
export PKG_CONFIG_PATH="/usr/local/opt/openssl#1.1/lib/pkgconfig" with the info brew returns. Then try rvm install 2.2.10. If that doesn't work I would try rvm install 2.2.10 --with-openssl-dir=/usr/local/opt/openssl --with-openssl-lib=/usr/local/opt/openssl/lib --with-openssl-include=/usr/local/opt/openssl/include just make sure those paths are correct for your system.
You may also need to run
export LDFLAGS="-L/usr/local/opt/openssl#1.1/lib"
export CPPFLAGS="-I/usr/local/opt/openssl#1.1/include"
beforehand, which will be supplied by brew info.
Adding some extra options here that might help:
We need the right SSL version:
$ brew install rbenv/tap/openssl#1.0
$ rvm install 2.2.10 -C --with-openssl-dir=`brew --prefix openssl#1.0`
First, install open-ssl
brew install rbenv/tap/openssl#1.0
Then
CFLAGS="-Wno-error=implicit-function-declaration" rvm reinstall ruby-2.2.5 --with-openssl-dir='/usr/local/opt/openssl#1.0'
I recently had to install ruby-2.2.0 in Catalina 10.15.7 and was facing the same issues. But luckily managed to get my work done. Steps are as follows:
Installed openssl as a rvm package:
$ rvm pkg install openssl
Ignored compiler warnings:
$ export optflags="-Wno-error=implicit-function-declaration"
Installed required ruby version (2.2.0 in my case) while providing openssl directory parameter and ignoring rubygems:
$ rvm install 2.2.0 --with-openssl-dir=$rvm_path/usr --rubygems ignore
Consider the situation when a C++ project is built and shipped within a Centos 7 virtual machine or container. Default gcc for Centos 7 is 4.8. In order to allow developers to use modern C++, the more recent version of gcc (for example, 6.3) is installed into Centos 7 which runs as a CI server. This provides -std=c++14 support.
[builder#f7279ae9f33f build (master %)]$ /usr/bin/c++ -v 2>&1 | grep version
gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)
[builder#f7279ae9f33f build (master %)]$ /opt/rh/devtoolset-6/root/usr/bin/c++ -v 2>&1 | grep version
gcc version 6.3.1 20170216 (Red Hat 6.3.1-3) (GCC)
export CXX=/opt/rh/devtoolset-6/root/usr/bin/c++
make all -j4
...
This is short example of compilation and linkage command:
[ 78%] Building CXX object CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o
/opt/rh/devtoolset-6/root/usr/bin/c++ -Ducsdos_EXPORTS -I/home/builder/src/dos/libucsdos/./src -I/home/builder/src/dos/libucsdos/./include -I/home/builder/src/dos/libucsdos/build/schema/cpp -I/home/builder/src/dos/libucsdos/build/schema -isystem /usr/local/include -O2 -g -DNDEBUG -fPIC -frtti -pedantic -Wall -Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization -Wformat=2 -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wnoexcept -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wshadow -Wsign-conversion -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 -Wswitch-default -Wundef -Werror -Wno-unused -std=gnu++14 -o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -c /home/builder/src/dos/libucsdos/src/merge_operator_string.cpp
[ 80%] Linking CXX shared library libucsdos.so
/usr/bin/cmake3 -E cmake_link_script CMakeFiles/ucsdos.dir/link.txt --verbose=1
/opt/rh/devtoolset-6/root/usr/bin/c++ -fPIC -O2 -g -DNDEBUG -shared -Wl,-soname,libucsdos.so.0 -o libucsdos.so.0.3.23 CMakeFiles/ucsdos.dir/src/c.cpp.o CMakeFiles/ucsdos.dir/src/crdt_2p_set.cpp.o CMakeFiles/ucsdos.dir/src/crdt_pn_counter.cpp.o CMakeFiles/ucsdos.dir/src/errors.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_document.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_segment.cpp.o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -Wl,-rpath,/usr/local/lib: schema/libschema.a /usr/lib64/librocksdb.so /usr/lib64/libjemalloc.so /usr/local/lib/libgrpc++_reflection.so /usr/local/lib/libgrpc++.so /usr/local/lib/libgrpc.so -ldl -lgrpc++ /usr/lib64/libprotobuf.so -lpthread /usr/lib64/libprotobuf-lite.so
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
[builder#f7279ae9f33f build (master %)]$ ldd libucsdos.so | grep libstdc++.so.6
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2a4a054000)
It's easy to find out that /lib64/libstdc++.so.6 version is 4.8.5:
[builder#f7279ae9f33f build (master %)]$ yum whatprovides "/lib64/libstdc++.so.6"
libstdc++-4.8.5-28.el7_5.1.x86_64 : GNU Standard C++ Library
Repo : #Updates
Matched from:
Filename : /lib64/libstdc++.so.6
Is this build environment configuration valid?
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
Yes. The devtoolset-6-gcc-c++ package provides a custom version of GCC that uses a special linker script instead of a dynamic library for libstdc++.so. That means the binaries it produces do not depend on the newer libstdc++.so.6 and can be run on other CentOS machines that don't have devtoolset installed (i.e. they only have the older libstdc++ library from GCC 4.8).
Is this build environment configuration valid?
Yes. What you're seeing is completely normal, and how it's supposed to work.
The pieces of the newer C++ runtime from GCC 6.4.0 get statically linked into your binary, and at runtime it only depends on the old libstdc++.so which every CentOS system has installed.
That's the whole point of the devtoolset version of GCC.
Consider the situation when a C++ project is built and shipped within a Centos 7 virtual machine or container. Default gcc for Centos 7 is 4.8. In order to allow developers to use modern C++, the more recent version of gcc (for example, 6.3) is installed into Centos 7 which runs as a CI server. This provides -std=c++14 support.
[builder#f7279ae9f33f build (master %)]$ /usr/bin/c++ -v 2>&1 | grep version
gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)
[builder#f7279ae9f33f build (master %)]$ /opt/rh/devtoolset-6/root/usr/bin/c++ -v 2>&1 | grep version
gcc version 6.3.1 20170216 (Red Hat 6.3.1-3) (GCC)
export CXX=/opt/rh/devtoolset-6/root/usr/bin/c++
make all -j4
...
This is short example of compilation and linkage command:
[ 78%] Building CXX object CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o
/opt/rh/devtoolset-6/root/usr/bin/c++ -Ducsdos_EXPORTS -I/home/builder/src/dos/libucsdos/./src -I/home/builder/src/dos/libucsdos/./include -I/home/builder/src/dos/libucsdos/build/schema/cpp -I/home/builder/src/dos/libucsdos/build/schema -isystem /usr/local/include -O2 -g -DNDEBUG -fPIC -frtti -pedantic -Wall -Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization -Wformat=2 -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wnoexcept -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wshadow -Wsign-conversion -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 -Wswitch-default -Wundef -Werror -Wno-unused -std=gnu++14 -o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -c /home/builder/src/dos/libucsdos/src/merge_operator_string.cpp
[ 80%] Linking CXX shared library libucsdos.so
/usr/bin/cmake3 -E cmake_link_script CMakeFiles/ucsdos.dir/link.txt --verbose=1
/opt/rh/devtoolset-6/root/usr/bin/c++ -fPIC -O2 -g -DNDEBUG -shared -Wl,-soname,libucsdos.so.0 -o libucsdos.so.0.3.23 CMakeFiles/ucsdos.dir/src/c.cpp.o CMakeFiles/ucsdos.dir/src/crdt_2p_set.cpp.o CMakeFiles/ucsdos.dir/src/crdt_pn_counter.cpp.o CMakeFiles/ucsdos.dir/src/errors.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_document.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_segment.cpp.o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -Wl,-rpath,/usr/local/lib: schema/libschema.a /usr/lib64/librocksdb.so /usr/lib64/libjemalloc.so /usr/local/lib/libgrpc++_reflection.so /usr/local/lib/libgrpc++.so /usr/local/lib/libgrpc.so -ldl -lgrpc++ /usr/lib64/libprotobuf.so -lpthread /usr/lib64/libprotobuf-lite.so
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
[builder#f7279ae9f33f build (master %)]$ ldd libucsdos.so | grep libstdc++.so.6
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2a4a054000)
It's easy to find out that /lib64/libstdc++.so.6 version is 4.8.5:
[builder#f7279ae9f33f build (master %)]$ yum whatprovides "/lib64/libstdc++.so.6"
libstdc++-4.8.5-28.el7_5.1.x86_64 : GNU Standard C++ Library
Repo : #Updates
Matched from:
Filename : /lib64/libstdc++.so.6
Is this build environment configuration valid?
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
Yes. The devtoolset-6-gcc-c++ package provides a custom version of GCC that uses a special linker script instead of a dynamic library for libstdc++.so. That means the binaries it produces do not depend on the newer libstdc++.so.6 and can be run on other CentOS machines that don't have devtoolset installed (i.e. they only have the older libstdc++ library from GCC 4.8).
Is this build environment configuration valid?
Yes. What you're seeing is completely normal, and how it's supposed to work.
The pieces of the newer C++ runtime from GCC 6.4.0 get statically linked into your binary, and at runtime it only depends on the old libstdc++.so which every CentOS system has installed.
That's the whole point of the devtoolset version of GCC.
I'm looking to install matplotlib on CentOS using :
yum install python-matplotlib.x86_64
It works but the problem is that it is an old version (matplotlib 0.99.1.1) and I need the last version : [1.3.1].
So I've downloaded the source and trying with : python setup.py install
But I get this error ...
Edit setup.cfg to change the build options
BUILDING MATPLOTLIB
matplotlib: yes [1.3.1]
python: yes [2.6.6 (r266:84292, Jan 22 2014, 09:42:36) [GCC
4.4.7 20120313 (Red Hat 4.4.7-4)]]
platform: yes [linux2]
REQUIRED DEPENDENCIES AND EXTENSIONS
numpy: yes [version 1.8.1]
dateutil: yes [using dateutil version 1.4.1]
tornado: yes [using tornado version 3.2.2]
pyparsing: yes [using pyparsing version 2.0.2]
pycxx: yes [Couldn't import. Using local copy.]
libagg: yes [pkg-config information for 'libagg' could not
be found. Using local copy.]
freetype: yes [version 9.22.3]
png: yes [version 1.2.49]
OPTIONAL SUBPACKAGES
sample_data: yes [installing]
toolkits: yes [installing]
tests: yes [nose 0.11.1 or later is required to run the
matplotlib test suite]
OPTIONAL BACKEND EXTENSIONS
macosx: no [Mac OS-X only]
qt4agg: no [PyQt4 not found]
gtk3agg: no [Requires pygobject to be installed.]
gtk3cairo: no [Requires pygobject to be installed.]
Xlib: extension "RANDR" missing on display "localhost:22.0".
gtkagg: no [The C/C++ header for gtk (gtk/gtk.h) could not
be found. You may need to install the development
package.]
tkagg: yes [installing, version 73770]
wxagg: no [requires wxPython]
gtk: no [The C/C++ header for gtk (gtk/gtk.h) could not
be found. You may need to install the development
package.]
agg: yes [installing]
cairo: yes [installing, version 1.8.6]
windowing: no [Microsoft Windows only]
OPTIONAL LATEX DEPENDENCIES
dvipng: yes [version 1.11]
ghostscript: yes [version 8.70]
latex: yes [version 3.141592]
pdftops: no
running install
running bdist_egg
running egg_info
writing requirements to lib/matplotlib.egg-info/requires.txt
writing lib/matplotlib.egg-info/PKG-INFO
writing namespace_packages to lib/matplotlib.egg-info/namespace_packages.txt
writing top-level names to lib/matplotlib.egg-info/top_level.txt
writing dependency_links to lib/matplotlib.egg-info/dependency_links.txt
reading manifest file 'lib/matplotlib.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'lib/matplotlib.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
copying lib/matplotlib/mpl-data/matplotlibrc -> build/lib.linux-x86_64-2.6/matplotlib/mpl-data
running build_ext
building 'matplotlib._png' extension
gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib__png_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 -I/usr/lib64/python2.6/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/include/libpng12 -I/usr/include/python2.6 -c src/_png.cpp -o build/temp.linux-x86_64-2.6/src/_png.o
In file included from /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/ndarraytypes.h:1798,
from /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/ndarrayobject.h:17,
from /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/arrayobject.h:4,
from src/_png.cpp:28:
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
src/_png.cpp:243:48: error: macro "npy_PyFile_DupClose" requires 3 arguments, but only 2 given
src/_png.cpp:264:44: error: macro "npy_PyFile_DupClose" requires 3 arguments, but only 2 given
src/_png.cpp:577:44: error: macro "npy_PyFile_DupClose" requires 3 arguments, but only 2 given
In file included from src/file_compat.h:4,
from src/_png.cpp:31:
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_3kcompat.h: In function ‘PyObject* npy_PyFile_OpenFile(PyObject*, const char*)’:
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_3kcompat.h:348: warning: deprecated conversion from string constant to ‘char*’
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_3kcompat.h: In function ‘int npy_PyFile_CloseFile(PyObject*)’:
/usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_3kcompat.h:356: warning: deprecated conversion from string constant to ‘char*’
src/_png.cpp: In member function ‘Py::Object _png_module::write_png(const Py::Tuple&)’:
src/_png.cpp:243: error: ‘npy_PyFile_DupClose’ was not declared in this scope
src/_png.cpp:264: error: ‘npy_PyFile_DupClose’ was not declared in this scope
src/_png.cpp: In member function ‘PyObject* _png_module::_read_png(const Py::Object&, bool, int)’:
src/_png.cpp:329: warning: deprecated conversion from string constant to ‘char*’
src/_png.cpp:577: error: ‘npy_PyFile_DupClose’ was not declared in this scope
error: command 'gcc' failed with exit status 1
Any helps ?
Thanks
This has been fixed in version 1.4.0 (see patch here). I have successfully compiled version 1.4.0 on CentOS 6.5 after patching setupext.py to lower the required freetype version (as suggested in the installation notes).
I'm trying to get llvm-gcc 4.2.2.9 to compile on this x86_64 system which runs the 3.0.0-21-generic kernel. llvm 2.9 itself builds fine. I suspected the downloadable version of llvm-gcc was causing some other problems, so I decided to build llvm-gcc myself.
Like suggested in the README.LLVM I configured with
../llvm-gcc-4.2-2.9.source/configure \
--prefix=/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install \
--disable-multilib \
--program-prefix=llvm- \
--enable-llvm=/opt/llvm-2.9 \
--host=x86_64-generic-linux-gnu
--enable-languages=c,c++
I'm running this from the /opt/llvm-gcc4.2-2.9 directory, while the sources are sitting in /opt/llvm-gcc-4.2-2.9.source and my llvm 2.9 lives in /opt/llvm-2.9. Note that I'm setting the --host instead of the --target as this implicitly sets the --target to the same architecture.
make does build a lot of stuff (producing a sizeable amount of warnings) when finally stopping at this error:
make[3]: Entering directory `/opt/llvm-gcc4.2-2.9/gcc'
/opt/llvm-gcc4.2-2.9/./gcc/xgcc -B/opt/llvm-gcc4.2-2.9/./gcc/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/bin/ -B/opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/lib/ -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/include -isystem /opt/llvm-gcc4.2-2.9/../llvm-gcc4.2-2.9-install/x86_64-generic-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../llvm-gcc-4.2-2.9.source/gcc -I../../llvm-gcc-4.2-2.9.source/gcc/. -I../../llvm-gcc-4.2-2.9.source/gcc/../include -I../../llvm-gcc-4.2-2.9.source/gcc/../libcpp/include -I../../llvm-gcc-4.2-2.9.source/gcc/../libdecnumber -I../libdecnumber -I/opt/llvm-2.9/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer -fno-asynchronous-unwind-tables \
-c ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
In file included from /usr/include/stdio.h:28,
from ../../llvm-gcc-4.2-2.9.source/gcc/tsystem.h:90,
from ../../llvm-gcc-4.2-2.9.source/gcc/crtstuff.c:68:
/usr/include/features.h:323:26: error: bits/predefs.h: No such file or directory
/usr/include/features.h:356:25: error: sys/cdefs.h: No such file or directory
/usr/include/features.h:388:23: error: gnu/stubs.h: No such file or directory
I find it a bit odd that the include path goes from my system's stdio.h back to llvm-gcc headers and then tries again to include system headers. But maybe that's normal?
After that error hundreds of lines with more errors follow from the same compilation unit.
Could it be that my system's gcc 4.6.1 or my system's headers maybe grew incompatible with the dated llvm-gcc 4.2 headers? Then again, I know that on a different system (running the 2.6 kernel) gcc 4.5.2 plays well with llvm 2.7's gcc 4.2.
I'm at a loss here, because I do need a recent llvm 2.*, and the other two acceptable llvm versions (2.7, 2.8) didn't show any result more helpful.
It seems that /usr/include on your system provides 32-bit headers, thus the compilation fails since you do not have all multilib headers installed. You might need to patch llvm-gcc the same way as your distribution patches gcc in order to find the headers locations.
Alternatively, you might try to install 32-bit headers and try multilib build of llvm-gcc.
But the best way will be switch to LLVM 3.1 and clang :)