PSARC 2008/549 Re: Apache Standard C++ Library ARC Case

[John Fischer]

All,

I have updated the case directory with the new proposal
(named proposal_v2.txt).  

Arti,

Can we schedule a slot for next week for a discussion and
vote?

Thanks,

John

On Wed, 2008-10-01 at 23:17, Garrett D'Amore wrote:
> 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/
> 
>