On Tue, May 01, 2012 at 12:25:30PM +0700, Nick Fenwick wrote:
On 05/01/2012 11:47 AM, Nick Fenwick wrote:
python-2.7.2-5.2.fc16.x86_64
It seems that because I had only the 64 bit python rpms installed, I didn't
have the 32 bit libraries.
ln -s /usr/lib64/libpython2.7.so /usr/lib/libpython2.7.so
This was a hack. Installing i686 architecture fixed my problem more
gracefully.
yum install libpython.i686
Do you feel this is a dependency problem in one of the other systems I've
installed (ruby, octopress), and their dependency on python? Perhaps I should
move this query onto some other forum, such as rvm (the ruby installer, some
part of which installed rubypython). There's a thread at
https://github.com/
imathis/octopress/issues/251 where the Octopress guy seems to be distancing
himself from dependency management, which doesn't look promising if the ball's
actually in his court.
Yeah -- on 64bit multilib, the system should find the 64 bit libraries in
/usr/lib64/ and on 32bit multilib systems, in /usr/lib/. It's a little
strange to me that your program works with either the 64bit compiled library
or the 32bit compiled library. (It used the 64bit lib when you symlinked
and the 32bit lib when you installed the 32bit package). Normally the
program you've installed is linked at buildtime to one or the other (and
built to work with a library that expects certain types to be of a certain
size associated with that architecture). This also seems to imply that the
library is not being loaded by the system dynamic linker but by something
else -- perhaps it's being brought in as part of a dlopen'd object.
My best guess is that this is a problem with one of the things that's making
use of libpython. Perhaps the program was built on a 32bit system and it
therefore assumes that libraries are in /usr/lib/. Perhaps the path is
hardcoded to be /usr/lib/ in the build scripts.
-Toshio