Setting Up A Debug Environment
I've been trying to set up a debugable version of fipy in virtualenv for debugging a trilinos issue. Here are the steps:
- Install the python-dbg package from the Debian repositories.
- Use mkvirtualenv -p python-dbg debug to make the debug environment.
- Install numpy with pip install, not debug.
- Install swig in the standard way.
- Here is the do-configure for trilinos
EXTRA_ARGS=$@ TRILINOS_HOME=/users/wd15/Documents/python/trilinos-10.8.3-Source CMAKE=cmake PYTHON_EXECUTABLE=${VIRTUAL_ENV}/bin/python ${CMAKE} \ -D CMAKE_BUILD_TYPE:STRING=DEBUG \ -D Trilinos_ENABLE_PyTrilinos:BOOL=ON \ -D BUILD_SHARED_LIBS:BOOL=ON \ -D Trilinos_ENABLE_ALL_OPTIONAL_PACKAGES:BOOL=ON \ -D TPL_ENABLE_MPI:BOOL=ON \ -D Trilinos_ENABLE_TESTS:BOOL=ON \ -D PYTHON_EXECUTABLE:FILEPATH=${PYTHON_EXECUTABLE} \ -D DART_TESTING_TIMEOUT:STRING=600 \ -D CMAKE_INSTALL_PREFIX:PATH=${VIRTUAL_ENV} \ -D PyTrilinos_INSTALL_PREFIX:PATH=${VIRTUAL_ENV} \ ${EXTRA_ARGS} \ ${TRILINOS_HOME}
Comments
This doesn't currently compile. Get the following config error.
What is happening is that the debug version of python is not returning the numpy version in the correct format. See packages/PyTrilinos/cmake/FindNumPy.cmake line 55.
The problem is the debug version of numpy returns an extra line with the ref count.
I'm stuck at this point. Don't know what to do.
I hacked it to make it work.
Nasty! I don't think there was a way round that without amending FindNumPy.cmake in some way.
So Trilinos installed fine. However I can't import pytrilinos
Giving up.
The failure in comment 3 was because LD_LIBRARY_PATH wasn't set. After setting that, PyTrilinos? throws the following
Not sure what the issue is, something is missing though.
Examinimg libpytrilinos.so with nm and ldd reveals the following unhelpful info. ldd does not seem to show a libpython dependecy where Py_InitModule4_64 is rumored to hide. nm confirms that Py_InitModule4_64 is undefined along with a whole array of other symbols.
Found this:
"We ran into this error on Debian this morning, with a system that had more than one Python.
Typically this means that an extension was compiled against the wrong Python.h.
This just means that the calling Python interpreter and the extension don't use the same version (one is Python 2.4, the other 2.5). They were both 64-bit but the name changed in http://www.python.org/dev/peps/pep-0353/
Some commands to help debug this are ldd (to show dymanic library linking) and nm (to list exports)."
It's certainly possible that the debug python version is using the regular python versions libraries.
Starting over with
instead.
Using
makes no difference.