[lsb-discuss] Some questions on the LSB build environment

[Mike Hearn]

Hi,

I'm investigating how to use the LSB to let me build binaries of open
source apps that will work on any LSB compliant distro, as I don't wish
to make RPMs for every version of every distro which has been the
traditional way. 

As part of that, I've been trying out the tools, in particular lsbcc and
trying to port a small random app I have lying around my hard disk.

My first question is if there is any way to stop lsbcc attempting to
statically link all the additional libraries. As we can use stuff like
apt to effectively "distibute the libraries with the application" I
clearly don't want to statically link anything if I don't have to. It's
not realistic to statically link the gnome libs into every gnome app for
example. I can't see any way of doing that though, and there doesn't
seem to be an lsbcc manpage.

Secondly, why some of the header files differ from the standard Linux
ones. For instance, sys/un.h on my SuSE 8 system has the SUN_LEN macro
defined, but the LSB version doesn't. This random app needs that macro,
so I'm puzzled as to why it isn't included in the LSB, I can't see any
real reason for that. Is it OK to copy definitions from the standard
headers to the app if it needs them?

Thirdly, compiling the app with lsbcc results in quite a few warnings of
the form:

In file included <snip>
                 from services.h:27,
                 from services.c:23:
/opt/lsbdev-base/include/stddef.h:12: warning: `NULL' redefined
../dbus/dbus-macros.h:49: warning: this is the location of the previous
definition

Is it right that NULL is redefined, or am I seeing this warning for
another reason?

In particular, it should be understood that I'm not interested in having
these apps actually fully compliant, with the certs and everything,
simply stopping the binaries binding to the latest glibc symbols is
enough as that's one cause of concern - if I build a binary on a very
new distro, it could end up using symbols not available in slightly
older distros.

Finally, how far behind do the symvers for glibc lag in the LSB? There's
little point in the glibc team introducing new symbols if the LSB
mandates the use of older ones for ages. I'm interested in a more stable
platform than what Linux currently gives us for sure, but eventually I'd
expect the versions to be bumped up, are there plans for that?

Are there any other issues I should be aware of?
thanks -mike