LSB Compliance Example

Create a simple "hello world" program.

cat > hw.c << FILE

&include <stdio.h>

int
main(int argc, char *argv[]) {
	printf("Hello World\n");
}

FILE

Compile the "hello world" program and link it with the LSB loader and libraries.

$ gcc -o hw -Wall hw.c -L/usr/lib/lsb -Wl,--dynamic-linker=/lib/ld-lsb.so.1

Test to see if the "hello world" program works.

$ ./hw

  Hello World

Test to see if the "hello world" program is using the LSB loader and libraries.

$ ldd hw

  libc.so.6 => /lib/lsb/libc.so.6
  /lib/ld-lsb.so.1 => /lib/ld-lsb.so.1

Test of see if the "hello world" program is LSB compliant.

$ lsbappchk hw

If there is any output from lsbappchk, then it detected API calls that are not specified by the LSB.

To correct this, the programmer has the following options:

To satisfy this API calls link these functions statically (last resort for SUID/SGID programms). To make this less annoying, we recommend to concentrate the privileged activity (e.g. opening port 80 for a web server) on a small binary, which is called by a non privileged binary and can do its work after the small SUID/GID binary has done its job.

Supply a vendor private dynamic library. When linking, explicitly add this library path with the -rpath linker option. Applications should be aware that using -rpath makes it difficult/impossible to ship a package which can be installed in more than one location.

Supply a vendor private dynamic library and get it loaded at runtime by setting the Environment variable LD_LIBRARY_PATH. This will not work with SUID/SGID programms.