[lsb-discuss] LSB and the GNU build system

[Theodore Tso]

On Tue, Jul 01, 2008 at 12:23:34PM +0200, Dallman, John wrote:
> But there's an obvious way to do an end run round the problem: should
> the GNU build system have options for building LSB-compliant libraries? 

There are three answers to your question.  The first is that is GNU
build system is too low-level to deal with LSB compliance issues.
It's not just matter of options to the C compiler and linker, but it's
also specific libraries that go far beyond what is shipped by the GNU
project.  (For example, things like the Qt libraries, in the next
version of the LSB, the NSS libraries, etc.)  So the problem is one of
simply being at the wrong level of abstraction.

The second answer is that making LSB-compliant libraries is a lot more
than just using a different compiler toolchain.  Using the LSB SDK
will solve a number of issues flagged by the LSB Application Checker
(currently known as the Application Testkit Manager), but by itself it
is not enough.  In some cases, you have to make source-level changes.
For example, certain interfaces such as memalign are not supported in
the LSB; but the simple replacement of that interface with
posix_memalign() is all that is needed to solve that particular
problem.  In other cases, because the OpenSSL library does not have a
stable ABI, in LSB 4.0 we will be adding the NSS library to provide
equivalent functionality --- but if your code is currently written to
use the OpenSSL library, it will need to be changed to use the NSS
library.

The third observation is that even if the GNU tools magically gained
the ability to generate LSB-compliant libraries tomorrow, you would
still have to rebuild all of your libraries with the new GNU tools.   

With LSB 4.0, we will be shipping a new LSB SDK that should make it
easier to use and integrate into existing build systems, and so what I
would suggest doing is to make plans to start next year to use the LSB
SDK (which is basically a set of wrappers around gcc and ld, plus a
set of header files and other configuration files) instead of using
the GNU toolchain directly.  It may be that for your company the
transition to using the LSB is something that will have to be done
gradually, as your various LGPL binary components are gradually
converted over to being compiled with the LSB toolchain, and as each
binary component is modified as necessary for maximum
cross-distribution compatibility and LSB conformance.

> Not an appealing
> idea to development managers with limited resources to work with, who
> are still trying to understand why the different flavours of Linux aren't
> automatically binary-compatible. 

One thing to point out to your managers is that very often there are
incompatibilities between Windows 98, ME, XP, 2000, and Vista, even
for applications that only try to restrict themselves to the Win32
API.  And of course, it's very easy to accidentally use some new
interface in Windows which only works on newer Windows systems.  So
this problem isn't unique to Linux.  The LSB is intended to help solve
this problem, but it is not a panacea.

The other thing to point out is that there are advantages to their
being multiple competing flavors of Linux; it means that you don't
have a single monopolistic company (either Microsoft or Apple)
dictating changes unilaterally to customers and ISVs.  (It's not just
Microsoft; observe what happened to Adobe when without warning
announced that they were dropping the 64-bit Carbon APIs from Leopard
on the first day of WWDC 2007; as a result the "the fastest way to run
Photoshop CS4 on a Mac will be to run it on Windows[1].)

[1] http://daringfireball.net/2008/04/64000_question

So with the Linux ecosystem, you have to take the bad with the good.
The LSB is intended to be a way to fix up some of the less pleasant
aspects of the fact that there are multiple competing flavors of
Linux.


The one thing I would add in conclusion is that it's great that you
are asking these questions, and if you are interested in a few months
when we have some initial versions of these tools that would be ready
for a beta-test, it would be great if we could include you on the beta
program, and get back your feedback about how easy it is to replace
the use of the raw GNU toolchain with the LSB toolset.  We also have a
pre-release version of the next version of the Linux Application
Checker which may be useful as you are trying to determine how
cross-platform portable your applications and libraries are, and what
you might need to do to improve their portability.

Best regards,

					- Ted