[lsb-discuss] LSB sample implementation

Wichmann, Mats D mats.d.wichmann at intel.com
Wed Aug 2 09:44:42 PDT 2006


>> There are two development kits:
>> 
>> - a set of tools that include lsbcc, etc.
>
>I have not looked at these scripts to figure out how one can use a
>different compiler than gcc/g++. If this is easily possible this might
>be a solution.

It's easily possible in theory:

LSBCC=c-compiler-to-call lsbcc [args]
LSBCXX=c++-compiler-to-call lsbc++ [args]

sorry, no LSBF95 yet :-)

In practice, today, this only works correctly with gcc/g++.
For example, it works great if the default compiler is GCC 4.1
but you have a package installed providing GCC 3.4 with a
front-end named gcc34:

LSBCC=gcc34 lsbcc -o hello hello.c

We'll add support for other "known" compilers as demand
pushes it and as we get support.  For example, this has
been tried with "icc" but it turned out, at least a few
versions ago, that there were a few things that could
not be fully controlled from the command line that lsbcc
builds up before calling the external compiler.

>> - a complete set, designed to be used as a chroot (lsb-buildenv)
>
>not sure how we could utilize this in an automated fashion when the
>build is triggered automatically from a remote machine. I also thought
>chroot required root access.

So does starting various virtual machines, booting a new
environment, etc.  That's just a "fact of life".  My
point was that if you really wanted to, you could turn
lsb-buildenv into something that was either bootable standalone
or ran in a virtual machine.  Neither one of these gives you
a fully automated build capability that I can think of, but
this is not hard to set up with a script.  None of this is
going to work without root access of some form.  If you don't
switch environments, you're always risking picking up something
from the host and the environment is not properly controlled.
Package building in a chroot jail of some form is a pretty
well accepted practice.




More information about the lsb-discuss mailing list