LSB development environment
I've uploaded lsbdev-1.0.1.tar.gz to ftp://ftp.freestandards.org/pub/lsb/lsbdev
Although its very different from the previous version it contains much
of what is in lsbdev-1.0.0 and the xdevel directory of the impl CVS
module plus more. Don't be mislead by the version number - it
shouldn't be considered at all `stable'.
It has not yet been tested it on other machines other than my laptop
so it may not work properly on all distributions, but I would like to
hear of any problems you may have. You will need at least glibc 2.2
and a 2.4.x kernel.
Attached is the README file from the tarball. Please read it and the
INSTALL file completely before using the environment as its possible
to delete important files on your system if you don't understand how
it works properly.
I've managed to compile a simple package in it (byacc which is
currently needed to compile the LSB test suites). More complex
packages like rsync are able to configure themselves and compile[1] in
the environment.
There's lots more to do before I'd consider it really useful, but I'd
appreciate any feedback you may have. I'll be working on making it
easier to setup and use, and seeing if I can get the LSB test suites
compiled in it.
Chris.
[1] Could not actually link rsync because it uses the non LSB interface
'getpass'
--
yeohc@au1.ibm.com
IBM OzLabs Linux Development Group
Canberra, Australia
LSB Build Environment
=====================
Last updated 2001/8/29
This purpose of this package is to make it easier to build LSB
compliant applications. It is not meant to necessarily provide an LSB
runtime environment and is possible/easy to build a binary in the
build environment which will not actually run in it. Use the LSB
sample implementation to test the binaries and packages.
See the INSTALL file for instructions on how to setup and use the
build environment.
This build environment should be considered EXPERIMENTAL. Ensure that
you understand how bind-mounts work before removing files in the build
environment. Depending on which version of the kernel you are using
read-only bind mounts may not in fact be read only, so it is possible
to accidentally remove important files outside of the chroot area from
within it. The purpose of the chroot area is not for reasons of
security, but instead to make it easier to build applications without
accidentally polluting binaries with information from non-compliant
header files and libraries (as can easily happen with configure
scripts).
A developer can build an application within this build environment by
first chrooting into the directory structure constructed by the setup
scripts. This environment by default provides tools installed in /bin
and /usr/bin and the core runtime libraries needed to compile and link
a binary. As there currently are not a set of known LSB compliant
header files available the header files of the system are used.
Although a complete set of development tools will not be available
through just /bin and /usr/bin more may be included by individually
bind mounting them into the chroot area.
The package contains the following:
- LSB stub libraries (stub_libs).
These libraries contain the versioned symbols as required by
the LSB specification. Linking against these libraries will ensure
that the application attempts to use the correct versions
at runtime. They do not contain the code necessary for
a program to operate during runtime.
- gcc spec file
A modified version for gcc (2.95.4). This will ensure that the programs
are linked against ld-lsb.so.1 instead of ls-linux.so.2. It also
adds the lsb stub library directory to the link search path.
- rpm binaries
A statically linked version of rpm and associated binaries/scripts
and other infrastructure needed to package applications. You might
not need this if you have a version of rpm capable of generating
v3 format packages on your system.
- setup scripts
scripts to setup the chroot build environment
Known Bugs
----------
- No tested LSB compliant header files available yet. /usr/include
from system used in place which may not be completely compliant.
- Not all of the variables in stub libraries are of the correct size
because of missing data in the LSB database. However for the ones of
unknown size large defaults (1000 bytes) have been used so I think
linked binaries should work ok.
- No automatic cleanup of bind mounts
Running:
umount `cut -d' ' -f2 /proc/mounts | grep $ROOT | sort -r`
where $ROOT is the root of the chroot environment should remove them
all in most cases.
Feedback
--------
Please send any comments you may have to lsb-impl@linuxbase.org
Chris Yeoh <cyeoh@samba.org>
Reply to: