Re: [Condor-devel] Official Debian package for Condor

[Peter Keller <psilord@xxxxxxxxxxx>]

Hello,

On Wed, Dec 08, 2010 at 03:39:37PM -0500, Michael Hanke wrote:
> On Tue, Dec 07, 2010 at 03:42:54PM -0500, Michael Hanke wrote:
> > I'm compiling a list of questions regarding the packaging -- most of
> > them concerning a proper port to Debian's glibc.
> 
> I'd be glad if I could get some pointers to GLIBC-related issues. The
> upcoming Debian release will come with GLIBC 2.11. Condor has not been
> ported to this version yet. If I look into the code I find long chains
> of 'defined(GLIBC21) || defined(GLIBC25 || ...'. What is the desired
> strategy to port Condor to a newer GLIBC version? It looks like I can
> only inspect every ifdef and append to the chain. I wonder whether there
> is a better approach? Let's say the behavior of GLIBC 2.11 and 2.7 is
> identical, I'd still have to add GLIBC211 explicitely.
> 
> Is it possible to, by default, treat newer GLIBC versions like the
> latest GLIBC version that Condor has already been ported to (and only
> handle actual differences between these two versions)?
> 
> Related to that: What is the reason to categorically disable the
> standard universe build whenever the GLIBC version is unknown? Are there
> actual problems, or is it simply to limit possible build environment to
> trusted grounds?

I'm the person who is most knowledgable about porting Condor's stduniv
(and I haven't responded to your rust ticket yet).

Condor's stduniv on linux, among other things, is also a link compatible
interface with glibc. This is because we do interposition at the library
level during link time to catch all of the system calls for remote i/o
and some calls for checkpointing.

Porting stduniv, even from one glibc version to another, is a very complex
task and requires pretty deep knowledge of unix systems programming on
linux, historical understanding of linux kernels and glibc revisions going
back a few years at least, and arcance knowledge of verious reviions
of gcc compiler runtimes.  It can take me anywhere from 1 to 6 months
to perform the work and validate it. That's working on it nearly every
day too...

The problem at hand isn't the condor ifdefs, it is understanding the
semantic and structural changes across time in glibc implementations,
linux kernels, and gcc/g++ runtimes.

The maintenance costs of stduniv are pretty high and we're looking to an
adjunct solution using DMTCP. If you are willing to help out by hacking
some code in the Condor's test suite to integrate DMTCP with the stduniv
tests, that would likely be a good use of time and I have a starting
point for it.

However, if you are itching to undertake porting stduniv, I can do my
best to write up a porting guide for how to, or at least what you should
watch out for, perform a port of stduniv to a newer version of glibc.

Later,
-pete