Loïc Minier wrote:
We faced this in the Ubuntu armhf port as well; the bug is described in
details there:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/898172
Essentially ctypes' "find_library" is very wrong and should not be used
(it tries to emulate ld.so's search behavior but does so with many
scary shortcuts...). find_library breaks on armhf because its ldconfig
output parsing isn't ready for the ",hard-float" suffix on libraries in
the cache.
Not only is find_library poorly implemented, but it also encourages
upstreams to try loading *any* SONAME from a library (in fact the first
one which comes in the ldconfig output), and with *whatever*
architecture ABI. So if you have the 32-bits libenchant12, 32-bits
libenchant13, 64-bits libenchant12 and 64-bits libenchant13, and you
find_library("enchant"), any of these libraries might be loaded
depending on the ldconfig output ordering...
I've opened an upstream bug (see the Launchpad meta-bug) and AFAIK the
python2.x patches will be uploaded to Debian with next uploads.
According to the launchpad "meta-bug" the python2.7 fix was already
uploaded to
unstable. This would fit with my test succeeding with python2.7 and
failing with
python2.6
Python2.6 (ubuntu) in the launchpad meta-bug is marked as "won't fix"
because python2.6 is "to be removed" are there any plans to fix
python2.6 in
debian or do they plan to remove it like ubuntu do?
It would be best if we would patch python programs and modules to stop
using find_library.
Should a bug be opened against python-enchant? and if so what should the
package use instead of find_library?
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ef887ff.60...@p10link.net
