PSARC 2008/549 Re: Apache Standard C++ Library ARC Case
Aarti Pai
Aarti.Pai at sun.com
Thu Oct 2 15:00:55 PDT 2008
This case is on the agenda for next week.
10/08/2008
10:00-10:10 Open ARC Business
10:10-10:30 -Discussion/Vote: Apache Standard C++ Library (2008/549)
Submitter: Stefan Teleman
Owner: Garrett D'Amore
Status: waiting need spec
10:30-10:45 -Discussion: Meeting-less full case reviews
Aarti
On 10/02/08 09:57, John Fischer wrote:
> 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/
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081002/1e6b6a93/attachment.html>
More information about the opensolaris-arc
mailing list