Re: [Condor-devel] debian support

[Peter Keller <psilord@xxxxxxxxxxx>]

Hello,

On Wed, Oct 25, 2006 at 11:13:43AM +0200, guillaume pernot wrote:
> > hum, nearly :( for both gcc and g++ :
> > job_rsc_getdirentries_std                (returned 255)
> > 
> > any clue for this one ?
> 
> hum, in fact, the test routine is bogus !

Yeah, we sometimes find a test like that every now and then... Thanks
for catching it!

> foobaz:~/src/pool/condor/src/condor_tests$ ./batch_test.pl -d g++ -t 
> job_rsc_getdirentries_std
> submitting g++ tests .
> job_rsc_getdirentries_std                succeeded
> 
> 1 successful, 0 failed

So, it looks like the port works, which is very good news.  Since you
were able to port glibc to the newer compiler, we can fix up another
of our linux ports to use the default compiler which will make others
happy as well.

As for the glibc build script patch, config/config.sh.in is probably
where you want to put something like this:

C_COMP_KIND = @CompilerKind@
C_COMP_MAJOR = @CompilerMajor@
C_COMP_MINOR = @CompilerMinor@
C_COMP_PATCH = @CompilerPatch@

and then in the build script for glibc 2.3.2.27.9.7 (which already brings
in config.sh via the '. $EXTERNALS_CONFIG' line), fix the part where all
of the patches are applied to apply all of them BUT the one you wrote,
and then if the compiler revision is gcc and greater than 3.3.x (I think
I saw that problem with 3.3.x, but it might have been 3.4.x..._) apply
the build patch for the compiler.

Then to finish the port, go into condor_scripts/make_final_tarballs, and
find the %opsysname, %archname, and %libcname, hash table definitions.

The %opsysname tables maps the system identifying string to a base OS.
Look at where this line gets printed in configure.ac to understand the format
of the system identifying string:
checking system identifying string... i386_centos44

You'll probably have something like:
	"i386_debainxxx"   => "linux",

debianxxx should be replaced by whatever your system identifying string is.

The %archname table maps the system identifying string to an architecture.
You'll probably have something like:
	"i386_debinaxxx"   => "x86",

The %libcname table is a bit wonky, because it used to map to the
libc revision of the glibc we use as the external. However, the
meaning has changed over the years and now more means a distribution
identification. You can see this evolution from something old like
"i386_rh72"   => "glibc22" to something new like "i386_rhel3"  => "rhel3".
You'll probably want something like:

	"i386_debianxxx"   => "debianxxx"

Then, when you build condor from a clean build, build it like this:

make release
make public

After make public finishes (there might be more to port when it comes
time to make the rpms for condor, and if debian has a different package
manager maybe scripts need to be produced to make that natively), then
cd into public/ at the top level (it'll be created during make public)
and check out the names of the things in there. If you see two hyphens in
a row, then a value got dropped that should have been in the file name.
If you don't see "linux", "x86", and "debianxxx" in the file name, then
something got dropped. But, I think it'll work pretty straightforwardly
for you. If debian uses rpm, and the rpm build steps succeed, then you 
might very well be done with the porting all together.

The last things I'd look over again are to make sure there aren't any helper
libraries in the gcc/c++ runtime which should be included in the release of
Condor that our configure.ac script doesn't detect.

If things look good, I think you're done.

Thank you.

-pete