This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Lsb-wg] opposition to LSB 2.0 rc1
Benjamin Kosnik writes...
> The specific scenario I'm thinking about is the following. Vendor A uses
> the gcc-3.3.5 release, constructs libstdc++.so.5.0.7. Vendor B uses
> gcc-3.2.3, with a backport of gcc-3.3.5's libstdc++.so.5.0.7. Both
> compilers validate, both compilers can pass the LSB parts for libstdc++.
>
> However, an application using only the LSB-approved and certified
> libstdc++, that invokes any of the known differences between the two
> underlying compilers (see gcc bugzilla, ABI) will behave differently at
> runtime on systems from Vendor A and Vendor B. This is surprising to me!
I think this is a general flaw in behavioural standards and is not specific
to c++. The same case exists today with the existing libraries in the LSB.
The predecessor to LSB was the Linux Development Platform Specification
http://members.freestandards.org/ldps/
This approach specified specific implementations and specific versions of
those implementations. It was dropped in favor of the LSB for several
reasons.
1.) The runtime implementors felt it was too constraining and took away
their flexibility to craft their distro the way they saw fit, and weren't
willing to adopt it.
2.) It was thought to be impossible to get all the runtimes synced up on
those versions at the same time and for long enough to make it an
attractive platform for developers.
3.) By entrenching a particular implementation/version it took away a
really nice feature of Free Software, the ability to fork. It was deemed
that the benefit of the standard was not worth the price of giving up
control to one particular implementation.
So we arrived at a behavioral model. The keys to making this model work,
1.) Attempt to document *all* interfaces that are presented to the
developer, and if the developer shouldn't be using it don't specify it.
2.) Write assertion based tests for all interfaces.
3.) Count on finding problems and being able to fix them in the spec and
test for them. Publish errata to the standard and iteratively improve it
over time.
So it's not perfect, we need to work hard to make it work.
> Um, great. Given the past trajectory of the LSB and LSB standards,
> please excuse me if I remain skeptical of these proposed time lines.
The LSB doesn't create standards, it only documents existing standards
created by the community, so the LSB release schedule is dependent on the
community's schedule. So it's not our fault :)
I'd like to note that c++ was first added as a candidate for consideration
on 2002-04-08. It hasn't been added to an LSB release precisely because it
wasn't ready upstream. I really don't think you want the LSB releasing
things before it makes sense. And yes our skills predicting when a
particular candidate will meet the criteria pretty much suck :)
[ld trick thing]
> Regardless, I believe this is best avoided if at all possible.
Yes, ideally.
> It still sems odd to me that this "pathspace" idea is not qualified in the s
> tandard.
Yes, it should be.
> Some of the ABI issues were only made public recently, as non-FSF
> compiler vendors, working with GCC contributors, worked to ensure
> increased ABI compatibility between gcc-3.4 and these proprietary
> compilers.
And I bet we can expect additional ABI issues to continue to come out in
the future. Unless you think all the bugs have come out? (although I think
people have thought that before with each of the 3.x releases, right?)
> Given these developments, I think the FSG might want to re-think some of
> their previous assumptions. If this means delaying the C++ bits of LSB
> 2.0, then I think that is a step that should be honestly considered.
It may come to that, I think we're just trying to prove to ourselves that
waiting is the best answer.
> It's far better to have no specification than a flawed one.
This probably depends on the amount it's flawed. Will we ever have a
perfect spec, and if so how long is it worth waiting for? I'm mostly
playing devil's advocate here, I want to prove whatever answer we arrive at
is the best one.
Thanks,
--
Matt Taggart Linux and Open Source Lab
taggart@fc.hp.com Hewlett-Packard