[Bug 898172] [NEW] ctypes broken on armhf
Loïc Minier
lool at dooz.org
Wed Nov 30 14:01:55 UTC 2011
Public bug reported:
Hi
Python's ctypes allows dynamically loading libraries. On linux, it
parses ldconfig -p output for a given library name, skipping over
incompatible ABIs. ABI is derived from uname output, which is
incorrect. Currently, the code can't cope with "hard-float" in the
ldconfig -p output on armhf.
I will attach a debdiff which allows ctypes to work on either armel or
armhf, but wont work on a biarch or multiarch armel + armhf system.
The code should be redesigned to check the real ABI, not the uname
output; one option to do so is to check the ABI of the currently running
executable, e.g. ldd on sys.executable as done elsewhere in the script,
but still seems fragile; another option is to look at /proc/$pid/maps
(probably not portable); another option is to ask libc to do the loading
(seems the safest).
Cheers,
** Affects: python2.6 (Ubuntu)
Importance: Undecided
Status: New
** Affects: python2.7 (Ubuntu)
Importance: Undecided
Status: New
** Affects: python3.2 (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to python2.7 in Ubuntu.
https://bugs.launchpad.net/bugs/898172
Title:
ctypes broken on armhf
Status in “python2.6” package in Ubuntu:
New
Status in “python2.7” package in Ubuntu:
New
Status in “python3.2” package in Ubuntu:
New
Bug description:
Hi
Python's ctypes allows dynamically loading libraries. On linux, it
parses ldconfig -p output for a given library name, skipping over
incompatible ABIs. ABI is derived from uname output, which is
incorrect. Currently, the code can't cope with "hard-float" in the
ldconfig -p output on armhf.
I will attach a debdiff which allows ctypes to work on either armel or
armhf, but wont work on a biarch or multiarch armel + armhf system.
The code should be redesigned to check the real ABI, not the uname
output; one option to do so is to check the ABI of the currently
running executable, e.g. ldd on sys.executable as done elsewhere in
the script, but still seems fragile; another option is to look at
/proc/$pid/maps (probably not portable); another option is to ask libc
to do the loading (seems the safest).
Cheers,
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/898172/+subscriptions
More information about the foundations-bugs
mailing list