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
Jeffrey A Law writes...
> 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.
OK, thanks for that data. I updated the candidates at
http://www.linuxbase.org/futures/candidates/
> > 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).
I suspect all of the major runtimes are working on it, but it will be many
months until it's widely deployed in releases that developers target.
> 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.
Good point, but to some extent the burden lies on the runtimes to provide a
stable development environment by backporting fixes, while the GCC team
moves on to work on new things.
> 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*.
The LSB provides a built-in safety mechanism for exactly this purpose. All
LSB binaries are built to use a special ld-lsb*.so.* program interpreter.
In the default case this is a symlink to the real PI. But to solve
something like this it could be a special version that uses 3.3 while the
normal ld continues to provide 3.2.
This mechanism needed to be used by several runtimes for LSB 1.3 compliance
and worked well. The LSB figured out early on that trying to get all
runtimes sync'd up at the same time would always have minor issues and that
something like this was going to be needed.
> 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.
OK.
> 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.
This is interesting data, it would be really useful to have counts of where
the developers are. They are the LSB's target audience.
> > 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.
OK.
> 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.
3.4 doesn't yet meet the LSB criteria, it's blocked on deployment by the
runtimes. I believe this is only a matter of time, but waiting for 3.4
would delay the addition of c++ by at least 6 months.
--
Matt Taggart Linux and Open Source Lab
taggart@fc.hp.com Hewlett-Packard