[lsb-discuss] Building LSB-compliant apps on a non-LSB compliant system

[Dan Harrison]

Hello, list.

Just for fun, I wanted to see how difficult this endeavor would be. I
have Arch Linux -- a distribution that is off your radar screen, for
good reason -- and I felt like seeing if there are any troubles
building an LSB-compliant application on such an unusual system. You
will be pleased to hear it turned out to not be quite as much of an
adventure as I thought.

First, I had to install the SDK and AppChecker (to validate my work).
The main wrinkle in this process is that Arch Linux predates both
RedHat and Debian, and thus, the RPM and DEB formats. It was one of
the first "Linux, now with a Package Manager!" distros ever written,
so it uses its own custom package manager -- which is superior to both
of the others. :-P

Anyway, the SDK and APPCHK downloads -- tarballs which expanded into a
bunch of RPMs -- had to be converted. Fortunately, it was easy, for
the reason I consider this package manager superior. Unlike the other
two formats -- which require structured directories, checksums,
control files, mandatory un/install scripts, and multiple tools for
construction from source to finished product -- all I had to do was
write a quick "build recipe" file. It contained nothing but a little
metadata -- e.g. name, version, conflicts -- and the directions to
build it from source, written as a shell script with magical function
names.

Here is all those directions consisted of:

build() {
  cd "${srcdir}" # where it unpacks the original tarball automatically
  # unpack the RPMs, one at a time, and dump out their contents into
a local opt/
  for i in ${pkgname}/*rpm; do
    rpm2cpio $i | zcat | cpio -id
  done
}
package() {
  # now just copy the opt directory to the "install sandbox", while preserving
permissions top to bottom
  cp -a "${srcdir}/opt" "${pkgdir}/opt"
}

And that was it. Different package names, same build directions. I
just build the package with a tool, and that was that. (It did stuff
like ownership repair too; and I had to tell it NOT to strip the
binaries and libs.)

But there was one more little wrinkle: the loader. Neither of those
packages had the LSB-specified loader. But that just took installing
another package on the Arch repos called "ld-lsb", which has just four
files in it:

/usr/lib/ld-lsb-x86-64.so.2
/usr/lib/ld-lsb-x86-64.so.3
/usr/lib/ld-lsb.so.2
/usr/lib/ld-lsb.so.3

Thank you, by the way, for moving that out of /lib! The last time I
needed an LSB compliant loader a couple years ago, it was a giant mess
to get it working.

Finally, I wanted to compile something simple. I tried libjpeg-turbo.
It was something that had some discussion on the mailing list a while
back, and had no dependent libraries except libc. (I know that
dependency handling is where some of the bugs were; this was just a
sanity test of the wrapper script and toolchain.)

I tried the obvious: setting the C and C++ compilers to lsbcc,
clearing all of the CFLAGS (which I had all sorts of machine-specific
stuff in), and just told Arch to build the recipe. And it Just
Worked(tm). There was a little Makefile glitch, but I'm presuming
that's the package's fault, not the LSB's, so nevermind that.

Then, I stripped the library, and ran appchecker on it, looking for
bad symbols. This is what I got:

$ lsbappchk -T core,c++ -o journal.txt -s -L libjpeg.so
LSB version is not specified, using 4.1 by default.

SO-Pass1: libjpeg.so
SO-Pass2: libjpeg.so
Section .note.gnu.build-id: Not recognized by name. Checking as type SHT_NOTE
Section SHT_NOTE not checked
Section .hash contents not checked
Section .dynsym contents not checked
Section .dynstr contents not checked
Section .gnu.version contents not checked
Section .gnu.version_d contents not checked
Section .gnu.version_r contents not checked
Section .init contents not checked
Section .plt contents not checked
Section .text contents not checked
Section .fini contents not checked
WARNING: there was a problem parsing the eh_frame section of
libjpeg.so. This is not a compliance issue but to aid further evolution
of the LSB, please rerun the program with the environment
variable ELFCHK_DEBUG set to 17 and email the output to
<lsb-discuss at linux-foundation.org>
Section .init_array contents not checked
Section .fini_array contents not checked
Section .jcr contents not checked
Section .got contents not checked
Section .got.plt contents not checked
Section .bss contents not checked
Section .shstrtab contents not checked

LSB Unknown Symbol Report
=========================
No unspecified symbols were found.

I'd call that success. Great work, guys! You get all the credit! :-)

Should I "rerun the program which ELFCHK_DEBUG set to 17 and email the
output to <lsb-discuss at linux-foundation.org>"?

--
Dan Harrison