[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