© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
James,
I can observe the same problem, the debug version of the Subversion python libraries is not loaded. For that reason, I've moved the bug report to Confirm. It's not the same scenario as what you described, but it's enough to show there is something wrong in that area. I devised a test case to demonstrate the situation.
Details of the test case for anyone to reproduce:
Required packages
=================
python 2.5.2-0ubuntu1
python-dbg 2.5.2-0ubuntu1
python-subversion 1.4.6dfsg1-2ubuntu1
python-
Environment Variables
=======
PYTHONPATH=
This should not be required, but the Subversion app does not add a .pth file in the site-packages as others do. One must then take an action to provide the path to the Subversion libraries. You can verify this by inoking the Python interpreter and importing the _wc module.
@ubuntu:~$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import _wc
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named _wc
>>>
Displaying the effective library path
=======
>>> import sys
>>> print "\n".join(sys.path)
/usr/lib/
/usr/lib/
/usr/lib/python2.5
/usr/lib/
/usr/lib/
/usr/lib/
/usr/local/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/var/lib/
/usr/lib/
/var/lib/
/usr/lib/
>>>
Note that the Numeric app is already in the path without any actions on our part. None of the paths point to a debug version of the librairies either. So far we have been using the /usr/bin/python executable.
Run the Debugger and the debug version of Python
=======
We will set a breakpoint in the Python code where it loads the shared libraries. This is how we can tell if the debug version have been loaded or not. We then run the python interpreter and it will stop in the readline module. Note the library module name is readline_d.so in the same directory as readline.so. Type c to continue execution.
We are ready to import the Subversion _wc module which should load the _wc debug version somehow. However, the non-debug version is loaded. This concluded the demonstration for the bug report.
@ubuntu:~/python$ gdb -q --args python-dbg
(gdb) b _PyImport_
Breakpoint 1 at 0x4d8bd8: file ../Python/
(gdb) run
Starting program: /usr/bin/python-dbg
[Thread debugging using libthread_db enabled]
Python 2.5.2 (r252:60911, Jul 31 2008, 17:30:47)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
[New Thread 0x7f54f6db36e0 (LWP 11909)]
[Switching to Thread 0x7f54f6db36e0 (LWP 11909)]
Breakpoint 1, _PyImport_
pathname=
fp=0x831540) at ../Python/
28 ../Python/
in ../Python/
(gdb) c
Continuing.
>>> import _wc
Breakpoint 1, _PyImport_
pathname=
28 in ../Python/
Observations
============
The python interpreter loads its own libraries as _d.so. This also applies to other applications. I tried one, Numeric for which I installed the debug-version. It too, loads a _d.so library for debugging. I searched the Internet and found several python related makefile with some scheme to handle *_d.so.
When I copy the _wc.so debug version, rename it to _wc_d.so and place it in the same directory as the _wc.so, everything now works out of the box (save for the PYTHONPATH env var). It does appear that the debug architecture is to provide debug version libraires with a _d suffix and place them in the same directory.
For the python libraires, there are 2 copies of each debug version library:
/usr/lib/
/usr/lib/
However they have significant size differences. I have not seen the /usr/lib/debug version being used, perhaps they are in a different context.
BugSquad