Red Hat/Fedora va faire l'impasse sur LSB 2.0 car il faut gcc 3.3.5 et Red Hat/Fedora est passé à gcc 3.4 (FC3 et futur RHEL4. RHEL 3 utilise gcc 3.2).
Pour info, Fedora n'est pas certifiée. Il y a le paquet redhat-lsb-1.3 mais la distribution ne subit pas la certification (quelle pourrait peut-être passer, j'en sais rien).
opposition to LSB 2.0 rc1
The LSB 2.0 spec is likely to be announced at LW next week. This is
the first update of LSB in two years, and for the first time includes
a specification for the following libraries: C++, X11, Xext, Xt, GL,
ncurses, and some others.
It is believed that all parts of this spec, with the exception of C++, to be
noncontroversial and adoptable by most current and pending linux
distributions.
The C++ specification is problematic, for several reasons.
1) LSB C++ ABI specification is inadequate and ill-formed.
Attempting to qualify the C++ binary interface on linux solely by
details of the C++ runtime library, without also detailing
requirements of the underlying compiler, is insufficient. As a
result the standard may have a fundamental and fatal flaw. Namely,
that two incompatible C++ implementations, which have the same C++
runtime library characteristics, are deemed compatible.
2) LSB C++ specification enshrines non-current, inferior technology.
The draft LSB spec implies C++ support implemented by a future
release of the gcc 3.3 compiler. As of today, the last gcc
release in this series (gcc-3.3.4) cannot meet the LSB
specification, although future releases (gcc-3.3.5) may.
However, the current FSF release of gcc is gcc-3.4.1, which is
incompatible with the older release series. This release provides
substantial benefits to users, including increased compiler and
runtime performance, increased conformance to C99 and C++
standards, and innovative new features.
In addition, the gcc developers have been working with other
members of the C++ community, and as such gcc-3.4.x provides
increased compiler and runtime compatibility with other vendor
solutions.
3) LSB C++ specification is not multi-vendor.
The draft LSB spec privileges linux distributions that are based
on gcc-3.3. For distributions using gcc-3.2, conforming to LSB will
require the addition of a duplicate yet incompatible system
library, with the same name, same SONAME, and different path. This
is problematic from an architectural standpoint, and may introduce
unsupportable configurations. This may be considered a port of
Microsoft's "DLL hell" to linux.
In response, this LSB has advocated the use of dynamic loader
tricks to solve this issue. A separate dynamic linker with special,
LSB-only properties would purportedly solve the problem. Especially
concerning are non-trivial, real-world cases, where applications
need more runtime support than the subset of libraries standardized
in the LSB specification. These libraries will drag in their own
dependencies on the C++ ABI. The LSB working group has repeatedly
been pointed to this problem; the problem has been ignored since
there are no dependencies of any other standardized library on
libstdc++. Conforming with the LSB specification just for the sake
of passing the LSB test suite while ignoring the compatibility
issues lingering in the shadows is not advisable.
These objections have been explained to the LSB, and their response
has not been satisfactory, although this effort is ongoing. Proposals
to drop the C++ parts of the LSB 2.0 specification were specifically
voted down.
It's time the LSB stops being a vendor lapdog and remembers that its
purpose is to standardise things in agreement with the community. No
agreement, no standard. Its hard but its the long term win. For all the
talk of LSB 3 and fixing it, with no help from the community the current
spec seeks to override there will be no LSB 3 because the community will
have to do its standardisation without the LSB so that it can get
technically sound results.
> 2.) The ISO PAS submission needs to happen before October.
The ISO PAS cannot pass when ISO members are being told by the people
who write the code that the LSB 2.0 is broken. Certainly at the moment
I'd advise the UK ISO people to take a "wait and see" attitude and not
move until the matter is resolved, otherwise they end up rubberstamping
a dead duck, and thats not good for anyone.
I would rather win the small war than lose the large one.
Si je dis que c'est Red Hat, ce n'est pas pour rien. Il semble (car en fait, j'en sais rien :-)) que SuSE/Novell a gcc 3.3 dans sa dernière version "entreprise" alors que Red Hat ne l'a pas dans ses précédentes et futurs versions "entreprise". Bref, l'avis des employés Red Hat est peut-être "biaisé". Néanmoins cet avis semble largement partagé.
Ce n'est pas bien grave, puisqu'il y aura une LSB 3.0 ou 2.1.
Suivre le thread car c'est assez animé et "passionnant".
Mais il faut expérer que ça ne va pas couper Linux en deux. Pour un standard, ce serait un peu con.
La situation actuelle :
Les pas LSB 2.0 et ne le seront sans doute jamais :
Red Hat = gcc 3.2 et gcc 3.4.2
Mandrake = gcc 3.4
Les LSB 2.0 ou potentiellement LSB 2.0 :
SuSE/Novell = gcc 3.3.4 (il me semble pour les versions "entreprise") + patch vers 3.3.5 qui n'existe pas encore.
Debian Sarge = gcc 3.3.x :-)
# LSB 2.0
Posté par 007 . En réponse à la dépêche Sorties de SUSE LINUX 9.2 Live Eval/Professional et Novell Linux Desktop 9. Évalué à 5.
http://www.opengroup.org/lsb/cert/cert_prodlist.tpl?CALLER=index.tp(...)
Le certificat :
http://www.opengroup.org/lsb/cert/display_product.tpl?CALLER=cert_p(...)
Mi juillet, Theodore Ts'o n'était pas d'accord pour avoir C++ dans LSB 2.0 :
http://mail.freestandards.org/pipermail/lsb-wg/2004-July/000233.htm(...)
Red Hat/Fedora va faire l'impasse sur LSB 2.0 car il faut gcc 3.3.5 et Red Hat/Fedora est passé à gcc 3.4 (FC3 et futur RHEL4. RHEL 3 utilise gcc 3.2).
Pour info, Fedora n'est pas certifiée. Il y a le paquet redhat-lsb-1.3 mais la distribution ne subit pas la certification (quelle pourrait peut-être passer, j'en sais rien).
D'ailleurs Red Hat n'est pas du tout "content" avec LSB 2.0. Fin juillet, un mail de Benjamin Kosnik et Ulrich Drepper(Red Hat) :
http://gcc.gnu.org/ml/gcc/2004-07/msg01337.html(...)
opposition to LSB 2.0 rc1
The LSB 2.0 spec is likely to be announced at LW next week. This is
the first update of LSB in two years, and for the first time includes
a specification for the following libraries: C++, X11, Xext, Xt, GL,
ncurses, and some others.
The draft spec is here:
http://www.linuxbase.org/spec/booksets/LSB-Core/LSB-Core.html(...)
http://www.linuxbase.org/spec/booksets/LSB-Core-IA32/LSB-Core-IA32.(...)
It is believed that all parts of this spec, with the exception of C++, to be
noncontroversial and adoptable by most current and pending linux
distributions.
The C++ specification is problematic, for several reasons.
1) LSB C++ ABI specification is inadequate and ill-formed.
Attempting to qualify the C++ binary interface on linux solely by
details of the C++ runtime library, without also detailing
requirements of the underlying compiler, is insufficient. As a
result the standard may have a fundamental and fatal flaw. Namely,
that two incompatible C++ implementations, which have the same C++
runtime library characteristics, are deemed compatible.
2) LSB C++ specification enshrines non-current, inferior technology.
The draft LSB spec implies C++ support implemented by a future
release of the gcc 3.3 compiler. As of today, the last gcc
release in this series (gcc-3.3.4) cannot meet the LSB
specification, although future releases (gcc-3.3.5) may.
However, the current FSF release of gcc is gcc-3.4.1, which is
incompatible with the older release series. This release provides
substantial benefits to users, including increased compiler and
runtime performance, increased conformance to C99 and C++
standards, and innovative new features.
This page has the full details:
http://gcc.gnu.org/gcc-3.4/changes.html(...)
In addition, the gcc developers have been working with other
members of the C++ community, and as such gcc-3.4.x provides
increased compiler and runtime compatibility with other vendor
solutions.
3) LSB C++ specification is not multi-vendor.
The draft LSB spec privileges linux distributions that are based
on gcc-3.3. For distributions using gcc-3.2, conforming to LSB will
require the addition of a duplicate yet incompatible system
library, with the same name, same SONAME, and different path. This
is problematic from an architectural standpoint, and may introduce
unsupportable configurations. This may be considered a port of
Microsoft's "DLL hell" to linux.
In response, this LSB has advocated the use of dynamic loader
tricks to solve this issue. A separate dynamic linker with special,
LSB-only properties would purportedly solve the problem. Especially
concerning are non-trivial, real-world cases, where applications
need more runtime support than the subset of libraries standardized
in the LSB specification. These libraries will drag in their own
dependencies on the C++ ABI. The LSB working group has repeatedly
been pointed to this problem; the problem has been ignored since
there are no dependencies of any other standardized library on
libstdc++. Conforming with the LSB specification just for the sake
of passing the LSB test suite while ignoring the compatibility
issues lingering in the shadows is not advisable.
These objections have been explained to the LSB, and their response
has not been satisfactory, although this effort is ongoing. Proposals
to drop the C++ parts of the LSB 2.0 specification were specifically
voted down.
Signed,
Benjamin Kosnik
Ulrich Drepper
La fin d'une réponse d'Alan Cox (je sais, c'est encore Red Hat) :
http://gcc.gnu.org/ml/gcc/2004-07/msg01346.html(...)
It's time the LSB stops being a vendor lapdog and remembers that its
purpose is to standardise things in agreement with the community. No
agreement, no standard. Its hard but its the long term win. For all the
talk of LSB 3 and fixing it, with no help from the community the current
spec seeks to override there will be no LSB 3 because the community will
have to do its standardisation without the LSB so that it can get
technically sound results.
Et Alan n'est vraiment pas content :
http://gcc.gnu.org/ml/gcc/2004-07/msg01353.html(...)
> 2.) The ISO PAS submission needs to happen before October.
The ISO PAS cannot pass when ISO members are being told by the people
who write the code that the LSB 2.0 is broken. Certainly at the moment
I'd advise the UK ISO people to take a "wait and see" attitude and not
move until the matter is resolved, otherwise they end up rubberstamping
a dead duck, and thats not good for anyone.
I would rather win the small war than lose the large one.
Si je dis que c'est Red Hat, ce n'est pas pour rien. Il semble (car en fait, j'en sais rien :-)) que SuSE/Novell a gcc 3.3 dans sa dernière version "entreprise" alors que Red Hat ne l'a pas dans ses précédentes et futurs versions "entreprise". Bref, l'avis des employés Red Hat est peut-être "biaisé". Néanmoins cet avis semble largement partagé.
Ce n'est pas bien grave, puisqu'il y aura une LSB 3.0 ou 2.1.
Suivre le thread car c'est assez animé et "passionnant".
Mais il faut expérer que ça ne va pas couper Linux en deux. Pour un standard, ce serait un peu con.
La situation actuelle :
Les pas LSB 2.0 et ne le seront sans doute jamais :
Red Hat = gcc 3.2 et gcc 3.4.2
Mandrake = gcc 3.4
Les LSB 2.0 ou potentiellement LSB 2.0 :
SuSE/Novell = gcc 3.3.4 (il me semble pour les versions "entreprise") + patch vers 3.3.5 qui n'existe pas encore.
Debian Sarge = gcc 3.3.x :-)