Stefan Teleman wrote:
> Updated proposal document attached.
Thank you. The document appears fairly comprehensive to me, and if you
can get an explicit agreement from the compiler group to this (they
"have to", because the proposal includes obligations that they must
perform), then I'm happy to accept and vote to approve.
In retrospect, I think this is still out-of-bounds for a fast track, so
"re-railing" the proposal might not be the best thing to do. (It also
seems like there may be opinion matters to publish, as well.)
*But*, if you can get the agreement from the compiler, then I see no
reason why the case couldn't just come for a vote and skip the
inception/commitment review phase.
At this point, I think you should find out when you think you can get
commitment from the compiler group, and then ask Aarti to schedule you a
slot on the ARC agenda.
I'm CC'ing PSARC again, so that the members can see that convergence is
imminent (from my perspective only the compiler group agreement is
required), and to give them an opportunity to voice any concerns about
the points of order, or on the content of the actual case. It also
places this into the mail log for the case, which may be helpful to
future readers.
-- Garrett
Stefan Teleman <stefan.teleman at Sun.COM>
October 1, 2008
PSARC/2008/549
Addendum 1
1. Scope and Intent
This document formalizes the integration and support mechanism
for the Apache Standard C++ Library Version 4.2.1 in Solaris,
based on the discussions already having taken place for this ARC
Case. [0]
The issues addressed in this document are:
1.1. Detailed outline of the Apache Standard C++ Library's
Multibyte Character and Internationalization support.
1.2. Mechanics of integrating the Apache Standard C++ Library
in current versions of Nevada, and in a Solaris 10 Update.
1.3. Mechanics of providing Sun Studio specific command-line
switches for the purpose of transparently enabling inclusion, and
linkage, of the Apache Standard C++ Library for Sun Studio generated
binary objects.
1.4. Defining the responsibility boundaries for the ongoing
inclusion of the current Apache Standard C++ Library, in Nevada,
and in Solaris 10 Updates.
1.5. Recommendations for Solaris developers on the future
directions of the existing libCstd.so.1, STLport4, and the Apache
Standard C++ Library.
2. Internationalization and Multibyte Character Support
2.1. The Apache Standard C++ Library provides multibyte
character support via UTF/UCS encoding, and the wchar_t type.
Conversion between different encodings is achieved via Standard C
Library calls to iconv(3C). Character conversion operations
performed by the Apache Standard C++ Library are transparent
to the application.
2.2. The Apache Standard C++ Library Internationalization
and Message Catalog Support via Standard C Library calls to
catgets(3C). Message Catalogs are managed [ opened and closed ]
via Standard C Library calls to catopen(3C) and catclose(3C).
The Apache Standard C++ Library does not require the application
to make explicit calls to these Standard C Library functions.
Internationalization and Multibyte Character Support is provided
via the Standard C++ Language mechanisms for such facilities.
The Apache Standard C++ Library does not make calls to either
gettext(3C), dgettext(3C), dcgettext(3C), bindtextdomain(3C),
or any of the associated Standard C Library functions.
Programmatic handling of such facilities is purposely delegated
to the application.
The Apache Standard C++ Library provides no explicit facilities
for the storage or run-time discovery of localized message
catalogs. The responsibility for implementing such facilities
is explicitly delegated to the application requiring localization
support. Standard Message Catalog location discovery mechanisms
[ i.e. NLSPATH environment variable ] apply.
3. Proposed course of action
3.1. The SFW Consolidation will integrate Major Version 4
[ currently Version 4.2.1 ] of the Apache Standard C++ Library, in
Nevada, and in a Solaris 10 Update [ the likely candidate is Solaris
10 Update 7 ]. This version of the Apache Standard C++ Library, and
subsequent updates, if any, will be maintained by the DevPro/Compiler
Group, in close cooperation with the SFW Consolidation.
The objects delivered by this integration, and their corresponding
installation paths have been described in PSARC/2008/549 and ancillary
Case Materials.
3.2. The SFW Consolidation will provide pkg-config [ *.pc ]
files for the Apache Standard C++ Library. These files will encode
the correct Sun Studio 12 command-line switches for:
- disabling the inclusion of the existing libCstd.so.1 header
files
- disabling the automatic linking of the existing libCstd.so.1
shared library
- enabling the automatic inclusion of the Apache Standard C++
Library header files
- enabling the automatic linking of the Apache Standard C++
Library [ by implicitly passing -lstdcxx to the link editor ]
Automatic discovery of the correct compiler flags for enabling
the Standard C++ Library in the Sun Studio compilers will be
achieved via simple command-line invocation of the pkg-config
command:
pkg-config --cxxflags stdcxx
pkg-config --ldflags stdcxx
3.3. The SFW Consolidation will provide a default UNIX man
page for the Apache Standard C++ Library [ libstdcxx.3C++ and
a symbolic link to stdcxx.3C++ ]. This man page will detail the
mechanics of disabling the default libCstd.so.1, and enabling the
Apache Standard C++ Library, in Sun Studio 12 and above. The inherent
incompatibility restrictions between different implementations
of the Standard C++ Library, and the consequences of intentionally,
or inadvertently, combining such different implementations into
the same executable address space, will be clearly outlined in this
man page.
3.4. The DevPro/Tools Group will provide integrated command-line
support for the Apache Standard C++ Library starting with Version 12
of the Sun Studio Compilers.
These command-line switches will automatically:
- disable the automatic inclusion of the existing libCstd.so.1
header files
- disable the automatic linkage to the existing libCstd.so.1
shared library
- enable the automatic inclusion of the Apache Standard C++ Library
header files
- enable the automatic linkage to the Apache Standard C++ Library,
by passing -lstdcxx to the link editor
3.5. Prevention of accidental inclusion, or linkage, of
incompatible header files, or shared library objects, will be
enforced by the Compiler, by providing appropriate, disjunctive and
mutually exclusive command-line switches. This document does not
attempt to address the interfaces to be provided for such mutual
exclusion facilities: these considerations are purposely delegated
to a future ARC Case.
4. Future Directions, and Recommendations for Solaris Developers
4.1. With the Integration of the Apache Standard C++ Library,
the facilities provided by the existing STLport4 library have
become incomplete, and redundant. This Integration establishes the
de facto Obsolescence of the STLport4 Standard C++ Library.
It is very strongly recommended that applications which rely on the
STLport4 library migrate to the Apache Standard C++ Library as soon
as possible. In the vast majority of cases, the migration path involves
only a recompilation of the application. The STLport4 Library may be
removed in a future Update Version of Solaris, or in a future release
of Nevada. Prior notification for the removal of the STLport4 Library
will be provided. However, the integration of the Apache Standard C++
Library makes the coexistence of the STLport4 Library highly impractical.
Any new software projects must avoid relying on the STLport4 Library
and must use the Apache Standard C++ Library.
4.2. With the Integration of the Apache Standard C++ Library,
the Solaris C++ Compilation Environment has evolved to a very close
tracking of the ISO/IEC:14882:2003 Standard. It is very strongly
recommended that applications which link against the Solaris
libCstd.so.1 migrate to the Apache Standard C++ Library as soon as
possible. Although there are no current and imminent plans for the
obsolescence, or removal, of the Solaris libCstd.so.1, the Apache
Library's conformance with the C++ Language Standard provides
significant portability and cross-platform maintainability advantages.
It is to be expected that all C++ Software currently delivered by
Solaris, OpenSolaris, or Nevada, will migrate to the Apache Standard
C++ Library. The migration path for existing Solaris C++ Projects
will follow established Sun processes.
4.3. Future versions of OpenSolaris will demonstrate a clear
bias towards the Apache Standard C++ Library. It is highly likely that
in the very near future, OpenSolaris will deliver C++ applications and
shared libraries linked exclusively against the Apache Standard C++
Library.
4.4. The Apache Standard C++ Library is not source, or binary
compatible, with either the STLport4 Library, or with the Solaris
libCstd.so.1 Library. Combining symbols from more than one implementation
of the Standard C++ Library into the same executable address space will
result in severe software malfunctions, including crashes and run-time
failures. It is a software construction error to voluntarily, or
inadvertently, combine symbols from more than one implementation of the
Standard C++ Library, within the same executable address space.
4.5. The contents of this document do not establish ARC Precedent.
5. References
0. PSARC/2008/549 Including The Apache Standard C++ Library
with Solaris
1. The Apache Standard C++ Library http://stdcxx.apache.org/
