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
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.
> > It's time the LSB stops being a vendor lapdog and remembers that its
> > purpose is to standardise things in agreement with the community.
>
> 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. 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.
> Yeah, I think we'll all prefer to wait but there are other (mostly
> non-technical) constraints.
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.
> 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 ?
> 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.
I would rather win the small war than lose the large one.
> So these non-technical constraints are increasing the pressure to release.
> One can argue if they are really worth not waiting for an ideal solution.
Pressure to release but not pressure to release C++. It is most
definitely cutting losses.
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.
> So given the constraints does anyone have an alternative plan? What would
> it look like?
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..."
Alan