[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] Standard universe python: dynamic library problem
- Date: Sun, 27 May 2007 21:18:25 -0500
- From: Colin Dewey <cdewey@xxxxxxxxxxxxxxxx>
- Subject: Re: [Condor-users] Standard universe python: dynamic library problem
Thanks, Daniel. I have very little experience with dynamic linking,
but I can't help but wonder: in the standard universe, filesystem
operations use a remote system call mechanism, and since dynamic
libraries are just files, wouldn't these also be loaded from the
remote submit node? If this were the case, then the glibc versions
are always the same because they are from the same machine?
On May 26, 2007, at 10:45 PM, Daniel Forrest wrote:
I have been trying to get Python compiled for the standard universe,
as was claimed possible in:
Unfortunately, I am encountering linking problems when using
condor_compile that relate to dynamic linking library (libdl.a). I
get a bunch of undefined references to functions in that library (see
below). I am using RHEL 4 with condor v6.8.4 (RHEL 3), gcc 3.4.6,
and python 2.3.6 (also tried python 2.5.1 without success). I
realize that Condor does not support checkpointing for Linux programs
that do dynamic linking, but I believe the program should at least
link properly (and be usable without the checkpointing feature).
Any help would be greatly appreciated.
Trust me, you don't want to go there. There are serious problems with
using dlopen in statically linked programs.
libpython2.3.a(dynload_shlib.o)(.text+0x15d): In function
Python/dynload_shlib.c:129: warning: Using 'dlopen' in statically
linked applications requires at runtime the shared libraries from the
glibc version used for linking
This warning message is telling you what the problem is. Even if
dlopen were available, it requires that the machine where your program
runs has the same glibc version installed as the one you built on.
As I understand it, the dlopen in the static program might work to
load a dynamic object, but if that object loads another one it would
use the dynamic dlopen and the version mismatch causes a crash.
What you want to do is configure a python that doesn't use dynamic
loading, but instead has the modules you need already built in. I
have done this with perl and I see no reason why it wouldn't work with
python. Here is a link I found about that very topic:
Daniel K. Forrest Laboratory for Molecular and
forrest@xxxxxxxxxxxxx Computational Genomics
(608) 262 - 9479 University of Wisconsin, Madison