[lsb-discuss] Fw: LSB conference call agenda (Tuesday, September 5, 11am ET)

Dallman, John jgd at ugs.com
Tue Sep 5 07:42:34 PDT 2006


> John D, could you shed more light on what is not acceptable about the
> chroot environment?

Our build system is not self-contained on one machine. The source, 
the directories where compiled code is to be stored, and all of 
the test data are on the network. Most of the tools used are also
on network disk; we rely on a machine's own installed software for 
only the shells (and sometimes perl), compiler and linker. 

The people working on porting do not have root access; that's reserved 
for the sysadmins, who are few in number, and do not get involved in 
the inner details of teams' work environments. 

All of this means that the idea of a different root filesystem,
implying separate network mounts, was intimidating. Since we could 
use LSBCC very easily - just set an environment variable - and LSB 
compliance has the status of an attractive idea that may save us 
some work sometime, rather than anything that a customer wants, the 
choice was easy. 

It may be that I've utterly misunderstood what chroot really does,
but LSBCC works OK for us. 

> We have also encountered more than one ISV who had to have a 
> specific level of the compiler in order to generate correct code, 
> presumably.

I'm producing libraries for other ISVs to use. They need to 
compile their code in a compatible manner, and are often (a) 
good at infecting themselves with FUD (b) less skilful in 
configuring computers than they are in the esoteric field that 
they write software for and (c) don't have high proficiency in 
English. 

That means there's a major premium on having a simply described 
configuration, to cut down on support calls. So it's much preferable 
to be able to say "The GCC 3.3.3 shipped with SLES9sp1" than it is 
to say "GCC 3.3.3, from branch X on the CVS tree, plus patches Q, 
R and S, but not T".

We have also, over the last twenty years, learned to treat new
versions of compilers with considerable caution. New things are
broken from time to time: we definitely cannot treat them as 
being upwards compatible in the same ways that we can usually 
treat operating systems. 

We have a great deal of code, and the ability to test it very 
thoroughly. We also have customers who place a great deal of 
important on performance, although not at the expense of correct 
results. So we have to work with fairly high level of optimisation. 
We often find that problems can be got round by reducing the 
optimisation on one or two files, in a way that would be unacceptable 
if applied to the whole product. Yes, that means we're sometimes
working around compiler bugs rather than digging them out and 
reporting them. We report a lot of compiler bugs, but trying to 
figure out optimisation-dependent sequencing errors in the middle
of thousands of floating-point instructions is really hard. 

So overall, we want to stick with a compiler version for a while 
once we have it working right. Our build system checks the 
configuration when it starts a build, and if it find any version
changes in the tools, or in the compiler options, it flat-out 
refuses to go any further until a human has told it that's OK. 
Paranoia, but the results of long experience. 

-- 
John Dallman, Parasolid Porting Engineer, +44-1223-371554 




More information about the lsb-discuss mailing list