We're having very little joy getting the standard universe to work with
the x86_64 build for Condor 6.8.2, and we'd be ecstatically pleased if
*anyone* could shed some light on the matter. First, here are the
details of the Linux platform we're testing on:
Machine OS: Suse Enterprise Server 10
uname -a: Linux <hostname> 2.6.16.21-0.25-default #1 Tue Sep 19 07:26:15
UTC 2006 x86_64 x86_64 x86_64 GNU/Linux
From /proc/cpuinfo: model name : AMD Athlon(tm) 64 Processor 3200+
As suggested on the Condor Download page, we've installed the
dynamically-linked version of the RHE3 Opteron 6.8.2 build. The software
we've tested is a C++ application that works fine both with the native
g++ v4.1.0 on the machine as well as g++ v3.4.6 that we also installed.
Now for condor_compiling: condor_compile builds and links "fine" with
g++ v3.4.6 but fails with v 4.1.0, though the latter can be made to link
if -fno-threadsafe-statics is added to the compilation flags. If we now
try to run either executable at the command line (never mind submitting
as a Condor job) then both fail with a segment violation. Here's what
gdb has to say about it:
===
Starting program:
/home/Condor/mark/test/diffmc/diffmc-standard-x86_64-v4.1.0 NVT_PARAM
CONFIG
Condor: Notice: Will checkpoint to
/home/Condor/mark/test/diffmc/diffmc-standard-x86_64-v4.1.0.ckpt
Condor: Notice: Remote system calls disabled.
Program received signal SIGSEGV, Segmentation fault.
0x00000000004adeeb in std::locale::operator= ()
===
I'm guessing that this is a dynamic library incompatibility problem, but
how do we get out of this pickle? What x86_64 linux distros are people
successfully using with the standard universe? For what it's worth, we
can get the standard universe to work on i386 platforms OK.
Thanks,
Mark