This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Lsb-wg] opposition to LSB 2.0 rc1


People are starting to make assumptions about the intent and action of
the LSB, which is unfair because it begins to spread FUD without being
based on any facts. I'd like to try to clarify some of this.


* The LSB created the spec in a vaccum:

We have had GCC developers at our face to face meetings, and on some of
our weekly phone calls. We have asked the GCC/C++ community for comments &
feedback on both the specification, and on the code we use for testing
the C++ ABI. We received no comments when we asked for a review.
Normally, silence is intepreted as consent.

We submitted a patch to gcc months ago to expose the additional symbols
we thought should have been visible. This went into 3.4 then, and into
3.3 recently. Again, these action could be intepreted as consent.

I would have liked to have had a more active dialog with the gcc
developers. Do I feel we had a good dialog during the development of
LSB 2.0, no, not really, but we made an effort.

I'll agree that we could have done a whole lot better, but to imply we
didn't even try is false.



* The purpose of LSB 2.0 is to define the final C++ ABI:

The purpose of LSB 2.0 is to define a stable set of interfaces upon
which applications can be developed and deployed today. We know it's not
the final ABI for C++. That's why it's versioned. The lifespan of LSB
2.0 is expected to be about 2 years (with LSB 3.0 overlapping at the
end of that time).

Even though the C++ ABI is not completely perfect, we do think it is good
enough to support applications, and that we have the ability to measure
things to the point of having a good comfort level that if a distro passes
the test suite, an application should run OK.  We know there is a small
chance of something going wrong, but still, we think an application
built to run on the LSB will have a buch better chance of working
correctly on LSB certified distros than one which is just built to a
random choice of C++.

LSB 2.0 is not intended to be the final C++ ABI. It is an ABI which is
usable today, with a migration plan to getting to a better ABI in the
future.


* The LSB was clueless in choosing 3.3:

3.3. was chosen because it meets the needs outlined above. Also, as
recently as April, we were told by a FSF developer that given the
current state of things, 3.3 was in fact the best choice.


* Distros will be shipping 3.4 in 3-4 months:

We surveyed distributions just a couple of weeks ago, and the timeframe we
were given for shipping 3.4 releases is 9-18 months, not 3-4 months.
Given the goal of LSB 2.0, we think it is too early to be specifyig 3.4, but
that doing 3.4 a year from now makes sense.


* C++ 3.3 is broken and useless:

It has been implied that 3.3 is broken and useless. There seems to be a
lot of C++ code that is working on the 3.3 based distribtuions. While
3.3 may not be perfect, and it doesn't match whatever the final ABI will
be, it does seem to be be working well enough to support applications
today.

Implying that it is broken and unusable is false. Stating that it
doesn't match what the final ABI will be at some point in the future
is accurate.


* The purpose of the ISO submission is to cast a bad ABI into even more
  permanent ISO stone:

The purpose of the ISO PAS submittion, is to add legitimacy to Linux.
There are groups of potential Linux users that are prohibited from
considering Linux becasue it doesn't have an ISO stamp on it. Submitting
the LSB to ISO will close this gap.

If people are concerned that making the C++ ABI a part of ISO will cast
it too deeply in stone, please say so.

While the goals of LSB 2.0 and the ISO submission overlap a great deal,
they are not the same. The LSB goal is to provide practical solutions
that meet ISVs needs today, while the goal of the ISO submission is to
have Linux formally recognized so that it can be considered for use by a
larger group of people.

LSB 2.0 needs to have C++ in it to satisfy the requirments we have been
hearing from ISVs. ISO LSB may not need C++ in it to satisfy its
requirments. I would be happy to consider submitting a version of the
LSB that does not have C++ to ISO. Our new modular structure facilitates
being able to do this now.


* It took 2 years to get LSB 2.0, so it will take another 2 years for 3.0:

It took us a long time to get 2.0 out. Some of this was that it took us
a while to figure out how to specify C++, and to add some additional
framework to our data handling infrastructure, test tools, etc. Some of
the delay was caused by the lack of feedback we received, and some of it
was casued by a mis-coordination between the subgroups in the LSB, which
delayed the availability of the test suites.

While it is possible that things could occur again to cause delays,
overall, we should be able to reuse most of the work done for 2.0, and
be able to produce LSB 3.0, aligned with C++ 3.4 in a much more
predictable timeframe.


* Requiring patches beyond the 3.3.4 release is not acceptable:

There are at least 3 distributions that have already used the LSB patch
on the 3.3 branch. In practice, this doesn't seem to be a problem. With
the recent trend of projects no longer making tagged releases, it calls
into question wether this should be a hard requirment, or just a desired
goal.

Having any changes reviewed and accepted upstream is certainly a
hard requirment. Wether or not a new tagged release has been made on a
stable branch, doesn't seem to be as hard of a requirment for the
distros.


I hope these comments will help clear up some confusions, without adding
more that it removes 8-).



                                Stuart

anderson@freestandards.org                             Free Standards Group
Lead Developer, Written Specification                  Linux Standard Base
1024D/37A79149:                                        0791 D3B8 9A4C 2CDC A31F
                                                       BD03 0A62 E534 37A7 9149


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]