Kostas Georgiou wrote:
> You can still run 32bit software under a 64bit system, LeSC is already
> using a 64bit system. The only problem is that python/perl/etc. are
> 64bit so if your software provides 32bit libraries that are loaded
> from the interpreters it will fail. The solution is to provide 32bit
> versions of python/perl/etc. and put them in front of the path for
> the lcg queues (I guess that you can even start the job with setarch
> i686 so that even uname -a will tell you are running in 32bit).
Exactly so. Building your own 32bit Python isn't actually necessary if
you're using the relocatable TAR distribution on your worker nodes as
one is already provided -- but building your own Perl installation is
pretty easy to do.
> That of course will stop 64bit software that wants to use the interpreters
> with their own libraries but thats uncommon for now but you can always
> get extra queues that use the system ones. Users will have to choose
> the right queue but it is better than not supporting everything.
At the moment, that isn't much of a problem. In the future, some kind
of specification or convention should be adopted to allow jobs compiled
for different architectures to find appropriate versions of compilers
and libraries, but that's a bigger problem (ideally handled by the big
Linux distributors.)
(Debian's Multiarch design[0] looks quite good for this.)
> I am sure David can provide more details about the LeSC setup which
> is already running this way.
I've just created http://wiki.gridpp.ac.uk/wiki/LCG-on-64bit; let me
know if you'd like me to expand on anything.
Cheers,
David
[0] http://wiki.debian.org/multiarch
--
David McBride <[log in to unmask]>
Department of Computing, Imperial College, London
|