[lsb-discuss] Inconsistency between glibc and POSIX fixed
Wichmann, Mats D
mats.d.wichmann at intel.com
Wed Jun 21 14:31:59 PDT 2006
>> Suppose 3.2 allowed both the correct POSIX behavior as well
>as the 3.x
>> legacy behaviour; or suppose we issue waivers so that a distro with
>> the bugfix will be able to get LSB 3.2 certification even though 3.2
>> doesn't allow it --- what's the hit to application portability? Will
>> applications expecting the old 3.1 behavior misbehave horribly if we
>> change or allow the change in the LSB 3.x series? How many
>> applications are there that may be affected by this?
>I don't really like the idea of adding something that breaks
>applications - so understanding the impact will be important.
Since I couldn't attend the F2F I'm less up on the precise issue,
so let's wait for that.
Historically, when a fix goes into glibc it does propagate out
to distros, and if it's classified as pure bugfix (as opposed
to intentional ABI change - yes there's considered to be a
difference there) the symbol version often doesn't even bump.
So the possibilites are that this will make it into distros
anyway. But we don't know that yet. Sorry... lots of speculation
without having all the facts (darn, why is it so tempting to
To Nick's comment:
>Actually, in 3.1 we require the POSIX behavior. But glibc doesn't
>provide it. So, we should be issuing waivers for 3.1, but refusing to
>so for 3.2.
Right. We didn't know there was a difference until the
correct rock was turned over. So this seems like a
plausible course of action. We get unpopular if we take
a course that requires people to carry bugs around because
that's the way it worked in some LSB version... but not
knowing if there's really any application impact...
BTW, It wasn't an LSB testsuite that caught this, it
was the linuxtesting.org work, which is not used for LSB
certification at this point. So I don't believe anybody
has asked for a waiver on this.
More information about the lsb-discuss