This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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


On Thu, 2004-07-29 at 18:02, Matt Taggart wrote:
> Alan Cox writes...
> 
> > It is not "best practice" as is clear from looking at the glibc/g++
> > team view
> 
> True, compared to v6. It is the best practice when you also take into 
> consideration non-gcc implementations though right? (last I heard, I don't 
> actively track them so maybe someone can chime in here).
Nope, best practice would be GCC 3.4 which has fixes specifically
targeted to improve interoperability with C++ compilers such as ICC
from Intel and which is IMHO likely to be more widely accepted by
ISVs than a GCC 3.3 environment will be.




> Most of the runtime implementations are using 3.3.4 in their current 
> shipping releases.
Depends on precisely how you measure that and I suspect that won't
be true for terribly long.  Fedora for example will move to GCC 3.4
in a few months (Fedora Core 3).


> The v5 ABI is not perfect, but upstream is committed to maintaining the 3.3 
> branch right? This branch has the advantage that it will be the last to use 
> the v5 version.
There is a maintainer for that branch (Gaby) and as long as Gaby
wants to maintain that branch he can/will.  However, I can probably
safely say GCC 3.3 is _not_ the focus of most of the GCC team.  The
reality is GCC 3.3 is already over a year old and the current release
branch is GCC 3.4.



> > 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.
So how would you propose to implement v5 on a system that needs to have
backward compatibility with a GCC 3.2 based environment and the SO names
for the incompatible hacked up LSB GCC 3.3 environment *ARE THE SAME*.



> 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, 
> but not all. Having more applications helps the adoption of Linux and Free 
> Software, having c++ now speeds this up.
I certainly understand the need for bringing on more ISVs; however, I'm
not sure that using a GCC 3.3 based environment is going to help; in
fact it could very well be a step backwards as far as LSB acceptance
is concerned.

The majority of ISVs are using GCC 3.2 environments for products that
are currently shipping or due to ship in the next 3-9 months.  For
products that are further out, most ISVs have already told me they are
planning to target a GCC 3.4 environment.  The number of ISVs who are
currently using a GCC 3.3 environment are planning to use a GCC 3.3
environment are in the small minority.


> So given the constraints does anyone have an alternative plan? What would 
> it look like?
Unsure.  I think the reality is that a GCC 3.3 based environment is a 
mistake -- it's just too far behind the curve.  I don't know if LSB is
in a position to jump forward to GCC 3.4 -- which is where I expect the
sweet spot to be in the near future.

Jeff





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