[Lsb-wg] opposition to LSB 2.0 rc1

Joe Buck Joe.Buck@synopsys.COM
Sun Aug 1 00:12:00 GMT 2004


Alan Cox wrote:
> > Does the gcc steering committee have a formal opinion on the situation ?

On Sat, Jul 31, 2004 at 04:11:59PM -0700, Per Bothner wrote:
> The opinion of the FSF (I don't remember RMS's exact wording) is that
> a "Linux Standard Base" is not relevant to GNU.

RMS went further; as long as we are officially the maintainers of a GNU
program, we cannot officially cooperate with the LSB, though we can help
if we want while speaking as private individuals.  What this means is
that there will never be an official SC opinion on the LSB.

> In fact, it's kind of strange:  LSB seems to be trying to define an
> application binary interface (in the general sense, including file
> system standards), for which the choise of kernel should have no
> relevancy (except for marketing).  E.g. it seems perfectly reasonable
> for a BSD-based system to support such a standard, except perhaps
> for the unnecessarily polarizing name.

Exactly; for all practical purposes the LSB project is producing an ABI
standard for Posix on x86-compatible CPUs, and has almost nothing to do
with the Linux kernel.  This is not the old GNU/Linux fight; you're also
short-changing the BSD world.  The kernel simply isn't that relevant for an
application portability standard.  Because LSB has worked this way, many
of us have not paid much attention: GCC is a multi-platform compiler, it
is not the "Linux compiler".

All that said, I will offer my personal, non-official opinion:

the LSB C++ standard as proposed seems to be falling between two stools:
3.2.x-based systems are widely deployed at the moment; 3.4-based
distributions are now coming out, and it seems that LSB wants to
standardize on a not-yet-existing 3.3.5, which Gaby is being asked to
produce based on LSB specifications (a sensitive topic in itself, as the
FSF may object).  Unfortunately, there have been problems with the C++ ABI
standard: both errors in the standard itself, and bugs in GCC that mean we
did not correctly implement the standard.  I am particularly troubled
because it means that LSB will be locking in the last version of GCC
before we fixed the C++ parser, meaning that the old parser will have to
be maintained indefinitely.



More information about the Libstdc++ mailing list