Re: [Condor-devel] debian support

[Peter Keller <psilord@xxxxxxxxxxx>]

On Tue, Oct 24, 2006 at 11:17:58AM +0200, guillaume pernot wrote:
> condor_compile doesn't work with my previous patches :(
> 
> i have hard times trying to use static libs from debian distributions, but 
> both debian/sarge and ubuntu/dapper are missing /usr/lib/libnss_{files,dns}.a 
> (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203014).
> 
> that means we have to recompile glibc even if these distributions are shipping 
> a _nearly_ complete static library set :(
> 
> i'll make a patch for these and submit is here asap.

What version of glibc is used on these machines and what revisions of
gcc come on them? The version of glibc that Condor uses for its standard
universe codes is very exact and changing that revision will force a
full port of Condor to the new OS revision.

A full port of Condor generally means deep magic must be performed in
the condor_ckpt and condor_syscall_lib directories. For example, stat()
and its various implementations might have changed, objects might have
moved around suspiciously in the archive, functions we should trap could
have changed/been added, the extraction pattern denoted in the Imakefile
might have changed. It is a big deal to verify that a new glibc works
properly with respect to Condor since it in generally unknown what changed
in detail between the glibc you start with and the glibc to want to use.

In addition, the default gcc a machine has might affect the port as well
since we must ship along the internal libraries of gcc, and those might
also have changed.

Sometimes a full port just takes a week or two, sometimes 12-16 weeks. It
really depends on the particular circumstances between Condor and the
target machine in question.

I'd recommend running the entire condor test suite (both stduniv and
other tests) if you go down this path (or really, if you do any patching
of Condor). Of course, I can help if you need it.

-pete