This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Lsb-wg] opposition to LSB 2.0 rc1
Alan Cox writes...
> On Gwe, 2004-07-30 at 01:02, Matt Taggart wrote:
> > The spec is based on 3.3. Do you know of problems where they don't match?
> > Most of the runtime implementations are using 3.3.4 in their current
> > shipping releases.
>
> Which does not match the ABI. The 3.3.5 to be branch has accepted some
> patches that mean a final 3.3.5 might be ABI compatible, although
> whether vendors will upgrade from 3.3.4 and break existing 3.3.4
> applications by doing so mid release remains to be seen - although it
> can be answered here.
As pointed out in another message, this is a hazard of a behavioral
standard. We should try to make sure all known ABI issues are addressed,
but problems will happen.
> > On the contrary, the LSB is attempting to reach consensus among the LSB
> > runtime implementors (commercial and non-commercial). When existing LSB
> > implementors were polled about this particular issue, 7 were willing to
> > implement with v5, 1 preferred v6, and one had no opinion. It is thought
> > that all could technically implement v5.
>
> The LSB is supposed to consider both the community and the vendors. The
> vendors have a current position and its clear that the vendor position
> is v5.
As I pointed out above it's both commercial and non-commercial
implementors. Of particular interest is Debian since the in development
sarge release is 3.3 based and will probably not ship with 3.4 available.
You are probably referring to the IHVs as well and of course they want to
see wider adoption of Linux so they can sell more hardware.
> The glibc and g++ development world apparently prefers v6. They
> don't go away by not being "runtime implementors" or not having votes
> that count in the LSB.
Agreed.
> I'm not aware the LSB has a mandate to play politics on behalf of the
> open source community other than perhaps the vendors. I'm sceptical as
> to whether it even has a vendor mandate to play politics.
Agreed. I do believe the LSB has a mandate to build consensus and document
existing standards though.
> > 1.) As part of the LSB application program nearly every ISV/developer
> > that's been contacted has said that c++ is a requirement and won't look at
> > the LSB/Linux until c++ is included. A lot of these ISVs are proprietary,
>
> And will they look when the library and compiler maintainers say "Oh
> that, no its broken, we know, its historical, we told the LSB not to use
> it". Will they be impressed by the LSB process ?
We can't proceed without upstream support, that's why that LSB criteria
exists.
> > 2.) The ISO PAS submission needs to happen before October.
>
> The ISO PAS cannot pass when ISO members are being told by the people
> who write the code that the LSB 2.0 is broken. Certainly at the moment
> I'd advise the UK ISO people to take a "wait and see" attitude and not
> move until the matter is resolved, otherwise they end up rubberstamping
> a dead duck, and thats not good for anyone.
Noted.
> Rewording the C++ part as a migration reference of some sort might work
> as I know vendors really don't want to lose it. I know it won't make the
> vendor who voted against any happier but at least making it clear that
> the C++ stuff is broken, we know its broken and it'll be obsoleted ASAP
> would set the right expectations all around.
We've proposed that idea to the people who are asking for c++ and they said
until they can be sure that it will be available everywhere, they're not
interested. As far as giving the developers a way to start working, there
was a 1.9 preview release and you can always point at the cvs version of
the spec.
> I'd like to know exactly where the C++ ABI community people draw their
> lines. "I oppose" is the easier bit, now what is the "but I would
> accept..."
Yes, that's a good question.
Thanks,
--
Matt Taggart Linux and Open Source Lab
taggart@fc.hp.com Hewlett-Packard