From sacadmin Mon Aug 25 13:41:05 2008 Received: from sr1-umpk-16.sfbay.sun.com (sr1-umpk-16.SFBay.Sun.COM [129.145.154.66]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7PKf5la023201; Mon, 25 Aug 2008 13:41:05 -0700 (PDT) Received: from sr1-umpk-16.sfbay.sun.com (localhost [127.0.0.1]) by sr1-umpk-16.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7PKf5rR023862; Mon, 25 Aug 2008 13:41:05 -0700 (PDT) Received: (from johnf@localhost) by sr1-umpk-16.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m7PKf5CY023859; Mon, 25 Aug 2008 13:41:05 -0700 (PDT) Date: Mon, 25 Aug 2008 13:41:05 -0700 (PDT) From: John Fischer Message-Id: <200808252041.m7PKf5CY023859@sr1-umpk-16.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Apache Standard C++ Library [PSARC/2008/549 FastTrack timeout 09/01/2008] Status: RO Content-Length: 565 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Apache Standard C++ Library 1.2. Name of Document Author/Supplier: Author: Stefan Teleman 1.3 Date of This Document: 25 August, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From John.Fischer@Sun.COM Mon Aug 25 13:50:42 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7PKogx7023623 for ; Mon, 25 Aug 2008 13:50:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7PKoTef014211 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 25 Aug 2008 21:50:41 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6600801CKFNF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 13:50:39 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6600083CKEM990@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 13:50:38 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7PKocuF008259 for ; Mon, 25 Aug 2008 20:50:38 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K66006019Z77600@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 14:50:38 -0600 (MDT) Received: from 129.145.154.66 ([129.145.154.66]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K66006IVCKBGGB0@mail-amer.sun.com>; Mon, 25 Aug 2008 14:50:36 -0600 (MDT) Date: Mon, 25 Aug 2008 13:50:35 -0700 From: John Fischer Subject: PSARC/2008/549 - Apache Standard C++ Library Sender: John.Fischer@Sun.COM To: PSARC-ext@Sun.COM Cc: Stefan.Teleman@Sun.COM Reply-to: John.Fischer@Sun.COM Message-id: <1219697434.9503.162.camel@sr1-umpk-16> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: multipart/mixed; boundary="Boundary_(ID_mQO1DTkupenOyZwUjS3jaA)" X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 13479 --Boundary_(ID_mQO1DTkupenOyZwUjS3jaA) Content-type: text/plain; charset=ASCII Content-transfer-encoding: 7BIT All, I am sponsoring this case for Stefan Teleman from the SFW group. The case directory contains this proposal, the ANSI C++ Standard, 2003 Revision and delivered files appendices. I have set the timeout for Monday, September 1st, 2008. This project proposes to deliver the Apache Standard C++ library (libstdcxx.so.4) in a Micro/Patch release of Solaris. The inclusion of the Apache Standard C++ Library in Solaris will enable the adoption, of important developments in the evolution of the C++ Language Standard. Most notably, it will enable the building and inclusion of the Boost Framework. Please note: the Apache/RogueWave Standard C++ Library is not binary compatible with the Sun Standard C++ Library [ libCstd.so.1 ], or with the STLport Standard C++ Library. See the proposal for further details. Thanks, John --Boundary_(ID_mQO1DTkupenOyZwUjS3jaA) Content-type: text/plain; charset=ASCII; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=proposal.txt Including The Apache Standard C++ Library with Solaris Stefan Teleman 24 August 2008 1. Summary and motivation C++ [1] is a generic purpose programming language designed by Bjarne Stroustroup at AT&T Bell Labs in the 1980's. C++ was designed as a "Better C". [0] The C++ Programming Language became an ANSI/ISO Standard in 1998. [1] In 2005, Rogue Wave Software [3] contributed its commercial implementation of the Standard C++ Library to the Apache stdcxx Project, under the Apache License, Version 2.0. [4] This contribution from Rogue Wave makes available to the Open Source Community an implementation of the Standard C++ Library with more than 10 years of real-life, production experience and acceptance. The Apache/RogueWave Standard C++ Library is known to run on at least the following platforms: AIX, HP-UX, Linux, Solaris, FreeBSD, Windows. The goal of the Apache/RogueWave Standard C++ Library is to provide a free and open source implementation of the ISO/IEC 14882:2003 [ C++ Programming Language + Technical Corrigendum 1] Standard. [1] According to the Project's Web Site: "The key features of the stdcxx project at the time of submission include: - Full conformance to the C++ standard - Complete implementation of the localization library independent of the underlying operating system, including a large set of locale definition files, character set description files, and utility programs to process these files and generate locale databases - User control over strict or permissive conformance checking - Thread-safe implementation of strings, iostreams, and locales - Reference counted basic_string implementation using atomic locking with the ability to switch to a non-reference counted implementation - Excellent runtime performance - Optimized for fast compiles and extremely small executable file sizes - Portable to and fully tested on a large set of operating systems, including AIX, HP-UX, Linux, Solaris, Windows, etc. - Portable to most leading commercial as well as open source compilers - Debugging facilities such as safe iterators, precondition and postcondition checking, and the ability to generate stack traces - Fully documented configuration and build infrastructure - Thorough, well-maintained documentation - Ten years of deployment in the world's most critical enterprise systems" A detailed README containing operating system and compiler and operating system specific Platform Notes is available at: http://stdcxx.apache.org/#platforms The inclusion of the Apache Standard C++ Library in Solaris will enable the adoption, of important developments in the evolution of the C++ Language Standard. Most notably, it will enable the building and inclusion of the Boost Framework. [6] Ten libraries from the Boost Framework are already included in the C++ Standards Committee's Technical Report [ TR1 ], as a step towards inclusion in the next version of the C++ Language Standard. [11] Several other Boost libraries are under active consideration for inclusion in Technical Report 2 [ TR2 ]. [12] This Fasttrack proposes the integration of the latest Stable Version of the Apache Standard C++ Library, Version 4.2.1. [5] This Case seeks Micro/Patch release binding. 2. Technical issues 2.1. Key Objects The complete list of all the Objects and Interfaces provided by ISO/IEC 14882:2003 is extremely large [ the printed version of the C++ Language Standard has more than 800 pages ]. [6] For the purposes of this ARC Case, a full and complete PDF document of the ISO/IEC 14882:2003 Standard, detailing all the Interfaces, will be provided as an Addendum in the ARC Case Materials. /usr/include/stdcxx /usr/include/stdcxx/ansi /usr/include/stdcxx/loc /usr/include/stdcxx/sun /usr/include/stdcxx/rw /usr/include/stdcxx/doc /usr/lib/libstdcxx.so.4.2.1 /usr/lib/libstdcxx.so.4 -> /usr/lib/libstdcxx.so.4.2.1 /usr/lib/libstdcxx.so -> /usr/lib/libstdcxx.so.4.2.1 /usr/lib/pkgconfig/stdcxx.pc /usr/lib/${MACH64}/libstdcxx.so.4.2.1 /usr/lib/${MACH64}/libstdcxx.so.4 -> /usr/lib/${MACH64}/libstdcxx.so.4.2.1 /usr/lib/${MACH64}/libstdcxx.so -> /usr/lib/${MACH64}/libstdcxx.so.4.2.1 /usr/lib/${MACH64}/pkgconfig/stdcxx.pc /usr/share/doc/html/stdcxx/ /usr/share/doc/html/stdcxx/index.html /usr/share/doc/html/stdcxx/banner.gif /usr/share/doc/html/stdcxx/rw.css /usr/share/doc/html/stdcxx/rwbanner.css /usr/share/doc/html/stdcxx/stdlibref/ /usr/share/doc/html/stdcxx/stdlibref/*.html /usr/share/doc/html/stdcxx/stdlibug/ /usr/share/doc/html/stdcxx/stdlibug/*.html For the purpose of maintaing brevity of this document, the complete list of the localization and internationalization support objects delivered by the Apache Standard C++ Library is available in the ARC Case Materials directory, Appendix 2. The Apache Standard C++ Library does not deliver any executables. 2.2. C++ ABI Considerations The Apache/RogueWave Standard C++ Library is not binary compatible with the Sun Standard C++ Library [ libCstd.so.1 ], or with the STLport Standard C++ Library. Applications linked against the Sun Standard C++ Library will malfunction at run-time. Combining shared libraries, or executables linked against libCstd.so.1 and libstdcxx.so.1, or linked against other shared libraries which import both libCstd.so.1 and libstdcxx.so, will also result in run-time software malfunctions. Simply put: the Sun libCstd.so.1 and The Apache Standard C++ Library are mutually exclusive. The Sun Studio 12 [ and earlier releases ] C++ Compiler provides a documented way of avoiding the automatic inclusion of the Sun Standard C++ Library header files: -library=no%Cstd passed to the compiler. 2.3. C++ Language Considerations The Apache/RogueWave Standard C++ Library is written in Standard C++. The library compiles correctly with the Sun Studio 12 compilers, in both 32- and 64- bit, on Intel and SPARC ISA's. The Apache Standard C++ Library Project supports the Sun Studio compilers. [2] 2.4. Internationalization The Apache Standard C++ Library provides full support for internationalization and localization through Native Language Support and multibyte [ wchar_t ] character support. The canonical release of stdcxx delivers 196 character maps and NLS support for 166 languages. The full Internationalization support provided by The Apache Standard C++ Library will be included with this Integration. 2.5. Documentation The Apache Standard C++ Library provides a full documentation set in HTML format. This documentation set will be included with the Standard C++ Library Integration. 3. Interfaces 3.1. Interface Stability The Apache Standard C++ Library maintains ABI compatibility within Major Releases. No ABI incompatible changes are to be expected within the boundaries of a Major Standard C++ Library Release. Considering that this Fasttrack proposes the integration of an existing ANSI/ISO/IEC Standard, an overall "Committed" Interface Stability Classification is appropriate, and desirable for this Integration. 3.2. Imported Interfaces The Standard C++ Library imports interfaces from the Standard C Library, the Standard Math Library, and the Sun C++ Runtime Library [ libCrun.so.1 ]. 3.3. Exported Interfaces The Standard C++ Library exports the interfaces mandated by the C++ Language Standard, including Technical Corrigendum 1 [ ISO/IEC 14882:2003 ] [1] [7]. A detailed listing of the Standard C++ Library's exported interfaces will be provided in the Additional Case Materials for this Fasttrack. The canonical distribution of The Apache Standard C++ Library delivers the following Mandatory C++ header files: /usr/include/stdcxx/ansi/cassert /usr/include/stdcxx/ansi/cctype /usr/include/stdcxx/ansi/cerrno /usr/include/stdcxx/ansi/cfloat /usr/include/stdcxx/ansi/ciso646 /usr/include/stdcxx/ansi/climits /usr/include/stdcxx/ansi/clocale /usr/include/stdcxx/ansi/cmath /usr/include/stdcxx/ansi/csetjmp /usr/include/stdcxx/ansi/csignal /usr/include/stdcxx/ansi/cstdarg /usr/include/stdcxx/ansi/cstddef /usr/include/stdcxx/ansi/cstdio /usr/include/stdcxx/ansi/cstdlib /usr/include/stdcxx/ansi/cstring /usr/include/stdcxx/ansi/ctime /usr/include/stdcxx/ansi/cwchar /usr/include/stdcxx/ansi/cwctype /usr/include/stdcxx/tr1/array /usr/include/stdcxx/tr1/cstdint In addition, the Apache Standard C++ Library relies on the availability of three compiler-specific C++ header files: /usr/include/stdcxx/exception /usr/include/stdcxx/new /usr/include/stdcxx/typeinfo The canonical distribution of the Apache Standard C++ Library delivers a complete set of the Mandatory Standard C++ Library header files, along with a complementary set of the Standard C Library header files. The Standard C Library header files delievered by the Library are not 100% compatible with their Solaris equivalents. Therefore, these files will not be delivered with this Integration. For the purposes of this Integration, and for the purpose of maintaining binary compatibility with the Solaris C runtime, and with the Sun Studio Compilers, The Apache Standard C++ Library will be built and integrated with Sun specific Mandatory Standard C++ Library forwarding header files. [9] A complete list of the header files delivered by the Standard C++ Library is available in the ARC Case Materials directory, in Appendix 1. [4]. Programmatic Facilities Compiling C++ programs with the Apache Standard C++ Library, and without introducing conflicts with the default Sun Standard C++ Library, can be easily achieved by passing specific include directories, and options, to the Sun Studio compiler: 4.1. Include files: -I/usr/include/stdcxx/ansi -I/usr/include/stdcxx/tr1 -I/usr/include/stdcxx 4.2. Libraries: -lstdcxx 4.3. Binding SONAME: The Apache Standard C++ Library will have a binding SONAME of libstdcxx.so.4. [4]. References [0] http://www.research.att.com/~bs/C++.html [1] http://www.open-std.org/jtc1/sc22/wg21/ [2] http://stdcxx.apache.org/ [3] http://www.roguewave.com/ [4] http://www.apache.org/licenses/LICENSE-2.0 [5] http://incubator.apache.org/stdcxx/download.html [6] http://www.boost.org/ [7] http://www.amazon.com/C%2B%2B-Standard-Incorporating-Technical-Corrigendum/dp/0470846747/ref=pd_bbs_1?ie=UTF8&s=books&qid=1197413379&sr=1-1 [8] PSARC/1999/192 http://www.opensolaris.org/os/community/arc/caselog/1999/ [9] Sun C++ ABI 5.0: LSARC/1994/323 LSARC/1997/150 LSARC/2000/211 et. seq. [10] PSARC/2002/348 http://www.opensolaris.org/os/community/arc/caselog/2002/ [11] http://open-std.org/jtc1/sc22/wg21/docs/library_technical_report.html http://en.wikipedia.org/wiki/Technical_Report_1 [12] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2122.htm --Boundary_(ID_mQO1DTkupenOyZwUjS3jaA)-- From gdamore@sun.com Mon Aug 25 15:08:56 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7PM8u7H025770 for ; Mon, 25 Aug 2008 15:08:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7PM8tkT018504 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 25 Aug 2008 15:08:56 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6600305G6UXG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 16:08:54 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6600IQKG6TWA60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 16:08:53 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7PM8rqs006721 for ; Mon, 25 Aug 2008 15:08:53 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6600D01FSYLU00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 15:08:53 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K66001X1G6SQW00@fe-sfbay-09.sun.com>; Mon, 25 Aug 2008 15:08:53 -0700 (PDT) Date: Mon, 25 Aug 2008 15:02:13 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <1219697434.9503.162.camel@sr1-umpk-16> Sender: Garrett.Damore@sun.com To: John.Fischer@sun.com Cc: PSARC-ext@sun.com, Stefan.Teleman@sun.com Message-id: <48B32BE5.7030506@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3755 So the questions/concerns I have about this are: 1) Is there any long term plan for rectifying the differences between Studio-supplied Standard C++ libraries and this version? 2) It seems like we (Sun and OpenSolaris both) ought to be putting our weight behind *one* of the implementations. If the Apache version is the best version (I gather that the Studio supplied libraries are somehow deficient, but I don't understand why), then perhaps its time we take a look at a general move to mark the Sun stuff Obsolete, and direct users towards the newer version. 3) Given the rotten ABI incompatibilities that exist already in C++, one could argue that precedent has been set. However, I feel that making this problem worse by adding yet another system-supplied and-incompatible C++ library is asking for severe trouble. Without some long term plan to consolidate on (and recommend) a single ABI, developers are left confused as to which they should be using. 4) If you have an application that needs to bring in libraries from multiple sources, each of which were built against different C++ standard libraries, you wind up with a situation where the binary can't work. And, its not clear to me that the poor developer stuck here trying to use one set of libraries linked against Apache's code, and another against Studio's, has a way to know that a problem is lurking, much less a way to avoid or solve it. 5) Yes, I know that this problem already exists with Gnu C++ versus Studio compiler ABI incompatibilities. However, I'm strongly opposed seeing this problem increased by another degree of freedom if we can avoid it. 6) The failure mode if mislinked programs (random application misbehavior) makes me very unhappy. I'd far rather have a failure occur at compile or at least at link time. I consider these compatibility concerns rather grave. Grave enough that I'm *very* uncomfortable that this meets the "obviousness" (or "uncontroversial") test required for a fast track. I think it should be derailed, so that a broader plan around C++ API/ABIs can be arrived at. HOWEVER, as I'm still on sabbatical, I don't think its fair for me to derail it. But I *really* hope that someone else on the committee will do so. (Project team, note that I'm specifically *not* trying to prevent integration of Apache libstdc++ -- rather I want to see a plan evolve where we can figure out how to arrive at a reasonable predictable and modern C++ library that doesn't leave developers in a complete bewilderment about how to build their applications. It may be that the quasi-major binding status of OpenSolaris gives us an opportunity here to consolidate on the Apache libstdc++, although I'm not sure whether that horse might already have left the barn with the OpenSolaris 2008.05 release.) -- Garrett John Fischer wrote: > All, > > I am sponsoring this case for Stefan Teleman from the SFW > group. The case directory contains this proposal, the ANSI > C++ Standard, 2003 Revision and delivered files appendices. > I have set the timeout for Monday, September 1st, 2008. > > This project proposes to deliver the Apache Standard C++ > library (libstdcxx.so.4) in a Micro/Patch release of > Solaris. The inclusion of the Apache Standard C++ Library > in Solaris will enable the adoption, of important developments > in the evolution of the C++ Language Standard. Most notably, > it will enable the building and inclusion of the Boost Framework. > Please note: the Apache/RogueWave Standard C++ Library is not > binary compatible with the Sun Standard C++ Library > [ libCstd.so.1 ], or with the STLport Standard C++ Library. > See the proposal for further details. > > Thanks, > > John > > From Stefan.Teleman@sun.com Mon Aug 25 16:16:31 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7PNGUAk027451 for ; Mon, 25 Aug 2008 16:16:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7PNGPAR027624; Tue, 26 Aug 2008 07:16:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6600F0BJBEAU00@nwk-avmta-2.sfbay.sun.com>; Mon, 25 Aug 2008 16:16:26 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6600FA1JBE2W00@nwk-avmta-2.sfbay.sun.com>; Mon, 25 Aug 2008 16:16:26 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7PNGP25008105; Mon, 25 Aug 2008 16:16:25 -0700 (PDT) Date: Mon, 25 Aug 2008 19:16:24 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B32BE5.7030506@sun.com> To: "Garrett D'Amore" Cc: John.Fischer@sun.com, PSARC-ext@sun.com Reply-to: Stefan Teleman Message-id: <48B33D48.5090202@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 5612 Garrett D'Amore wrote: > So the questions/concerns I have about this are: > > 1) Is there any long term plan for rectifying the differences between > Studio-supplied Standard C++ libraries and this version? These differences cannot be rectified, due to the backwards API compatibility constraints of the existing libCstd.so.1. In other words, the existing libCstd.so.1 is frozen in time. It is currently not Standard C++ Compliant, and has been so for 10 years. This means: any Sun customer developing Standard Compliant C++ software (meaning: wanting to use Standard Language features unavailable in libCstd.so.1) will either: 1. Not use Sun Studio. 2. Not use Solaris. > 2) It seems like we (Sun and OpenSolaris both) ought to be putting our > weight behind *one* of the implementations. As explained above, we cannot do that, unless we want to remain Standard C++ non-compliant forever. > If the Apache version is the best version (I gather that the Studio supplied libraries are > somehow deficient, but I don't understand why), libCstd.so.l must maintain compatibility with Sun Workshop 5. At the time Workshop 5 was released, the compiler did not implement all the language features mandated by the Standard. The deficiencies were primarily in the compiler support for Partial Template Specializations, std::iterator_traits, etc. Introducing support for these mandatory language features in the current libCstd.so.1 would break compatibility with the existing libCstd.so.1 (for example, because the sizes of some of the existing classes and structs in the Standard C++ Library and STL will change). > then perhaps its time we > take a look at a general move to mark the Sun stuff Obsolete, and direct > users towards the newer version. > > 3) Given the rotten ABI incompatibilities that exist already in C++, one > could argue that precedent has been set. Indeed it has. > However, I feel that making > this problem worse by adding yet another system-supplied > and-incompatible C++ library is asking for severe trouble. Without some > long term plan to consolidate on (and recommend) a single ABI, > developers are left confused as to which they should be using. There appears to be confusion here between the Sun C++ ABI, and the library incompatibility between the existing libCstd.so.1 and the Apache Standard C++ Library. The Sun C++ ABI does not change with the introduction of the Apache library. Actually, the Apache library links against the existing libCrun.so.1, and will conform to the Sun C++ ABI. It is the Library ABI's that are incompatible. C++ developers are well aware of incompatibilities between different implementations of the Standard C++ Library. These incompatibilities exist regardless of the compiler ABI in use. The GNU Standard C++ Library is not compatible with the Apache Standard C++ Library, either, even in the case where both were compiled with the exact same compiler. This library compatibility conflict currently exists today, in Solaris, with the presence of the STLport implementation of the Standard C++ Library. However, the Apache implementation of the Standard C++ Library is far superior to STLport (if for no other reason other than full internationalization support in Apache, which is absent in STLport). And even if it wasn't superior, STLport is still incompatible with libCstd.so.1 as well. > 4) If you have an application that needs to bring in libraries from > multiple sources, each of which were built against different C++ > standard libraries, you wind up with a situation where the binary can't > work. And, its not clear to me that the poor developer stuck here > trying to use one set of libraries linked against Apache's code, and > another against Studio's, has a way to know that a problem is lurking, > much less a way to avoid or solve it. Standards Compliance trumps potential (although not really possible) developer confusion. > 5) Yes, I know that this problem already exists with Gnu C++ versus > Studio compiler ABI incompatibilities. However, I'm strongly opposed > seeing this problem increased by another degree of freedom if we can > avoid it. This is not a degree or measure of freedom, this is a matter of becoming compliant with an Industry Standard which was adopted 10 years ago, and which is supported by all our competitors (I am deliberately not including GCC in this statement, since GCC does not observe the same compatibility constraints to the same degree to which the IBM, HP and Microsoft compilers do). This lack of compliance prevents us from introducing other C++ components (read: BOOST) which are currently widely used in the industry, and by our customers. > 6) The failure mode if mislinked programs (random application > misbehavior) makes me very unhappy. I'd far rather have a failure occur > at compile or at least at link time. And that is exactly where the vast majority errors will occur. The case of "random application misbehavior" simply does not exist when linking against conflicting Standard C++ Libraries. The application simply crashes on startup, if it manages to link, and if the link editor did not already cause fatal errors because of either undefined or multiply-defined symbols. > I consider these compatibility concerns rather grave. Any C++ software developers worth their title knows that "Thou Shalt Not Mix Different Implementations Of The Standard C++ Library." This is not a language bug, it is a language feature. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gdamore@sun.com Mon Aug 25 16:51:14 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7PNpEYT029336 for ; Mon, 25 Aug 2008 16:51:14 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7PNpDJh002070 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 25 Aug 2008 16:51:13 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6600BDPKXD7S00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 17:51:13 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6600IZ9KUSW6E0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 17:49:40 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7PNne2p023883 for ; Mon, 25 Aug 2008 16:49:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6600701KPEQ600@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 16:49:40 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6600GNSKUR0O50@fe-sfbay-10.sun.com>; Mon, 25 Aug 2008 16:49:40 -0700 (PDT) Date: Mon, 25 Aug 2008 16:43:00 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B33D48.5090202@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B34384.4020501@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 9495 Stefan Teleman wrote: > > > Garrett D'Amore wrote: >> So the questions/concerns I have about this are: >> >> 1) Is there any long term plan for rectifying the differences between >> Studio-supplied Standard C++ libraries and this version? > > These differences cannot be rectified, due to the backwards API > compatibility constraints of the existing libCstd.so.1. In other > words, the existing libCstd.so.1 is frozen in time. It is currently > not Standard C++ Compliant, and has been so for 10 years. This means: > any Sun customer developing Standard Compliant C++ software (meaning: > wanting to use Standard Language features unavailable in libCstd.so.1) > will either: > > 1. Not use Sun Studio. > 2. Not use Solaris. Seems like coordination with the compiler folks is in order here. More below. > >> 2) It seems like we (Sun and OpenSolaris both) ought to be putting >> our weight behind *one* of the implementations. > > As explained above, we cannot do that, unless we want to remain > Standard C++ non-compliant forever. Not true. It may be true that the existing libCstd.so.1 is not adequate to the task. But then we ought to either start encouraging folks to use some thing else (e.g. this project) -- and mark the legacy API/ABI Obsolete (possibly with an EOF notice as well!), or enhance the existing library (not sure if that is even possible.) We aren't stuck in time. I'm not saying we shouldn't ship t Apache Standard C++ (I'm not prepared to make value judgments of one library versus another -- I abhor C++ and haven't used it seriously for ~10 years).... I'm saying that we need a *plan* for what we are going to do going forward -- there should be a single default system C++ library that is good enough for everyone except folks with particular backwards compatibility concerns. > >> If the Apache version is the best version (I gather that the Studio >> supplied libraries are somehow deficient, but I don't understand why), > > libCstd.so.l must maintain compatibility with Sun Workshop 5. At the > time Workshop 5 was released, the compiler did not implement all the > language features mandated by the Standard. The deficiencies were > primarily in the compiler support for Partial Template > Specializations, std::iterator_traits, etc. > > Introducing support for these mandatory language features in the > current libCstd.so.1 would break compatibility with the existing > libCstd.so.1 (for example, because the sizes of some of the existing > classes and structs in the Standard C++ Library and STL will change). I see. So, then perhaps we should *strongly* encourage folks to move away from the legacy library, if that's we want to do. (Part of this can happen by coordination with the compiler folks to get them to adopt a new standard library, possibly making the old library available only with extra options.) At the end of the day, I'd like to have the situation where the default compiler flags build code that Just Works, and have that code support the standards. > >> then perhaps its time we take a look at a general move to mark the >> Sun stuff Obsolete, and direct users towards the newer version. >> >> 3) Given the rotten ABI incompatibilities that exist already in C++, >> one could argue that precedent has been set. > > Indeed it has. > >> However, I feel that making this problem worse by adding yet another >> system-supplied and-incompatible C++ library is asking for severe >> trouble. Without some long term plan to consolidate on (and >> recommend) a single ABI, developers are left confused as to which >> they should be using. > > There appears to be confusion here between the Sun C++ ABI, and the > library incompatibility between the existing libCstd.so.1 and the > Apache Standard C++ Library. The Sun C++ ABI does not change with the > introduction of the Apache library. Actually, the Apache library links > against the existing libCrun.so.1, and will conform to the Sun C++ > ABI. It is the Library ABI's that are incompatible. Actually, ABI can *also* refer to the interface between linked modules -- i.e. binary compatibility. I.e. there is a more general notion of an ABI than just what the compiler emits. > > C++ developers are well aware of incompatibilities between different > implementations of the Standard C++ Library. These incompatibilities > exist regardless of the compiler ABI in use. The GNU Standard C++ > Library is not compatible with the Apache Standard C++ Library, > either, even in the case where both were compiled with the exact same > compiler. > > This library compatibility conflict currently exists today, in > Solaris, with the presence of the STLport implementation of the > Standard C++ Library. However, the Apache implementation of the > Standard C++ Library is far superior to STLport (if for no other > reason other than full internationalization support in Apache, which > is absent in STLport). And even if it wasn't superior, STLport is > still incompatible with libCstd.so.1 as well. Pity the poor noob C++ programmer that has to figure out the link dependencies! Or the poor admin who downloaded some sources from the 'net and can't seem to make them compile properly, because he can't resolve library incompatibility issues. Just because the problem exists today does not mean we should make it worse. I firmly believe that We Can Do Better Than That. Some basic planning and engineering work is called for here, IMO. I'm not married to any one of these APIs, and I understand that some incompatibilities will exist during a transition period. But there should be a transition period, at the end of which one can reasonably expect the libraries bundled with the OS (and typically used by most 3rd party libraries as well) to Just Work, with the default compiler flags. I hate the g++ versus Sun C++ ABI incompatibility, and I'm not asking the project team to solve *that* problem. But I am asking that before we ship another incompatible implementation, we have a *plan* for how to make the problem *better* instead of *worse*. (Making it temporarily worse is OK, if in the long run it will be better.) > >> 4) If you have an application that needs to bring in libraries from >> multiple sources, each of which were built against different C++ >> standard libraries, you wind up with a situation where the binary >> can't work. And, its not clear to me that the poor developer stuck >> here trying to use one set of libraries linked against Apache's code, >> and another against Studio's, has a way to know that a problem is >> lurking, much less a way to avoid or solve it. > > Standards Compliance trumps potential (although not really possible) > developer confusion. We can have both, I think. I'm unwilling to believe that we have to live in this current morass forever and ever. > >> 5) Yes, I know that this problem already exists with Gnu C++ versus >> Studio compiler ABI incompatibilities. However, I'm strongly opposed >> seeing this problem increased by another degree of freedom if we can >> avoid it. > > This is not a degree or measure of freedom, this is a matter of > becoming compliant with an Industry Standard which was adopted 10 > years ago, and which is supported by all our competitors (I am > deliberately not including GCC in this statement, since GCC does not > observe the same compatibility constraints to the same degree to which > the IBM, HP and Microsoft compilers do). > > This lack of compliance prevents us from introducing other C++ > components (read: BOOST) which are currently widely used in the > industry, and by our customers. I get it. I'm not advocating *against* integrating Apache libstdc++... I'm asking for a transition plan that gets us to the point where the compilers Just Work, and we don't have to explain to customers which library to use or ask customers to provide a byzantine set of options to override the compilers default headers. I think some collaboration with the compiler group is probably also called for here. > >> 6) The failure mode if mislinked programs (random application >> misbehavior) makes me very unhappy. I'd far rather have a failure >> occur at compile or at least at link time. > > And that is exactly where the vast majority errors will occur. > > The case of "random application misbehavior" simply does not exist > when linking against conflicting Standard C++ Libraries. The > application simply crashes on startup, if it manages to link, and if > the link editor did not already cause fatal errors because of either > undefined or multiply-defined symbols. > >> I consider these compatibility concerns rather grave. > > Any C++ software developers worth their title knows that "Thou Shalt > Not Mix Different Implementations Of The Standard C++ Library." This > is not a language bug, it is a language feature. I think you're placing a lot of credit towards C++ developers. Remember that not everyone that compiles code is a developer! We need a *canonical* Standard C++ library. If ours isn't good enough, then it either needs to evolve so it can become good enough, or we need to transition to a better one (such as Apache's). This is one area where choice is *not* good, it actually makes things far worse than they should be. I I hope someone derails this case. If I weren't on sabbatical I'd be punching the derail button. -- Garrett From John.Fischer@Sun.COM Mon Aug 25 17:16:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7Q0GOjg001033 for ; Mon, 25 Aug 2008 17:16:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7Q0GNHw000709 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 01:16:23 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6600703M3AN800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 17:16:22 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K66002T7M39J1B0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 17:16:22 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7Q0GLBZ023756 for ; Tue, 26 Aug 2008 00:16:21 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6600101M0D4N00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 25 Aug 2008 18:16:21 -0600 (MDT) Received: from 129.145.154.66 ([129.145.154.66]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K66001Z5M38E3F0@mail-amer.sun.com>; Mon, 25 Aug 2008 18:16:21 -0600 (MDT) Date: Mon, 25 Aug 2008 17:16:20 -0700 From: John Fischer Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B34384.4020501@sun.com> Sender: John.Fischer@Sun.COM To: "Garrett D'Amore" Cc: John Fischer , Stefan Teleman , PSARC-ext@Sun.COM Reply-to: John.Fischer@Sun.COM Message-id: <1219709778.9503.178.camel@sr1-umpk-16> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B34384.4020501@sun.com> Status: RO Content-Length: 10151 Garrett, I have contacted someone within the Dev Pro group about this issue. I'll keep PSARC posted. If we do not come up with something before the timeout I'll extend it. Thanks, John On Mon, 2008-08-25 at 16:43, Garrett D'Amore wrote: > Stefan Teleman wrote: > > > > > > Garrett D'Amore wrote: > >> So the questions/concerns I have about this are: > >> > >> 1) Is there any long term plan for rectifying the differences between > >> Studio-supplied Standard C++ libraries and this version? > > > > These differences cannot be rectified, due to the backwards API > > compatibility constraints of the existing libCstd.so.1. In other > > words, the existing libCstd.so.1 is frozen in time. It is currently > > not Standard C++ Compliant, and has been so for 10 years. This means: > > any Sun customer developing Standard Compliant C++ software (meaning: > > wanting to use Standard Language features unavailable in libCstd.so.1) > > will either: > > > > 1. Not use Sun Studio. > > 2. Not use Solaris. > > Seems like coordination with the compiler folks is in order here. More > below. > > > > >> 2) It seems like we (Sun and OpenSolaris both) ought to be putting > >> our weight behind *one* of the implementations. > > > > As explained above, we cannot do that, unless we want to remain > > Standard C++ non-compliant forever. > > Not true. It may be true that the existing libCstd.so.1 is not adequate > to the task. But then we ought to either start encouraging folks to use > some thing else (e.g. this project) -- and mark the legacy API/ABI > Obsolete (possibly with an EOF notice as well!), or enhance the existing > library (not sure if that is even possible.) > > We aren't stuck in time. I'm not saying we shouldn't ship t Apache > Standard C++ (I'm not prepared to make value judgments of one library > versus another -- I abhor C++ and haven't used it seriously for ~10 > years).... I'm saying that we need a *plan* for what we are going to do > going forward -- there should be a single default system C++ library > that is good enough for everyone except folks with particular backwards > compatibility concerns. > > > > >> If the Apache version is the best version (I gather that the Studio > >> supplied libraries are somehow deficient, but I don't understand why), > > > > libCstd.so.l must maintain compatibility with Sun Workshop 5. At the > > time Workshop 5 was released, the compiler did not implement all the > > language features mandated by the Standard. The deficiencies were > > primarily in the compiler support for Partial Template > > Specializations, std::iterator_traits, etc. > > > > Introducing support for these mandatory language features in the > > current libCstd.so.1 would break compatibility with the existing > > libCstd.so.1 (for example, because the sizes of some of the existing > > classes and structs in the Standard C++ Library and STL will change). > > I see. So, then perhaps we should *strongly* encourage folks to move > away from the legacy library, if that's we want to do. (Part of this > can happen by coordination with the compiler folks to get them to adopt > a new standard library, possibly making the old library available only > with extra options.) > > At the end of the day, I'd like to have the situation where the default > compiler flags build code that Just Works, and have that code support > the standards. > > > > >> then perhaps its time we take a look at a general move to mark the > >> Sun stuff Obsolete, and direct users towards the newer version. > >> > >> 3) Given the rotten ABI incompatibilities that exist already in C++, > >> one could argue that precedent has been set. > > > > Indeed it has. > > > >> However, I feel that making this problem worse by adding yet another > >> system-supplied and-incompatible C++ library is asking for severe > >> trouble. Without some long term plan to consolidate on (and > >> recommend) a single ABI, developers are left confused as to which > >> they should be using. > > > > There appears to be confusion here between the Sun C++ ABI, and the > > library incompatibility between the existing libCstd.so.1 and the > > Apache Standard C++ Library. The Sun C++ ABI does not change with the > > introduction of the Apache library. Actually, the Apache library links > > against the existing libCrun.so.1, and will conform to the Sun C++ > > ABI. It is the Library ABI's that are incompatible. > > Actually, ABI can *also* refer to the interface between linked modules > -- i.e. binary compatibility. I.e. there is a more general notion of an > ABI than just what the compiler emits. > > > > > C++ developers are well aware of incompatibilities between different > > implementations of the Standard C++ Library. These incompatibilities > > exist regardless of the compiler ABI in use. The GNU Standard C++ > > Library is not compatible with the Apache Standard C++ Library, > > either, even in the case where both were compiled with the exact same > > compiler. > > > > This library compatibility conflict currently exists today, in > > Solaris, with the presence of the STLport implementation of the > > Standard C++ Library. However, the Apache implementation of the > > Standard C++ Library is far superior to STLport (if for no other > > reason other than full internationalization support in Apache, which > > is absent in STLport). And even if it wasn't superior, STLport is > > still incompatible with libCstd.so.1 as well. > > Pity the poor noob C++ programmer that has to figure out the link > dependencies! Or the poor admin who downloaded some sources from the > 'net and can't seem to make them compile properly, because he can't > resolve library incompatibility issues. > > Just because the problem exists today does not mean we should make it > worse. I firmly believe that We Can Do Better Than That. Some basic > planning and engineering work is called for here, IMO. > > I'm not married to any one of these APIs, and I understand that some > incompatibilities will exist during a transition period. But there > should be a transition period, at the end of which one can reasonably > expect the libraries bundled with the OS (and typically used by most 3rd > party libraries as well) to Just Work, with the default compiler flags. > > I hate the g++ versus Sun C++ ABI incompatibility, and I'm not asking > the project team to solve *that* problem. But I am asking that before > we ship another incompatible implementation, we have a *plan* for how to > make the problem *better* instead of *worse*. (Making it temporarily > worse is OK, if in the long run it will be better.) > > > >> 4) If you have an application that needs to bring in libraries from > >> multiple sources, each of which were built against different C++ > >> standard libraries, you wind up with a situation where the binary > >> can't work. And, its not clear to me that the poor developer stuck > >> here trying to use one set of libraries linked against Apache's code, > >> and another against Studio's, has a way to know that a problem is > >> lurking, much less a way to avoid or solve it. > > > > Standards Compliance trumps potential (although not really possible) > > developer confusion. > > We can have both, I think. I'm unwilling to believe that we have to > live in this current morass forever and ever. > > > > >> 5) Yes, I know that this problem already exists with Gnu C++ versus > >> Studio compiler ABI incompatibilities. However, I'm strongly opposed > >> seeing this problem increased by another degree of freedom if we can > >> avoid it. > > > > This is not a degree or measure of freedom, this is a matter of > > becoming compliant with an Industry Standard which was adopted 10 > > years ago, and which is supported by all our competitors (I am > > deliberately not including GCC in this statement, since GCC does not > > observe the same compatibility constraints to the same degree to which > > the IBM, HP and Microsoft compilers do). > > > > This lack of compliance prevents us from introducing other C++ > > components (read: BOOST) which are currently widely used in the > > industry, and by our customers. > > I get it. I'm not advocating *against* integrating Apache libstdc++... > I'm asking for a transition plan that gets us to the point where the > compilers Just Work, and we don't have to explain to customers which > library to use or ask customers to provide a byzantine set of options to > override the compilers default headers. > > I think some collaboration with the compiler group is probably also > called for here. > > > > >> 6) The failure mode if mislinked programs (random application > >> misbehavior) makes me very unhappy. I'd far rather have a failure > >> occur at compile or at least at link time. > > > > And that is exactly where the vast majority errors will occur. > > > > The case of "random application misbehavior" simply does not exist > > when linking against conflicting Standard C++ Libraries. The > > application simply crashes on startup, if it manages to link, and if > > the link editor did not already cause fatal errors because of either > > undefined or multiply-defined symbols. > > > >> I consider these compatibility concerns rather grave. > > > > Any C++ software developers worth their title knows that "Thou Shalt > > Not Mix Different Implementations Of The Standard C++ Library." This > > is not a language bug, it is a language feature. > > I think you're placing a lot of credit towards C++ developers. Remember > that not everyone that compiles code is a developer! We need a > *canonical* Standard C++ library. If ours isn't good enough, then it > either needs to evolve so it can become good enough, or we need to > transition to a better one (such as Apache's). > > This is one area where choice is *not* good, it actually makes things > far worse than they should be. I > > I hope someone derails this case. If I weren't on sabbatical I'd be > punching the derail button. > > > -- Garrett > From Joerg.Barfurth@sun.com Tue Aug 26 09:58:32 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QGwVT3028830 for ; Tue, 26 Aug 2008 09:58:32 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7QGwRX6000597 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 17:58:31 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6700J05WHIM000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 09:58:30 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6700HAPWHHXB80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 09:58:30 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7QGwTbP005473 for ; Tue, 26 Aug 2008 16:58:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6700101W9H2I00@fe-emea-10.sun.com> (original mail from Joerg.Barfurth@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 17:58:29 +0100 (BST) Received: from [10.16.46.61] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K67007MDWHG4RG0@fe-emea-10.sun.com>; Tue, 26 Aug 2008 17:58:29 +0100 (BST) Date: Tue, 26 Aug 2008 18:58:20 +0200 From: Joerg Barfurth Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B33D48.5090202@Sun.COM> Sender: Joerg.Barfurth@sun.com To: Stefan Teleman Cc: "Garrett D'Amore" , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B4362C.7070604@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 10636 Hi, What I'm going to say really just reiterates the need to coordinate with the compiler group (with which I am not particularly affiliated). But I think I have some more arguments. Stefan Teleman schrieb: > > Garrett D'Amore wrote: >> So the questions/concerns I have about this are: >> >> 1) Is there any long term plan for rectifying the differences between >> Studio-supplied Standard C++ libraries and this version? > > These differences cannot be rectified, due to the backwards API compatibility > constraints of the existing libCstd.so.1. In other words, the existing > libCstd.so.1 is frozen in time. It is currently not Standard C++ Compliant, and > has been so for 10 years. That has been done very consciously. And you can't get away from this for any use case that needs compatibility to the long-standing, stable C++ ABI (e.g. because they need to use libraries that are built against libCstd.so). > This means: any Sun customer developing Standard > Compliant C++ software (meaning: wanting to use Standard Language features > unavailable in libCstd.so.1) will either: > > 1. Not use Sun Studio. > 2. Not use Solaris. > If they don't need ABI compatibility on Solaris, there are existing alternative, in particular use of the STLport shipped with SunStudio. >> 2) It seems like we (Sun and OpenSolaris both) ought to be putting our >> weight behind *one* of the implementations. > > As explained above, we cannot do that, unless we want to remain Standard C++ > non-compliant forever. > Other have already made a strong case that this should be coordinated with the compiler folks. At least there should be agreement whether STLport or stdcxx is the best way forwards. Stepping away from the existing stable C++ ABI towards a new potentially stable ABI would also be a chance to fix any issues (in particular standards conformance issues) that are in the compiler or libCrun and also could not be fixed. This underscores the need for coordinated planning even more. >> If the Apache version is the best version (I gather that the Studio supplied libraries are >> somehow deficient, but I don't understand why), > > libCstd.so.l must maintain compatibility with Sun Workshop 5. At the time > Workshop 5 was released, the compiler did not implement all the language > features mandated by the Standard. The deficiencies were primarily in the > compiler support for Partial Template Specializations, std::iterator_traits, etc. > > Introducing support for these mandatory language features in the current > libCstd.so.1 would break compatibility with the existing libCstd.so.1 (for > example, because the sizes of some of the existing classes and structs in the > Standard C++ Library and STL will change). > >> then perhaps its time we >> take a look at a general move to mark the Sun stuff Obsolete, and direct >> users towards the newer version. >> >> 3) Given the rotten ABI incompatibilities that exist already in C++, one >> could argue that precedent has been set. > > Indeed it has. > BTW, I see that you suggest giving this library a Committed stability classification. This may lead you into the same corner where libCstd currently is caught: - Experience (e.g. the multitude of 'final stable ABI' releases of g++ and its library) shows that it is very difficult to determine that something is perfect enough that future bug fixes won't require more ABI changes. - There will be TR2 and eventually the next version of the Standard. Being 'Committed' may make the hurdle to accomodate these revisions very high. - You can maintain ABI compatibility only as long as the compiler does. If you commit to an ABI now, you may be stuck with being tied to a -compat switch and can't benefit from compiler improvements, if the compiler group eventually makes the step to a 'major release' (i.e. a new compiler ABI). >> However, I feel that making >> this problem worse by adding yet another system-supplied >> and-incompatible C++ library is asking for severe trouble. Without some >> long term plan to consolidate on (and recommend) a single ABI, >> developers are left confused as to which they should be using. > > There appears to be confusion here between the Sun C++ ABI, and the library > incompatibility between the existing libCstd.so.1 and the Apache Standard C++ > Library. The Sun C++ ABI does not change with the introduction of the Apache > library. Actually, the Apache library links against the existing libCrun.so.1, > and will conform to the Sun C++ ABI. It is the Library ABI's that are incompatible. > > C++ developers are well aware of incompatibilities between different > implementations of the Standard C++ Library. These incompatibilities exist > regardless of the compiler ABI in use. The GNU Standard C++ Library is not > compatible with the Apache Standard C++ Library, either, even in the case where > both were compiled with the exact same compiler. > Yes, but this is a PITA. Having a reasonably stable C++ ABI is a precondition for being able to ship binary applications that support plugins or binary plugins for existing applications. This is already pretty messy in cases like Mozilla or OpenOffice.org, which both support extensions through a component model with a native C++ binding. So by all means let's try to make a new, hopefully longer-lasting, stable C++ ABI. But that only works if the compiler and library take that step together. > This library compatibility conflict currently exists today, in Solaris, with the > presence of the STLport implementation of the Standard C++ Library. However, the > Apache implementation of the Standard C++ Library is far superior to STLport (if > for no other reason other than full internationalization support in Apache, > which is absent in STLport). And even if it wasn't superior, STLport is still > incompatible with libCstd.so.1 as well. > But then why is having three incompatible libraries better than two? STLport already supports the most important points of what you are setting out to do: - It is vastly more standards compliant than libCstd (at the cost of being incompatible). - It supports use of most of Boost. If stdcxx is superior to STLport, then that is a transition that the compiler group should make. And the full internationalization might even be a liability. I would expect some nasty surprises, if the locale support in the C++ library is out of sync with the support in the system itself. How do C++ applications behave, if the library doesn't support the current system locale? What happens when data for a locale is inconsistent between system and C++ library, so that C++ applications behave differently from all the others? Wouldn't it be better to add missing locale data to the system than to provide it in a C++-only ghetto? AFAIK there are a few cases already where we have multiple, possibly inconsistent databases for essentially the same data in the system. But any such case should be judged very carefully. >> 4) If you have an application that needs to bring in libraries from >> multiple sources, each of which were built against different C++ >> standard libraries, you wind up with a situation where the binary can't >> work. And, its not clear to me that the poor developer stuck here >> trying to use one set of libraries linked against Apache's code, and >> another against Studio's, has a way to know that a problem is lurking, >> much less a way to avoid or solve it. > > Standards Compliance trumps potential (although not really possible) developer > confusion. > The compiler group has operated under the opposite premises - presumably for good reasons. And that confusion is not as impossible as you make it be. And how does availability of STLport not already fulfill the need for a Standards Compliant C++ library? If all you can put forward is QoI, then your argument gets much weaker. >> 5) Yes, I know that this problem already exists with Gnu C++ versus >> Studio compiler ABI incompatibilities. However, I'm strongly opposed >> seeing this problem increased by another degree of freedom if we can >> avoid it. > It is not only with different compilers (where in C++-land all bets are off). We even now have libCstd (for ABI stability) and STLport (for Standards Compliance). > This is not a degree or measure of freedom, this is a matter of becoming > compliant with an Industry Standard which was adopted 10 years ago, and which is > supported by all our competitors (I am deliberately not including GCC in this > statement, since GCC does not observe the same compatibility constraints to the > same degree to which the IBM, HP and Microsoft compilers do). > > This lack of compliance prevents us from introducing other C++ components (read: > BOOST) which are currently widely used in the industry, and by our customers. > Doesn't STLport already address this? >> 6) The failure mode if mislinked programs (random application >> misbehavior) makes me very unhappy. I'd far rather have a failure occur >> at compile or at least at link time. > > And that is exactly where the vast majority errors will occur. > > The case of "random application misbehavior" simply does not exist when linking > against conflicting Standard C++ Libraries. The application simply crashes on > startup, if it manages to link, and if the link editor did not already cause > fatal errors because of either undefined or multiply-defined symbols. > The problem situation occurs when components using different C++ standard libraries are dynamically loaded into the same process. If the C++ implementation lives behind a C interface or is loaded in plugin style (dlopen/dlsym), the linker cannot warn you in time. AFAIK there used to be a component (from some layered product), that used a C++ implementation for a name service switch module (at a tiem when these modules were not strictly confined to ncsd). This produced bad runtime crashes when C++/STLport applications called functions like gethostbyname(3NSL). >> I consider these compatibility concerns rather grave. > > Any C++ software developers worth their title knows that "Thou Shalt Not Mix > Different Implementations Of The Standard C++ Library." This is not a language > bug, it is a language feature. > C++ may not always be at the surface. And having to deal with several different libraries with different quirks when creating (e.g.) plugins for different applications is onerous. Adding MORE diversity is the problem, not the solution, here. - Jörg From Stefan.Teleman@sun.com Tue Aug 26 12:26:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QJQOWt004382 for ; Tue, 26 Aug 2008 12:26:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7QJQH9m000936; Tue, 26 Aug 2008 20:26:21 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K68008113BWH500@brm-avmta-1.central.sun.com>; Tue, 26 Aug 2008 13:26:20 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6800KUO3BVNQB0@brm-avmta-1.central.sun.com>; Tue, 26 Aug 2008 13:26:20 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7QJQIhX008920; Tue, 26 Aug 2008 12:26:18 -0700 (PDT) Date: Tue, 26 Aug 2008 15:26:18 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B4362C.7070604@sun.com> To: Joerg Barfurth Cc: "Garrett D'Amore" , John.Fischer@sun.com, PSARC-ext@sun.com Reply-to: Stefan Teleman Message-id: <48B458DA.5050700@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 7576 Joerg Barfurth wrote: > Hi, > > What I'm going to say really just reiterates the need to coordinate with > the compiler group (with which I am not particularly affiliated). But I > think I have some more arguments. > If they don't need ABI compatibility on Solaris, there are existing > alternative, in particular use of the STLport shipped with SunStudio. So, this is the argument for being out of sync and non-compliant with a 10 years old Industry Standard ? "If you don't like that we're not Standard Compliant, go elsewhere" ? Sad to say, many customers have already done that -- they went elsewhere. I didn't realize that chasing customers and developers away was a strategic direction at Sun. But maybe i'm misinformed. >>> 2) It seems like we (Sun and OpenSolaris both) ought to be putting >>> our weight behind *one* of the implementations. >> >> As explained above, we cannot do that, unless we want to remain >> Standard C++ non-compliant forever. >> > > Other have already made a strong case that this should be coordinated > with the compiler folks. At least there should be agreement whether > STLport or stdcxx is the best way forwards. The purpose of this Case is not to engage in a religious debate as to which of the two (STLport or stdcxx) libraries are better. I've already explained the inherent weaknesses of STLport, and the advantages of Apache. By sumbitting an ARC Case for Apache, and not STLport, the Case already implicilty asserts that Apache is better than STLport. This argument seems to be supported by usage in the industry. The Apache library is really nothing more than the RogueWave Standard C++ Library. Interesting that full internationalization and localization support, which is a *requirement* for integrating software in Solaris, is presented here as a weakness or defect. In light of this unusual line of argumentation, may i ask: has the requirement for internationalization and localization support in Solaris been dropped, and the strategic direction changed, to not support these facilities ? > BTW, I see that you suggest giving this library a Committed stability > classification. This may lead you into the same corner where libCstd > currently is caught: > > - Experience (e.g. the multitude of 'final stable ABI' releases of g++ > and its library) shows that it is very difficult to determine that > something is perfect enough that future bug fixes won't require more ABI > changes. The GNU C++ Compiler is known to break C++ ABI between minor or even micro releases. This case does not propose building the library with the GNU compiler, and does not address the weaknesses of the GNU compiler. Comparisons between the GNU compiler and the Sun Studio compiler are not germane to, or in scope for, this case. Many other compilers have many other different problems, none of which are being addressed in this Case. > - There will be TR2 and eventually the next version of the Standard. > Being 'Committed' may make the hurdle to accomodate these revisions very > high. Yes, the Library ABI will break again when the new Standard is adopted. This will require a new Library. This is a known fact, right now, and this is precisely the reason why the directory layout structure for Apache is organized the way it is: /usr/include/stdcxx. When the new Standard is implemented in a new library, it will maybe go into /usr/include/stdcxx0x, and the library names, and the binding SONAME will be different. This Case does not attempt to address "what might happen in the future". This Case is about the integration of a Fully Standard Compliant Standard C++ Library. Insofar as the future direction of the Standard C++ Library is concerned, in an as-of-yet unapproved ISO Standard, this Case cannot address the non existing standard. The C++ Standard implemented by this library is ISO/IEC:14882:2003. That Standard has been approved. > - You can maintain ABI compatibility only as long as the compiler does. > If you commit to an ABI now, you may be stuck with being tied to a > -compat switch and can't benefit from compiler improvements, if the > compiler group eventually makes the step to a 'major release' (i.e. a > new compiler ABI). This argument is equally valid for the Standard C Library, or, for that matter, for any other compiler/compiled language combo. "You can maintain ABI compatibility only as long as the compiler does". True. If the Sun C Compiler decides to break the C ABI, the Standard C Library will break. The same statement is equally true for Fortran. How is this relevant, or particular, to C++, and the Standard C++ Library being proposed in this ARC Case ? The "Committed" Interface Stability classification level, assigned to this library, implies, or states, _nothing_ about the *compiler's* C++ ABI Stability Level, given that the library does not control the compiler's ABI stability level. If the compiler breaks the C++ ABI, then all the libraries built with said compiler will break, including existing "Committed" ones. This hypothetical breakage is beyond this Case's scope, or control. This Case is *not* about the Sun C++ ABI. > Yes, but this is a PITA. Having a reasonably stable C++ ABI is a > precondition for being able to ship binary applications that support > plugins or binary plugins for existing applications. Again, the Sun C++ Compiler's C++ ABI is not being addressed in this Case. Again, there appears to be confusion between the compiler's C++ ABI and one library, or another's ABI. Compiler C++ ABI != Library ABI. This Case assigns "Committed" to the interfaces of the Standard C++ Library because: [1] the library implements an Industry Standard and [2] the interfaces are not expected to change in an imcompatible way, given that these interfaces have been defined in a Standard. For all we care, this Library can stay as is for the remainder of time. > This is already pretty messy in cases like Mozilla or OpenOffice.org, > which both support extensions through a component model with a native > C++ binding. > > So by all means let's try to make a new, hopefully longer-lasting, > stable C++ ABI. But that only works if the compiler and library take > that step together. > >> This library compatibility conflict currently exists today, in >> Solaris, with the presence of the STLport implementation of the >> Standard C++ Library. However, the Apache implementation of the >> Standard C++ Library is far superior to STLport (if for no other >> reason other than full internationalization support in Apache, which >> is absent in STLport). And even if it wasn't superior, STLport is >> still incompatible with libCstd.so.1 as well. >> > > But then why is having three incompatible libraries better than two? > > STLport already supports the most important points of what you are > setting out to do: > - It is vastly more standards compliant than libCstd (at the cost of > being incompatible). > - It supports use of most of Boost. Again: STLport is first of all: obsolete, only supports the "C" locale, and it has significantly less industry traction than Apache/RogueWave. Also, this case does not propose the integration of a "vastly more standards compliant" library, since the definition of "vastly more standards compliant" is in the eye of the beholder. This case proposes the integration of a Fully Standard Compliant library. This is a very significant difference. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gdamore@Sun.COM Tue Aug 26 14:28:32 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QLSWbM012147 for ; Tue, 26 Aug 2008 14:28:32 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7QLSVWh003476 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 14:28:32 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800B038ZJHQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 14:28:31 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K680099R8ZITO30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 14:28:30 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7QLSUMB013465 for ; Tue, 26 Aug 2008 14:28:30 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800E016Z4W100@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 14:28:30 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800BS88ZE9310@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 14:28:27 -0700 (PDT) Date: Tue, 26 Aug 2008 14:28:25 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B458DA.5050700@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Stefan Teleman Cc: Joerg Barfurth , John.Fischer@Sun.COM, PSARC-ext@Sun.COM Message-id: <48B47579.4070609@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 12600 Stefan Teleman wrote: > > > Joerg Barfurth wrote: >> Hi, >> >> What I'm going to say really just reiterates the need to coordinate >> with the compiler group (with which I am not particularly >> affiliated). But I think I have some more arguments. > >> If they don't need ABI compatibility on Solaris, there are existing >> alternative, in particular use of the STLport shipped with SunStudio. > > So, this is the argument for being out of sync and non-compliant with > a 10 years old Industry Standard ? "If you don't like that we're not > Standard Compliant, go elsewhere" ? Compatibility sometimes is more critical than standards compliance. One does not universally trump the other. Breaking a zillion customers' products just because > > Sad to say, many customers have already done that -- they went > elsewhere. I didn't realize that chasing customers and developers away > was a strategic direction at Sun. But maybe i'm misinformed. I think you're being intentionally dense here. I thought that STLport is supposed to be standards compliant. If it isn't, then we need to figure out a solution that either gets it to be standards compliant, or moves on a transition path towards something else that is (perhaps Apache's version). No one is saying this case can't ship. What we (me!) are saying is that it fails the obviousness test, and there should be some plan for a solution that consolidates us to a single library for most folks to use, and that library should be what is used by default. (The older compatibility libraries can stay as is, and might need special compiler options to make use of them.) > >>>> 2) It seems like we (Sun and OpenSolaris both) ought to be putting >>>> our weight behind *one* of the implementations. >>> >>> As explained above, we cannot do that, unless we want to remain >>> Standard C++ non-compliant forever. >>> >> >> Other have already made a strong case that this should be coordinated >> with the compiler folks. At least there should be agreement whether >> STLport or stdcxx is the best way forwards. > > > The purpose of this Case is not to engage in a religious debate as to > which of the two (STLport or stdcxx) libraries are better. Having more options here is harmful (even toxic). By presenting the option, you've opened up the debate, whether you intended to or not. > > I've already explained the inherent weaknesses of STLport, and the > advantages of Apache. By sumbitting an ARC Case for Apache, and not > STLport, the Case already implicilty asserts that Apache is better > than STLport. So are you engaging in debate or not? I'm confused. > This argument seems to be supported by usage in the industry. The > Apache library is really nothing more than the RogueWave Standard C++ > Library. I'm not disagreeing with you. > > Interesting that full internationalization and localization support, > which is a *requirement* for integrating software in Solaris, is > presented here as a weakness or defect. In light of this unusual line > of argumentation, may i ask: has the requirement for > internationalization and localization support in Solaris been dropped, > and the strategic direction changed, to not support these facilities ? No. (Although C++ has some serious weaknesses with i18n, the last time I looked. In particular the cstream stuff seemed horribly busted with respect to i18n. Though the last time I tried to update C++ code for i18n was when I was working on the E10k service processor stuff over a decade ago. At that time it was far easier to just scrap the C++ code and rewrite the applications in C. The resulting applications were a lot smaller in both line count and run time as a result, but that's a separate rant.) Anyway, the problem with i18n is making sure that whatever the language does works well with the operating system. Having another database of i18n related information that has to be managed separately from our existing locale databases will create additional headaches (someone has to manage the contents of those databases after all), and so should be reviewed by ARC. You can't just ignore issues like this by declaring the case a fast-track. >> BTW, I see that you suggest giving this library a Committed stability >> classification. This may lead you into the same corner where libCstd >> currently is caught: >> >> - Experience (e.g. the multitude of 'final stable ABI' releases of >> g++ and its library) shows that it is very difficult to determine >> that something is perfect enough that future bug fixes won't require >> more ABI changes. > > The GNU C++ Compiler is known to break C++ ABI between minor or even > micro releases. The GNU C++ compiler doesn't care about compatibility -- that's obvious from their track record. We can't fix that, but we can and do offer a better stable alternative. I don't think anyone (at least outside of the GNU group) seriously suggests that the GNU C++ compiler should be the "compiler of choice" for C++ code on Solaris. Btw, the GNU compatibility problems are not unique to g++. Ask someone someday about the headaches that revolved around updates to GNU libc. > > This case does not propose building the library with the GNU compiler, > and does not address the weaknesses of the GNU compiler. Comparisons > between the GNU compiler and the Sun Studio compiler are not germane > to, or in scope for, this case. Many other compilers have many other > different problems, none of which are being addressed in this Case. The intent was to point out the problem that this case raises, which is not unlike the g++ ABI problem. Its a comparison, and IMO, a very valid one. The GNU libc example above is probably even more relevant, although at least in that case nobody seriously suggested that the older libc would be kept around forever and ever -- it was expected that folks would transition to the new one, and the need for the old one would eventually go away. I suspect that we could treat the older libCrun.so (and possibly even STLport, if that is determined to be the best choice) similar to the older libucb environment -- something we supply for folks who absolutely require it, but not something we seriously advocate that anyone who has a choice use. But this case (as you've presented it) fails to do that, and fails to provide any guidance about one library versus another. It just adds yet another incompatible C++ library. > >> - There will be TR2 and eventually the next version of the Standard. >> Being 'Committed' may make the hurdle to accomodate these revisions >> very high. > > Yes, the Library ABI will break again when the new Standard is > adopted. This will require a new Library. This is a known fact, right > now, and this is precisely the reason why the directory layout > structure for Apache is organized the way it is: /usr/include/stdcxx. > When the new Standard is implemented in a new library, it will maybe > go into /usr/include/stdcxx0x, and the library names, and the binding > SONAME will be different. > > This Case does not attempt to address "what might happen in the future". Submitters of ARC cases should have reasonable plans for future growth and directions, and try to allow for them. You might guess wrong about what happens, but if you've made some reasonable effort to allow for it, then there is less likely to be problem. Putting your head in the sand isn't a good option, IMO. > > This Case is about the integration of a Fully Standard Compliant > Standard C++ Library. Insofar as the future direction of the Standard > C++ Library is concerned, in an as-of-yet unapproved ISO Standard, > this Case cannot address the non existing standard. If the language changes require ABI breakage, then there isn't a lot that can be done (other than not to use C++!) But we can at least discuss whether or not that is likely, and try to design a situation that will minimize the pain that such breakage will incur, at least in our system supplied libraries. > > The C++ Standard implemented by this library is ISO/IEC:14882:2003. > That Standard has been approved. > >> - You can maintain ABI compatibility only as long as the compiler >> does. If you commit to an ABI now, you may be stuck with being tied >> to a -compat switch and can't benefit from compiler improvements, if >> the compiler group eventually makes the step to a 'major release' >> (i.e. a new compiler ABI). > > This argument is equally valid for the Standard C Library, or, for > that matter, for any other compiler/compiled language combo. "You can > maintain ABI compatibility only as long as the compiler does". True. > If the Sun C Compiler decides to break the C ABI, the Standard C > Library will break. The same statement is equally true for Fortran. Yes, but they generally don't break the ABI. > > How is this relevant, or particular, to C++, and the Standard C++ > Library being proposed in this ARC Case ? > > The "Committed" Interface Stability classification level, assigned to > this library, implies, or states, _nothing_ about the *compiler's* C++ > ABI Stability Level, given that the library does not control the > compiler's ABI stability level. If the compiler breaks the C++ ABI, > then all the libraries built with said compiler will break, including > existing "Committed" ones. This hypothetical breakage is beyond this > Case's scope, or control. This Case is *not* about the Sun C++ ABI. > >> Yes, but this is a PITA. Having a reasonably stable C++ ABI is a >> precondition for being able to ship binary applications that support >> plugins or binary plugins for existing applications. > > Again, the Sun C++ Compiler's C++ ABI is not being addressed in this > Case. > > Again, there appears to be confusion between the compiler's C++ ABI > and one library, or another's ABI. > > Compiler C++ ABI != Library ABI. For my purposes: ABI = union(C++ compiler ABI, library ABI) Breakage of either the compiler or the library interfaces will cause binaries to break. > > This Case assigns "Committed" to the interfaces of the Standard C++ > Library because: [1] the library implements an Industry Standard and > [2] the interfaces are not expected to change in an imcompatible way, > given that these interfaces have been defined in a Standard. > > For all we care, this Library can stay as is for the remainder of time. > >> This is already pretty messy in cases like Mozilla or OpenOffice.org, >> which both support extensions through a component model with a native >> C++ binding. >> >> So by all means let's try to make a new, hopefully longer-lasting, >> stable C++ ABI. But that only works if the compiler and library take >> that step together. >> >>> This library compatibility conflict currently exists today, in >>> Solaris, with the presence of the STLport implementation of the >>> Standard C++ Library. However, the Apache implementation of the >>> Standard C++ Library is far superior to STLport (if for no other >>> reason other than full internationalization support in Apache, which >>> is absent in STLport). And even if it wasn't superior, STLport is >>> still incompatible with libCstd.so.1 as well. >>> >> >> But then why is having three incompatible libraries better than two? >> >> STLport already supports the most important points of what you are >> setting out to do: >> - It is vastly more standards compliant than libCstd (at the cost of >> being incompatible). >> - It supports use of most of Boost. > > Again: STLport is first of all: obsolete, only supports the "C" > locale, and it has significantly less industry traction than > Apache/RogueWave. So then lets have a full plan to transition to Apache instead of this half-baked proposal. > > Also, this case does not propose the integration of a "vastly more > standards compliant" library, since the definition of "vastly more > standards compliant" is in the eye of the beholder. This case proposes > the integration of a Fully Standard Compliant library. This is a very > significant difference. Again, lets have a plan to transition then. I would like to see the compiler folks involved, along with a more complete plan for how this fits in the big picture, and how we transition (if that is required) away from STLport. I'm on the verge of coming out of sabbatical just for this case, if only so I can derail it. It fails on many significant points to meet the obviousness test required of a fast track. -- Garrett From Stefan.Teleman@sun.com Tue Aug 26 14:47:30 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QLlTeC013036 for ; Tue, 26 Aug 2008 14:47:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7QLlL07027059; Tue, 26 Aug 2008 22:47:27 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K68008019V1K000@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 14:47:25 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K68004PZ9V14T60@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 14:47:25 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7QLlO2w029019; Tue, 26 Aug 2008 14:47:24 -0700 (PDT) Date: Tue, 26 Aug 2008 17:47:24 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B47579.4070609@sun.com> To: "Garrett D'Amore" Cc: Joerg Barfurth , John.Fischer@sun.com, PSARC-ext@sun.com Reply-to: Stefan Teleman Message-id: <48B479EC.8070204@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 3496 Garrett D'Amore wrote: > Stefan Teleman wrote: >> >> >> Joerg Barfurth wrote: >>> Hi, >>> >>> What I'm going to say really just reiterates the need to coordinate >>> with the compiler group (with which I am not particularly >>> affiliated). But I think I have some more arguments. >> >>> If they don't need ABI compatibility on Solaris, there are existing >>> alternative, in particular use of the STLport shipped with SunStudio. >> >> So, this is the argument for being out of sync and non-compliant with >> a 10 years old Industry Standard ? "If you don't like that we're not >> Standard Compliant, go elsewhere" ? > > Compatibility sometimes is more critical than standards compliance. One > does not universally trump the other. Breaking a zillion customers' > products just because For the record: *NOTHING* will break. >> Sad to say, many customers have already done that -- they went >> elsewhere. I didn't realize that chasing customers and developers away >> was a strategic direction at Sun. But maybe i'm misinformed. > > I think you're being intentionally dense here. Thank you. I was aiming for that. > I thought that STLport is supposed to be standards compliant. No, it is not. > If it isn't, then we need to > figure out a solution that either gets it to be standards compliant, or > moves on a transition path towards something else that is (perhaps > Apache's version). Why ? What does STLport have to do with Apache ? The version of STLport4 included with the compiler is no longer maintained, or developed. It's *dead*. The new version of STLport5, is not ABI compatible with STLport4. So, we're back to Square One. > No one is saying this case can't ship. What we (me!) are saying is that > it fails the obviousness test, and there should be some plan for a > solution that consolidates us to a single library for most folks to use, > and that library should be what is used by default. Why ? Where does the requirement for "consolidating into a single library" come from ? The Sun Compiler Team has intentionally put a lot of effort in separating the C++ run-time from the Standard C++ Library. There are two libraries involved in C++ with Sun Studio: libCrun.so.1, and libCstd.so.1. I believe that this separation was intentional, and it was done precisely for the purpose of enabling multiple instances of the Standard C++ Library to coexist, and work, within the same Sun C++ run-time. Do we consolidate into a single library today ? No, we don't. Have we done this in the past ? No, we haven't. Can we honestly assert that we can do this in the future ? No, we can't, because the next iteration of the Standard will break compatibility with the existing one, and that will require a new Library, and this fact is already known today. How do you propose in practical terms to achieve this ? Your are proposing the following: let's change the default compiler behavior, so that it changes the default Standard C++ Library being used, from libCstd.so.1, to Apache. The Apache Library is known to be API and ABI incompatible with libCstd.so.1, so, by changing the default compiler behavior, we have instantly broken all your software. How is this proposal consistent with your earlier assertion that "maintaining compatibility" trumps Standards Compliance ? Or, how is this same proposal consistent with the Principle Of Least Astonishment ? --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From John.Plocher@sun.com Tue Aug 26 15:15:20 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QMFKYR013715 for ; Tue, 26 Aug 2008 15:15:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7QMFJV0042630 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 16:15:20 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800K0JB5JMJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 16:15:19 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6800JGQB5HS800@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 16:15:17 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7QMFHrn014561 for ; Tue, 26 Aug 2008 15:15:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800601AQ68N00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 15:15:17 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800MALB5GGH60@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 15:15:16 -0700 (PDT) Date: Tue, 26 Aug 2008 15:15:12 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B479EC.8070204@Sun.COM> Sender: John.Plocher@sun.com To: Stefan Teleman Cc: "Garrett D'Amore" , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B48070.2000407@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 1455 Stefan Teleman wrote: > Or, how is this same proposal consistent with the Principle Of Least Astonishment ? 1) What happens TODAY when I have A) A middleware C++ module that uses the STLPort4 Standard C++ Library B) A different middleware module that uses the Apache Standard C++ Library and C) A program that needs to use both middleware libraries? (I would expect pain and suffering and a failed build, but I could be wrong.) 2) Is the answer different if you postulate having the sources for A and B -vs- only having shared object libraries? 3) Are the various Standard C++ Libraries compatible at all at the source level? and finally, 4) What is the big picture with respect to all these choices? What I'm hoping to hear for this last one is something like STLPort4 is old and obsolete, but kept around for customers who have source and/or binary compatibility requirements with the [xxx] Standard. STLPort5 is a newer-but-source-and-binary incompatible replacement for STLPort4 that is compliant with [xxx] Standard. The Apache Standard C++ Library has the following relationships to the above [...]. New C++ code should be written to use [...pick one or more...] because [... rationalizations...]. New C++ middleware libraries should/must use [... pick one...] in order to ensure that applications can actually be built that use multiple C++ modules. -John From carlsonj@phorcys.east.sun.com Tue Aug 26 15:22:47 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QMMkPW013922 for ; Tue, 26 Aug 2008 15:22:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7QMMjKI045010; Tue, 26 Aug 2008 16:22:45 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800A05BHW4T00@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 15:22:44 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K68004OMBHU5180@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 15:22:43 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7QMMgtE029610; Tue, 26 Aug 2008 18:22:42 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7QMMgqD029607; Tue, 26 Aug 2008 18:22:42 -0400 (EDT) Date: Tue, 26 Aug 2008 18:22:42 -0400 From: James Carlson Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B48070.2000407@Sun.Com> To: John Plocher Cc: Stefan Teleman , "Garrett D'Amore" , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <18612.33330.522900.629427@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> Status: RO Content-Length: 1360 John Plocher writes: > 1) What happens TODAY when I have > > A) A middleware C++ module that uses the STLPort4 Standard C++ Library > B) A different middleware module that uses the Apache Standard C++ Library > and > C) A program that needs to use both middleware libraries? > > (I would expect pain and suffering and a failed build, but I could be wrong.) That'd be the hoped-for case. The more likely case is that the build works just fine, but subtle bugs and data corruption result when (say) 'program' allocates an object using 'STLPort4' and hands it off to a function^Wmethod using Apache. Many of those sorts of problems just can't be detected at build time. There's no good way to know what's "underneath" a library that you're using -- and since it's _supposed_ to be an implementation detail of that middleware, it's not something you'd even want to know. And it may change with time. > New C++ middleware libraries should/must use [... pick one...] in > order to ensure that applications can actually be built that use > multiple C++ modules. That's the part that I think is missing. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Stefan.Teleman@sun.com Tue Aug 26 15:53:28 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QMrSrt015130 for ; Tue, 26 Aug 2008 15:53:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7QMrOLt020180; Tue, 26 Aug 2008 23:53:26 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800003CX18L00@brm-avmta-1.central.sun.com>; Tue, 26 Aug 2008 16:53:25 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6800JCPCX0RY20@brm-avmta-1.central.sun.com>; Tue, 26 Aug 2008 16:53:24 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7QMrNdY015348; Tue, 26 Aug 2008 15:53:23 -0700 (PDT) Date: Tue, 26 Aug 2008 18:53:23 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B48070.2000407@Sun.Com> To: John Plocher Cc: "Garrett D'Amore" , John.Fischer@sun.com, PSARC-ext@sun.com Reply-to: Stefan Teleman Message-id: <48B48963.30600@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2708 John Plocher wrote: > Stefan Teleman wrote: >> Or, how is this same proposal consistent with the Principle Of Least >> Astonishment ? > > > 1) What happens TODAY when I have > > A) A middleware C++ module that uses the STLPort4 Standard C++ Library > B) A different middleware module that uses the Apache Standard C++ > Library > and > C) A program that needs to use both middleware libraries? > > (I would expect pain and suffering and a failed build, but I could be > wrong.) Does not work, cannot work, instant breakage. > > 2) Is the answer different if you postulate having the sources for A and > B -vs- > only having shared object libraries? Nope. > > 3) Are the various Standard C++ Libraries compatible at all at the > source level? Nope. > > and finally, > > 4) What is the big picture with respect to all these choices? Incompatibility between different implementations of different Standard C++ Library's is a known fact, it comes with the language. The big picture is: using the Apache Standard C++ Library is a voluntary choice, and it must be explicitly enabled (via specific compiler flags, in existence today). Using it will break any compatibility with libCstd.so.1. > What I'm hoping to hear for this last one is something like > > STLPort4 is old and obsolete, but kept around for customers who have > source and/or binary compatibility requirements with the [xxx] > Standard. True. > STLPort5 is a newer-but-source-and-binary incompatible replacement > for STLPort4 that is compliant with [xxx] Standard. True. > The Apache Standard C++ Library has the following relationships > to the above [...]. - Apache Standard C++ Library has no relation to STLport, either 4 or 5. - Apache Standard C++ Library is the RogueWave implementation of the Standard C++ Library. > New C++ code should be written to use [...pick one or more...] > because [... rationalizations...]. New C++ code which must make use of Standard Language facilities not supported in libCstd.so.1, should use the Standard Compliant C++ Library (Apache) -- being proposed here, for the following reasons: - Fully Compliant with the 1998/2003 C++ Standard - Full Internationalization and Localization support (absent in STLport4) - Thread-safe - 64-bit clean However: mixing any two different implementations of the Standard C++ Library in the same address space does not work. > New C++ middleware libraries should/must use [... pick one...] in > order to ensure that applications can actually be built that use > multiple C++ modules. Not possible. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gdamore@sun.com Tue Aug 26 16:14:38 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QNEbuO016142 for ; Tue, 26 Aug 2008 16:14:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7QNEUF6028665 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 27 Aug 2008 00:14:37 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800101DWCST00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 17:14:36 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6800J1WDWBRV30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 17:14:35 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7QNEZ8V020805 for ; Tue, 26 Aug 2008 16:14:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800F01DLH7600@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 16:14:35 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K680048KDWA0O60@fe-sfbay-09.sun.com>; Tue, 26 Aug 2008 16:14:34 -0700 (PDT) Date: Tue, 26 Aug 2008 16:14:33 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B48963.30600@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John Plocher , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B48E59.2000807@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1403 Stefan Teleman wrote: > > New C++ code which must make use of Standard Language facilities not > supported in libCstd.so.1, should use the Standard Compliant C++ > Library (Apache) -- being proposed here, for the following reasons: > > - Fully Compliant with the 1998/2003 C++ Standard > - Full Internationalization and Localization support (absent in STLport4) > - Thread-safe > - 64-bit clean > > However: mixing any two different implementations of the Standard C++ > Library in the same address space does not work. So, if standards compliance is key, then lets have a *full* case detailing the following: 1) Marking libCrun and libCstd as Obsolete, and discourage their future use. (Possible EOF notices.) 2) Integration of Apache libstdc++. 3) Transition flags for compilers to select older C runtimes if required for compatibility reasons. 4) Studio 13 (or somesuch) to use libstdc++ by default. 5) Full disclosure of g11n considerations for programs making use of g11n features. (How is locale-specific data managed?) 6) Full disclosure of any source incompatibilities between libraries. 7) Involvement from compiler folks (required for items #3 & #4) 8) Description of any expected future incompatibilities Yes, I'm asking for a lot here. But I think doing this the "right way" is worth the trouble, and ultimately will save a lot of confusion and trouble later. -- Garrett From gdamore@sun.com Tue Aug 26 16:17:39 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QNHcff016203 for ; Tue, 26 Aug 2008 16:17:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7QNHOSM028352 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 27 Aug 2008 07:17:37 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800001E1AFR00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 16:17:34 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6800LW1E19ST60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 16:17:33 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7QNHXYA026404 for ; Tue, 26 Aug 2008 16:17:33 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800901DOJ6B00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 16:17:33 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800BV2E187MG0@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 16:17:32 -0700 (PDT) Date: Tue, 26 Aug 2008 16:17:31 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B48963.30600@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: PSARC-ext@sun.com Message-id: <48B48F0B.9080208@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 421 Btw, apart from my request for a full proposal, which I already sent to the larger group, the rest of my responses to the "debate" have been taken off of PSARC-ext and delivered privately to Stefan. If folks are unclear about what I'm asking for or want to debate the merit of what I'm asking for (or of this case for that matter), then can I humbly recommend we do so off of PSARC-ext@? Thanks. -- Garrett From Stefan.Teleman@Sun.COM Tue Aug 26 20:03:23 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7R33Ngv020972 for ; Tue, 26 Aug 2008 20:03:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7R33LJC007754; Tue, 26 Aug 2008 20:03:23 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800J05OHMD700@brm-avmta-1.central.sun.com>; Tue, 26 Aug 2008 21:03:22 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6800JZKOHLSCB0@brm-avmta-1.central.sun.com>; Tue, 26 Aug 2008 21:03:21 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7R33K7C021216; Tue, 26 Aug 2008 20:03:20 -0700 (PDT) Date: Tue, 26 Aug 2008 23:03:19 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B48E59.2000807@sun.com> To: "Garrett D'Amore" Cc: John Plocher , John.Fischer@Sun.COM, PSARC-ext@Sun.COM Reply-to: Stefan Teleman Message-id: <48B4C3F7.5030003@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1454 Garrett D'Amore wrote: > Stefan Teleman wrote: >> >> New C++ code which must make use of Standard Language facilities not >> supported in libCstd.so.1, should use the Standard Compliant C++ >> Library (Apache) -- being proposed here, for the following reasons: >> >> - Fully Compliant with the 1998/2003 C++ Standard >> - Full Internationalization and Localization support (absent in STLport4) >> - Thread-safe >> - 64-bit clean >> >> However: mixing any two different implementations of the Standard C++ >> Library in the same address space does not work. > > So, if standards compliance is key, then lets have a *full* case > detailing the following: > > 1) Marking libCrun and libCstd as Obsolete, and discourage their future > use. (Possible EOF notices.) > 2) Integration of Apache libstdc++. > 3) Transition flags for compilers to select older C runtimes if required > for compatibility reasons. > 4) Studio 13 (or somesuch) to use libstdc++ by default. > 5) Full disclosure of g11n considerations for programs making use of > g11n features. (How is locale-specific data managed?) > 6) Full disclosure of any source incompatibilities between libraries. > 7) Involvement from compiler folks (required for items #3 & #4) > 8) Description of any expected future incompatibilities These requirements are completely beyond the scope and intent of this ARC Case. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From John.Plocher@sun.com Tue Aug 26 20:41:17 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7R3fGfo021312 for ; Tue, 26 Aug 2008 20:41:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7R3eb0a007741 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 27 Aug 2008 04:41:16 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800201Q8GMM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 26 Aug 2008 20:41:04 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6800FZXQ8GIEA0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 26 Aug 2008 20:41:04 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7R3f4gi010864 for ; Tue, 26 Aug 2008 20:41:04 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800H01Q80D100@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 26 Aug 2008 20:41:04 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800E0AQ8FL210@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 20:41:04 -0700 (PDT) Date: Tue, 26 Aug 2008 20:40:58 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B4C3F7.5030003@Sun.COM> Sender: John.Plocher@sun.com To: Stefan Teleman Cc: "Garrett D'Amore" , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B4CCCA.7030002@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 964 Stefan Teleman wrote: > Garrett D'Amore wrote: >> So, if standards compliance is key, then lets have a *full* case >> detailing the following: > These requirements are completely beyond the scope and intent of this > ARC Case. I tend to agree with Stefan here - what is wrong with a case that simply adds a new component without resetting the expectations surrounding the current one? In other words, how is this case architecturally different from our other recent cases that added commands that were similar-but-not-replacements-for existing ones? Adding a new command or library to the repo is a separable act from deciding to promote one of them as a preferred version. If the compiler team wishes to follow your suggestions in a new case that attempts to standardize on a newer C++ STL, that would be OK with me; however, forcing *this* case to do more than articulate what Stefan has already said about mixing and matching seems a bit much. -John From gdamore@sun.com Tue Aug 26 21:55:31 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7R4tUF9023215 for ; Tue, 26 Aug 2008 21:55:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7R4tQkP027106 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 27 Aug 2008 12:55:29 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800501TOG2A00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 22:55:28 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6800JWVTOFS6E0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 22:55:27 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7R4tRSF005798 for ; Tue, 26 Aug 2008 21:55:27 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800B01TNTGP00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 21:55:27 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800EI5TOEL2F0@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 21:55:26 -0700 (PDT) Date: Tue, 26 Aug 2008 21:55:23 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B4CCCA.7030002@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Stefan Teleman , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B4DE3B.8040608@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 5556 John Plocher wrote: > Stefan Teleman wrote: >> Garrett D'Amore wrote: >>> So, if standards compliance is key, then lets have a *full* case >>> detailing the following: > >> These requirements are completely beyond the scope and intent of this >> ARC Case. > > I tend to agree with Stefan here - what is wrong with a case that > simply adds a new component without resetting the expectations > surrounding the current one? In other words, how is this case > architecturally different from our other recent cases that added > commands that were similar-but-not-replacements-for existing ones? Middleware and confusing link compatibilities. This isn't just like adding another grep implementation or a different "make". Its adding a middle layer that is *fundamentally* incompatible with our "approved" middleware. What do we tell consumers? Which library should they use? The library this case proposes will require extra contortions to use, and will not be used by another Sun supplied middleware, so if you use it, you can't mix it with any other code not explicitly recompiled with it. Conversely, apparently what we ship is not standards compliant. This is a lose-lose situation. We need to turn it around into a win-win situation. The best way to do that is to get to a situation where we universally bless (and fully support, including making it the default choice and making sure that all of our middleware supports it) a standards compliant library. > > Adding a new command or library to the repo is a separable act from > deciding to promote one of them as a preferred version. This is a lot different IMO. We're talking about introducing fundamentally incompatible building blocks into the system, and not giving any guidance to users or developers as to which they should use. Or even a way for developers to know if they are going to use a middleware component which C++ library they are going to need to link against. Please go back and review the madness that happened in the Linux world when there were two GNU libc's in common use. It was *not* a good thing. This case proposes going down the same road, but without even having a plan to ultimately obsolesce one of the implementations. (At least the Linux libc problem resolved itself after time since there was a clear succession.) Its an open-ended situation of madness without any guidance for developers or even end users. (Recall not everyone that compiles code is a developer.) That's architecturally wrong for everyone, I think. > > If the compiler team wishes to follow your suggestions in a new case > that attempts to standardize on a newer C++ STL, that would be OK > with me; however, forcing *this* case to do more than articulate what > Stefan has already said about mixing and matching seems a bit much. Again, this is *not* like any other component. Its a fundamental building block, and ultimately, if we're going to ship it, its going to become a huge call generator when folks try to use it but find out that there are incompatibilities with different middleware layers. I also think there needs to be some work done (perhaps in the linker group) if this is going to be an ongoing concern, so that there is a link-time failure (with suitable messaging) when incompatible C++ run times are loaded into the same address space. *That* might be beyond the scope of this case. I think the submitter is trying to slide something "under the radar", and ignore the major issues that this is going to create. I'm extremely dissatisfied with any "not this case" kind of response to these issues. I'll note that I've also received mail from at least one major partner who uses Studio C++ and STLport that more choice is *not* the right answer -- a more comprehensive answer is required, and that yes, a fully supported/blessed transition to a fully standards conforming library is greatly desired. Now, by way of a compromise, I *might* be satisfied with an addendum to this case that forbade shipping any middleware (read libraries) -- or at least middleware with stability beyond Project Private -- built with this C++ library until a formal case addressing my concerns was brought forward. However, I suspect that this would seriously degrade the value that this project had hoped to bring to the table, since the limitations would probably prevent a huge majority of the likely candidate users. (It also flies in the face of the proposed Committed stability.) Unless something changes here, I feel so strongly about this issue that I'm likely to come out of sabbatical just to derail this case, if nobody else does first. I'm *not* trying to prevent us shipping Apache's product -- I suspect that the best situation for all involved is if we can get libstdc++ (or possibly STLport5 -- I'm not prepared to judge between them) adopted as a replacement "default" library, and obsolesce the older stuff. But we need to evaluate the project fully. By the way, the project has also failed to describe how the l10n data is managed/accessed. This is a significant deficiency in the project's specification. Projects using this touted i18n features of this library need to know what the implications are for them... how do they deliver localized data, etc. This is the sort of information that I expect would be exposed in a full case. I also haven't heard the compiler folks chime in. Adopting this case without getting their input would, IMO, be grossly irresponsible. -- Garrett From Michael.Schuster@sun.com Tue Aug 26 22:04:07 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7R547gw023324 for ; Tue, 26 Aug 2008 22:04:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7R544Gf006246 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 22:04:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800519U2TOD00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 23:04:05 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K68005UBU2TB810@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 23:04:05 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7R544Ke013900 for ; Tue, 26 Aug 2008 22:04:04 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800F01TZ5V800@fe-sfbay-10.sun.com> (original mail from Michael.Schuster@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 22:04:04 -0700 (PDT) Received: from [192.168.2.11] ([76.204.26.217]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800CNZU2S7I10@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 22:04:04 -0700 (PDT) Date: Tue, 26 Aug 2008 22:04:09 -0700 From: michael schuster Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B4DE3B.8040608@sun.com> Sender: Michael.Schuster@sun.com To: "Garrett D'Amore" Cc: John Plocher , Stefan Teleman , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B4E049.3030906@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 391 Garrett D'Amore wrote: > What do we tell consumers? Which library should they use? I think you're missing the point that many a project in the FOSS world *is* using this library, we want them to be able to move so to Solaris faster, without having to bring their own copy of the library. Michael -- Michael Schuster http://blogs.sun.com/recursion Recursion, n.: see 'Recursion' From John.Plocher@sun.com Tue Aug 26 22:32:15 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7R5WF0p025049 for ; Tue, 26 Aug 2008 22:32:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7R5W1oQ013706 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 22:32:14 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800707VDORZ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 23:32:12 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K68005E7VDOB8A0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 23:32:12 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7R5WCvi014811 for ; Tue, 26 Aug 2008 22:32:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800B01VANUZ00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 22:32:12 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800CZ0VDN7I60@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 22:32:11 -0700 (PDT) Date: Tue, 26 Aug 2008 22:32:11 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B4DE3B.8040608@sun.com> Sender: John.Plocher@sun.com To: "Garrett D'Amore" Cc: Stefan Teleman , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B4E6DB.1040207@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 3191 Garrett D'Amore wrote: > What do we tell consumers? Which library should they use? Exactly what we tell them today. "Use the stuff shipped with Studio". The customers will do exactly what *they* do today: Download and use the Apache Standard C++ Library. Except that they won't have to download it first. > Conversely, apparently what we ship is not standards compliant. Not this case. Gee, it would be nice if..., but it isn't. > This is a lose-lose situation. Good advice to the Sun Tools team, but again, not really this case. > We need to turn it around into a win-win situation. The best way to do > that is to get to a situation where we universally bless (and fully > support, including making it the default choice and making sure that all > of our middleware supports it) a standards compliant library. Also good advice, but it doesn't preclude offering our customers the very same choices they already have today: you can use our stuff now, you can hope we improve our stuff in the future, and/or you can use this other stuff. Gone are the days where it is normative to force ourselves or our users into a one-size-fits-all wardrobe. Yes, it is good to be able to deliver an integrated system; no, it isn't a showstopper for everyone else if we don't. > Please go back and review the madness that happened I don't disagree that madness lies down this path. Rather, I'm arguing that the using the threat of potential future madness to stop others from delivering components until *Sun* commits to doing something is a syntax error in an open source community. > Again, this is *not* like any other component. Its a fundamental > building block, How is it different from trying to mix Motif, GTK+ and KDE libraries in a single X application? Or trying to use g++ libs in a Studio application? In all these cases, we explicitly tell the user what the constraints are, and what they should expect to work and what shouldn't. Same here. Stefan needs to ensure that the docs tell the user all about these issues so that they don't try to crosslink things. He needs to say "here be dragons". He does not need to boil the ocean. > I think the submitter is trying to slide something "under the radar", You are reading too much into this. No conspiracy here, just a desire to provide a library that are customers are *already* downloading and using. Pandora's box is already open; this case doesn't make things worse. > and ignore the major issues that this is going to create. I'm extremely > dissatisfied with any "not this case" kind of response to these issues. I'm really disappointed that the compiler team hasn't jumped in to this discussion. Have they been contacted and invited? > Now, by way of a compromise, I *might* be satisfied with an addendum to > this case that forbade shipping any middleware (read libraries) -- or at Forbade *who* from doing so? Sun? OpenSolaris? Nexenta? Schillix? Slippery slope? > By the way, [other good points...] > I also haven't heard the compiler folks chime in. Adopting this case > without getting their input would, IMO, be grossly irresponsible. I can agree with this :-) -John From gdamore@sun.com Tue Aug 26 22:33:22 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7R5XL6G025064 for ; Tue, 26 Aug 2008 22:33:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7R5XLgm014868 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 22:33:21 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800L0BVFKDX00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 22:33:20 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6800E8JVFJ5120@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 22:33:19 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7R5XJ2m006761 for ; Tue, 26 Aug 2008 22:33:19 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800B01VANUZ00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 22:33:19 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800C59VFI7I70@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 22:33:19 -0700 (PDT) Date: Tue, 26 Aug 2008 22:33:16 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B4E049.3030906@sun.com> Sender: Garrett.Damore@sun.com To: michael schuster Cc: John Plocher , Stefan Teleman , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B4E71C.4030004@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> <48B4E049.3030906@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1212 michael schuster wrote: > Garrett D'Amore wrote: > >> What do we tell consumers? Which library should they use? > > I think you're missing the point that many a project in the FOSS world > *is* using this library, we want them to be able to move so to Solaris > faster, without having to bring their own copy of the library. Maybe, this is the first time this point has been raised. Why are they doing this? Are there ways that STLport4 or somesuch is somehow grossly incompatible? What about projects using STLport5? If those projects are providing middleware libraries of their own, then there is a house of cards being built, and we need to address that asap. Just delivering the library doesn't resolve the concerns, although it may stave off one set of problems for a little while. Again, I'm not opposed to shipping Apache stdc++, but I think it is crucial to consider the broader compatibility implications (particularly for middleware), and come up with a solution that gets us to the point where we can fully bless and support a standards-compliant library. Right now this case feels like a rush-job to get something integrated, rather than a well-formed proposal. -- Garrett From Michael.Schuster@sun.com Tue Aug 26 22:40:07 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7R5e7MM025081 for ; Tue, 26 Aug 2008 22:40:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7R5e4lU016691 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 22:40:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800813VQSFG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 23:40:04 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K68005MIVQRB8C0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 23:40:03 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7R5e3iq015055 for ; Tue, 26 Aug 2008 22:40:03 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800F01VNOMZ00@fe-sfbay-10.sun.com> (original mail from Michael.Schuster@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 22:40:03 -0700 (PDT) Received: from [192.168.2.11] ([76.204.26.217]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800CD8VQQ7I80@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 22:40:03 -0700 (PDT) Date: Tue, 26 Aug 2008 22:40:08 -0700 From: michael schuster Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B4E71C.4030004@sun.com> Sender: Michael.Schuster@sun.com To: "Garrett D'Amore" Cc: John Plocher , Stefan Teleman , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B4E8B8.8020409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> <48B4E049.3030906@sun.com> <48B4E71C.4030004@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 877 Garrett D'Amore wrote: > michael schuster wrote: >> Garrett D'Amore wrote: >> >>> What do we tell consumers? Which library should they use? >> >> I think you're missing the point that many a project in the FOSS world >> *is* using this library, we want them to be able to move so to Solaris >> faster, without having to bring their own copy of the library. > > Maybe, this is the first time this point has been raised. > > Why are they doing this? Are there ways that STLport4 or somesuch is > somehow grossly incompatible? What about projects using STLport5? IMO it's completely beside the point *why* they are doing so (although I believe Stefan's detailed answers to your previous emails provide sufficient information), the relevant issue here is *that* they are. Michael -- Michael Schuster http://blogs.sun.com/recursion Recursion, n.: see 'Recursion' From gdamore@sun.com Tue Aug 26 22:53:12 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7R5rCU0025171 for ; Tue, 26 Aug 2008 22:53:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7R5rCG8020170 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 22:53:12 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800905WCO9R00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 22:53:12 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K68005N5WCO8T30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 22:53:12 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7R5rBSG007169 for ; Tue, 26 Aug 2008 22:53:11 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800001W84IV00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 22:53:11 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800CUNWCN7IA0@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 22:53:11 -0700 (PDT) Date: Tue, 26 Aug 2008 22:53:08 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B4E6DB.1040207@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Stefan Teleman , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B4EBC4.6060901@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> <48B4E6DB.1040207@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 6687 John Plocher wrote: > Garrett D'Amore wrote: >> What do we tell consumers? Which library should they use? > > Exactly what we tell them today. "Use the stuff shipped with Studio". > The customers will do exactly what *they* do today: Download and use > the Apache Standard C++ Library. Except that they won't have to > download it first. My problem is that ARC blessing it is not just "shipping" a bit of software, but blessing it as a foundation upon which to build other bits. This goes beyond "download and install component X". > >> Conversely, apparently what we ship is not standards compliant. > > Not this case. Gee, it would be nice if..., but it isn't. > >> This is a lose-lose situation. > > Good advice to the Sun Tools team, but again, not really this case. I disagree with the "not-this-case" argument. If you're going to introduce a foundation block, then I think we need to understand how the bits fit together, and have a bigger picture. > >> We need to turn it around into a win-win situation. The best way to >> do that is to get to a situation where we universally bless (and >> fully support, including making it the default choice and making sure >> that all of our middleware supports it) a standards compliant library. > > Also good advice, but it doesn't preclude offering our customers the > very same choices they already have today: you can use our stuff now, > you can hope we improve our stuff in the future, and/or you can use > this other stuff. And that is the situation already. *BUT*, if you're going to use other stuff, then it is fairly explicit that most of the middleware we supply won't be linked with it, and you already know you're off into unsupported (or self-supported) territory. > > Gone are the days where it is normative to force ourselves or our users > into a one-size-fits-all wardrobe. Yes, it is good to be able to > deliver an integrated system; no, it isn't a showstopper for everyone > else if we don't. I'm depressed by your response. It seems to me that you believe we shouldn't try to solve the problem. If anyone can integrate whatever the heck they want, without regards to how the pieces fit together in the subsystem (even if, as in this, case know that there are major problems looming due to significant incompatibilities with no plan to resolve them), just to save someone a download, then what the heck are we wasting our time at ARC for? > > >> Please go back and review the madness that happened > > I don't disagree that madness lies down this path. Rather, I'm > arguing that the using the threat of potential future madness to > stop others from delivering components until *Sun* commits to doing > something is a syntax error in an open source community. Sun doesn't have to commit to anything here. The *community* (or if you prefer, the OpenSolaris project) should pick one. It stands to reason that it would be good if the compiler folks were brought on board as well. If that can't work, then maybe we need to supply stock Makefiles or a compilation wrapper that overrides the default compiler flags -- I don't know. Please don't try to make this into a Sun versus the community issue. It isn't. Its a "complete architecture versus half-baked impending morass" issue. > >> Again, this is *not* like any other component. Its a fundamental >> building block, > > How is it different from trying to mix Motif, GTK+ and KDE libraries > in a single X application? Or trying to use g++ libs in a Studio > application? In all these cases, we explicitly tell the user what > the constraints are, and what they should expect to work and what > shouldn't. Same here. Stefan needs to ensure that the docs tell > the user all about these issues so that they don't try to crosslink > things. The g++ libs problem is germane, and is already a source of issues. However, since generally the GNU C++ is generally used together with g++ libraries, its not really that big a problem -- we already don't mix and match GNU C++ and Studio C++ in the same address space. That's a well understood limitation. (And yes, it still is a major headache in its own right.) The various GUI libraries are far less a concern, since generally there is little desire to mix and match libraries from different toolkits into the same application. Its usually fairly obvious if you're going to use middleware which makes use of KDE, for example. But the situation were are talking about here is far more subtle -- because it potentially impacts *every* piece of C++ middleware, without any obvious way for the user to know which backend C++ libraries were used. How will developer using WhizzyWidgets++ library know which C++ library to use? And if they also want to use FancyFastNetwork library, which is built with a different library? (Then they are stuck..) > > He needs to say "here be dragons". He does not need to boil the > ocean. The Committed binding seems to imply (to me) an intent otherwise. > >> I think the submitter is trying to slide something "under the radar", > > You are reading too much into this. No conspiracy here, just a desire > to provide a library that are customers are *already* downloading and > using. Pandora's box is already open; this case doesn't make things > worse. If they are doing this, then why? We don't regularly see customers downloading GNU libc, even though it has some nice features that ours lacks. If the problem is our libraries suck goose eggs, then we need to make them stop sucking goose eggs. Even if that means replacing them with Apache stdc++. And, why aren't they downloading Dinkumware libraries? Or STLport5, or other implementations? At least with the explicit download, its clear that nobody should expect the library to be useful for uses outside of a project boundary. > >> and ignore the major issues that this is going to create. I'm >> extremely dissatisfied with any "not this case" kind of response to >> these issues. > > I'm really disappointed that the compiler team hasn't jumped in to this > discussion. Have they been contacted and invited? I think so, but I'm not certain. > >> Now, by way of a compromise, I *might* be satisfied with an addendum >> to this case that forbade shipping any middleware (read libraries) -- >> or at > > Forbade *who* from doing so? Sun? OpenSolaris? Nexenta? Schillix? > Slippery slope? Forbade any project from receiving ARC approval for such middleware libraries. Ultimately we can only withhold ARC approval -- we can't prevent anyone from shipping something if they want to ignore ARC approval. -- Garrett From gdamore@sun.com Tue Aug 26 23:06:00 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7R6601W025572 for ; Tue, 26 Aug 2008 23:06:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7R65xcI020876 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 23:06:00 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800201WXZ3E00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 23:05:59 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6800EQBWXY5930@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 23:05:58 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7R65wgQ007452 for ; Tue, 26 Aug 2008 23:05:58 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6800801WUCRB00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 23:05:58 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800CFKWXX7ID0@fe-sfbay-10.sun.com>; Tue, 26 Aug 2008 23:05:57 -0700 (PDT) Date: Tue, 26 Aug 2008 23:05:54 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B4EBC4.6060901@sun.com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Stefan Teleman , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48B4EEC2.8030603@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> <48B4E6DB.1040207@Sun.Com> <48B4EBC4.6060901@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1914 Garrett D'Amore wrote: > ` > The various GUI libraries are far less a concern, since generally > there is little desire to mix and match libraries from different > toolkits into the same application. Its usually fairly obvious if > you're going to use middleware which makes use of KDE, for example. > But the situation were are talking about here is far more subtle -- > because it potentially impacts *every* piece of C++ middleware, > without any obvious way for the user to know which backend C++ > libraries were used. > > How will developer using WhizzyWidgets++ library know which C++ > library to use? And if they also want to use FancyFastNetwork > library, which is built with a different library? (Then they are > stuck..) Another point here to consider: Unlike the GUI libraries, where generally source incompatibilities *force* one to pick one library or another, the choice of which C++ library comes down to selecting implementations. Many consumers of the C++ library may work with either implementation (i.e. barring use of certain unsupported features most code should be source compatible with multiple different implementations), and it will be incredibly difficult for consumers of middleware to know which libraries were used underneath. (One possible solution would be to confine libraries built against libstdc++ into a separate "namespace" -- kind of like the various perl5 version-specific ghettos. At least then there wouldn't be too many surprises.) The architecture presented in this case so far is just far too inadequate at the moment. But then again, if all we are interested in doing is saving folks the effort to download other components, and are becoming mere integrators, then there is no place for architecture and we should stop discussing things like this altogether. (And, IMO, probably stop having ARC review at all.) -- Garrett From gdamore@sun.com Wed Aug 27 22:34:50 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7S5YnvA012225 for ; Wed, 27 Aug 2008 22:34:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7S5YYZE012938 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 28 Aug 2008 13:34:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6A00H05Q5ZNJ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 27 Aug 2008 22:34:47 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6A00DMMQ5YJK30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 27 Aug 2008 22:34:46 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7S5YkPe028626 for ; Wed, 27 Aug 2008 22:34:46 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6A00301Q0LM200@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 27 Aug 2008 22:34:46 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6A00KR2Q5YSKF0@fe-sfbay-09.sun.com>; Wed, 27 Aug 2008 22:34:46 -0700 (PDT) Date: Wed, 27 Aug 2008 22:34:38 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B5C642.5010302@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John.Fischer@sun.com, PSARC-ext Message-id: <48B638EE.6090803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> <48B4E6DB.1040207@Sun.Com> <48B4EBC4.6060901@sun.com> <48B4EEC2.8030603@sun.com> <1219840807.9503.1415.camel@sr1-umpk-16> <48B5A23A.1060707@sun.com> <48B5A42B.6040800@Sun.COM> <48B5ACA3.4070409@sun.com> <48B5B306.2070208@Sun.COM> <48B5BEFF.9060400@sun.com> <48B5C642.5010302@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 9451 (Putting PSARC-ext back on distribution at request of Stefan.) Stefan Teleman wrote: > > > Garrett D'Amore wrote: >> It looks (from reading the README link you supplied) like there are >> some library utilities, localedef, etc. that are not part of your >> case but need to be. Your case materials are incomplete without a >> full list of what you intend to provide. > > These executables are not being delivered. the "locale" executable is > just a C++ version of the existing Solaris "locale" executable. There > is no need for this. OK. > > The "localedef" executable is a utility which only used at Library > build time, and which generates the character set conversion tables. > It plays no role after that, and it is not useful for inclusion. Ah, OK, sorry if I was confused from the Apache README. > >> The locations of the locale-specific data need to be fully exposed in >> the case materials as well. > > This location is provided in the ARC Case Materials, Appendix 2. > Please read all the ARC Case materials, completely. Sorry, I didn't see that. However, what I feel is still missing is how the data is manipulated. I.e., how do I generate l10n data. There is more than just a directory location here. (For example, with C's gettext(), I can use xgettext to extract data from the source, which can then be used to generate translations, and the translated files (whose format is specified in xgettext/gettext) can be stashed in documented location... you get the idea. Basically, anyone who is going to build a localized program, or provide localization data for such a program, needs to know certain information -- and that information is required in order for this case to be complete, IMO. > >> Saying your library provides i18n features without explaining *how* >> (or providing a link to a document that explains how) is inadequate. >> (And the Standard isn't sufficient either -- there are implementation >> specific behaviors that have to be specified as well.) > > What are these implementation specific behaviors ? How the implementation tracks down localized data, and what format it uses to interpret them. These are details of how users interact with the implementation that go beyond just the source code of the program. > > If they are implementation specific, therefore Project Private, why do > they have to be exposed as interfaces ? No. Implementation specific is *not* Project Private in this case. Unless you don't want to allow users to access any of those implementation specific details (which includes in this case the techniques used to publish locale specific data for new C++ programs.) > > Do any other ARC Cases which integrate external software document > Project Private implementation details ? Precedent, please. Again, not Project Private. But there are probably many precedents of publishing Project Private details. All one has to do is look for "Project Private" interface bindings in the ARC case log. Many Project Private details fall under the domain of "Architecture", even though ARC normally tends to focus on Interfaces. (See, for example, the cases associated with the FireEngine TCP stack in S10, which I think are almost entirely Project Private.) > > Do i also have to document all the private implementation details of > the std::iostream or std::string implementations ? Not if they are truly Project Private and not otherwise architectural. (I expect you don't need to, in other words.) > >> You still seem to be confusing the C++ ABI with the *binary* >> interfaces exposed by the library. (Binary interfaces are symbol >> names, semantics, etc.) Your library (all libraries!) offers an ABI, >> which is itself built upon the ABI supplied by the compiler. > > No, i am not confusing anything. > > Your understanding of ABI is valid in C. It is entirely inadequate, > and invalid, in C++. > > The Standard C++ Library is not just a shared library. It is also a > very large collection of templates, and classes. > > The classes provided in the Standard C++ Library contain virtual > methods. The presence of these methods determines the compiler to > create virtual tables, which become part of the binary representation > of the classes being compiled. Yes, I understand that. > > These templates provided by the Standard C++ Library are compiled > *into* the shared library, or executables, being built by the > consumer, including any and all virtual tables. These templates are > also compiled into the Standard C++ Library shared library being > delivered: libstdcxx.so.4 > > The consumer must link with the Standard C++ Library, libstdcxx.so.4. > In addition, the templates have been compiled into the application > built by the consumer. Yes, I understand that as well. > > As such, the ABI of the Library is comprised of everything i have > enumerated above: class definitions, class objects, automatic class > methods implicitly generated by the compiler, virtual tables, > constructors, destructors, assignment operators, exception handling, etc. Yes. But the *public* portions of those headers that were used (i.e. the parts that are specified in the Standard) should be common across multiple standards conformant libraries. The fact that the headers also include library-specific implementation details in the binary is *not* specific to C++. All one has to do is look at how certain macros are used in C. (The macro is part of the public source interface, but the binary bits it generates, which might includes in-code references to private structure fields, etc., are not.) The binary details constitute an ABI for applications working with that library (which consists of the shared object *and* the headers used with said shared object. > > The notion of ABI symbol names is non-sensical in C++. In any C++ > compiled binary, symbol names are mangled. The mangling algorithm is > implementation defined, and, actually the term "mangling" does not > appear in any of the 800+ pages which comprise the C++ Standard. It is > entirely implementation specific how any particular implementation > decides to handle C++ symbols. Of course, I get that. But that's a compiler artifact. The combination of compiler specific mangling (plus any other calling conventions used by the compiler) *and* the details in the headers for a library implementation together constitute an ABI. My understanding is that the C++ Standard does not specify an ABI. It *does* specify an API. Correct? > > The implementation always generates additional, mangled symbol names, > which are neither exposed, nor are they predictable to the consumer. > > The names of the interfaces exposed by the Standard C++ Library are > codified in the Standard. This is the Library API. This is what the > programmer writes code to. This is the Library API. We agree. I think the problem we are having is commitment level of the *API* versus the *ABI*. You can declare your API to have Committed binding -- however your *ABI* is where I have problems with your commitment level, and its also where the incompatibility problems lie. > > The semantics of the interfaces exposed by the Standard C++ Library are > > 1. Codified in the Standard > 2. Highly dependent on the context in which they are being used > 3. Highly dependent on the compilation context within which they were > used > > The actual names of the mangled symbols (ABI) are irrelevant, > inherently non-standard, non-portable, and implementation specific > private details. But those names seriously impact application compatibility. So while you might not document them in detail, the fact remains that they become part of an exported interface -- because without those no dynamically linked application could ever function properly. > >> Put another way: >> >> API = Source level compatibility >> ABI = Binary level compatibility >> >> If you know that the compiler group is planning something for the >> future, which should also support standards, then perhaps shipping >> this with Committed is inappropriate. Volatile might be better. > > Please raise these issues openly with PSARC-ext. I'm CC'ing them on this reply. I'm starting to think that if my concerns about insufficient specs are resolved, this case could be allowed to proceed, *IF* the case owner is willing to consider an amendment stating that developers should be aware that the library is likely to evolve in the future, and that binary compatibility should therefore not be relied upon. (In other words, we should retract any binary compatibility promises for this library, at least until a full case addressing the larger picture of compatibility concerns is made.) I do confess that this project being a fast track does feel to me a little like trying to shim KDE as a fast track. Sure lots of people download it, want it, use it, and we could do a lot of people a lot of favors by including it. But it also has some non-obvious issues (application compatibility between gnome and KDE being one good example), and I think it would be poor form to try to submit such a case as a fast track. If the only bar to a project integrating is that other people on the 'net use it, then there seems to be very little left for ARC to do. (Hmmm.... is a fast track for the Linux kernel coming soon?) -- Garrett From Stefan.Teleman@sun.com Thu Aug 28 16:33:00 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7SNWxw9013244 for ; Thu, 28 Aug 2008 16:32:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7SNWuJ9001475 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@Sun.COM>; Thu, 28 Aug 2008 17:32:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6C00H0R42YHQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 28 Aug 2008 16:32:58 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6C003NE42Y9190@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 28 Aug 2008 16:32:58 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7SNWvkl002238 for ; Thu, 28 Aug 2008 16:32:57 -0700 (PDT) Date: Thu, 28 Aug 2008 19:32:57 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library To: PSARC-EXT@sun.com Reply-to: Stefan Teleman Message-id: <48B735A9.1090700@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1470 -------- Original Message -------- Subject: Re: PSARC/2008/549 - Apache Standard C++ Library Date: Thu, 28 Aug 2008 16:26:44 -0700 From: Garrett D'Amore To: Stefan Teleman CC: John.Fischer@sun.com Th text below is the sum total of what I've been asking for about the i18n. Thank you. You should forward this to PSARC-ext@ so that it is recorded in the case materials. -- Garrett > The location of the message catalogs is specified via the NLSPATH env > var. > > Catalogs are opened via catopen(3C). Internally, in a very roundabout > way, this implementation does: > > nl_catd catd = nl_cat_open (cat_name.c_str(), NL_CAT_LOCALE); > > Messages from the opened catalog are retrieved via catgets(3C). > > --Stefan > > ------ > >> >> What you seem to be missing here is the requirement that if I'm going >> to write a C++ program that uses these facilities, then I >> *absolutely* need to know how to supply the localized data (down the >> precise format used in the messages database and the method used to >> determine which local-specific catalog is used!) Otherwise, its a >> black box and I can't localize a program! >> >> Think about someone trying to use these facilities and you'll see >> what I mean. (I mean more than just the programmer, but the l10n >> teams that are going to have to deal with them.) >> >> -- Garrett >> > -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gdamore@Sun.COM Wed Sep 3 10:01:38 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m83H1cIR025482 for ; Wed, 3 Sep 2008 10:01:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m83H1bh8046701 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Sep 2008 11:01:37 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6M00G0BPYOBC00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 10:01:36 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6M00FIYPYMPS00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 10:01:34 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m83H1Yrl010349 for ; Wed, 03 Sep 2008 10:01:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6M00301NRPSB00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 10:01:34 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6M0001WPYLP7H0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 10:01:33 -0700 (PDT) Date: Wed, 03 Sep 2008 10:00:55 -0700 From: "Garrett D'Amore" Subject: PSARC 2008/549 Apache Standard C++ Library Sender: Garrett.Damore@Sun.COM To: PSARC-ext Message-id: <48BEC2C7.9060000@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2437 I think most of my concerns, while not fully addressed, are nearing to a semi-satisfactory state. I still have concerns about binary compatibility, and I don't think the project team has adequately presented an answer to the following two questions: 1) how will we alert users/developers to the dangers (binary compatibility dangers, that is) of using this library 2) how will this project fit into any long term strategy with respect to C++ standards conformance The lack of (or appearance thereof) a long term strategy with respect to C++ standards conformance is something I find deeply unsettling. The fact that libraries compiled against this library will be incompatible with libraries compiled against other "default" libraries is only moderately unsettled -- but the fact that developers will have no way to apriori identify what the compatibility issues between "middleware" libraries is a serious shortcoming, and one that I think should be fixed if we're going to make any kinds of promises here. One way the team could help address my concerns would be to declare the *source code* interfaces to be Committed, but avoid granting that status to the binary interfaces. (And yes, the library has binary interfaces -- I'm not talking about the C++ ABI here, but the combination of ABI from the compiler and binary interfaces that result from compiling this library's header files.) Another mitigating approach would be to request/require that middleware developed on top of this library somehow name their libraries (perhaps by placing them in a directory) so that the linkage compatibility issues are made explicit. This could also help address the situation when we need (as I suspect we will) to change the binary interfaces when a new version of the library is included/shipped. Another approach might be for other projects (KDE) that need this library perhaps a solution involving autoconf style pkg-config to specify compiler options, along with a contract for the use of the interfaces, might be another approach. In any case, I'd like to request that the timeout for this case be extended until the next public PSARC meeting (i.e. Sept. 10). Its possible that the best solution here would be to derail and subsequently approve the case, so that the ARC can supply an opinion requesting Sun mgmt to fund additional work to address the problematic gaps here. -- Garrett From John.Plocher@sun.com Wed Sep 3 11:38:39 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m83Icds4001903 for ; Wed, 3 Sep 2008 11:38:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m83IcYpM015774 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Sep 2008 12:38:38 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6M0030DUGE7Z00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 11:38:38 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6M00FIYUGEPH60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 11:38:38 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m83IccFT023313 for ; Wed, 03 Sep 2008 11:38:38 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6M00201UEA0500@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 11:38:38 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6M00D6IUGBYH90@fe-sfbay-10.sun.com>; Wed, 03 Sep 2008 11:38:35 -0700 (PDT) Date: Wed, 03 Sep 2008 11:38:33 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48B4E6DB.1040207@Sun.Com> Sender: John.Plocher@sun.com To: Stefan Teleman Cc: John Plocher , John.Fischer@sun.com, PSARC-ext@sun.com, Stephen.Clamage@sun.com Message-id: <48BED9A9.4030306@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> <48B4E6DB.1040207@Sun.Com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 892 John Plocher wrote on the 26th of September: > I'm really disappointed that the compiler team hasn't jumped in to this > discussion. Have they been contacted and invited? I just got the following from Steve Clamage, one of the lead engineers on the compiler team: > I was only today made aware of this PSARC case, and I would like to > derail the fast-track if it is not too late. I knew the topic was > being discussed, and contributed negative comments to those who > mentioned it to me. In short, I think the proposal is counter-productive, > makes false statements of fact, and will not (and cannot) have the > good effects it claims. Please consider this fasttrack case derailed. The next step is for Stefan and Steve to get together [somewhere not on the PSARC aliases] and discuss these issues, and to then come back with their resolutions and/or an updated proposal. -John From gdamore@sun.com Wed Sep 3 12:37:15 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m83JbFb7003351 for ; Wed, 3 Sep 2008 12:37:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m83JbEkB028825 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Sep 2008 12:37:14 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6M00805X61J900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 12:37:13 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6M00FL5X61PZA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 12:37:13 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m83JbDDv021175 for ; Wed, 03 Sep 2008 12:37:13 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6M00401WTS9D00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 12:37:13 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6M0018TX5XNU40@fe-sfbay-10.sun.com>; Wed, 03 Sep 2008 12:37:10 -0700 (PDT) Date: Wed, 03 Sep 2008 12:36:31 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48BED9A9.4030306@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Stefan Teleman , John.Fischer@sun.com, PSARC-ext@sun.com, Stephen.Clamage@sun.com Message-id: <48BEE73F.5000003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> <48B4E6DB.1040207@Sun.Com> <48BED9A9.4030306@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1354 I'm not sure if members of other ARCs (LSARC) can derail PSARC cases. If so, then no problem here. If not, please take this message as indicating that I am derailing this case (in other words, if John can't derail it, then I can.) As one of the more vociferous detractors for this case, it probably would be a good idea to CC me on the conversation between Stefan and Steve. -- Garrett John Plocher wrote: > John Plocher wrote on the 26th of September: >> I'm really disappointed that the compiler team hasn't jumped in to this >> discussion. Have they been contacted and invited? > > I just got the following from Steve Clamage, one of the lead engineers > on the compiler team: > >> I was only today made aware of this PSARC case, and I would like to >> derail the fast-track if it is not too late. I knew the topic was >> being discussed, and contributed negative comments to those who >> mentioned it to me. In short, I think the proposal is >> counter-productive, >> makes false statements of fact, and will not (and cannot) have the >> good effects it claims. > > Please consider this fasttrack case derailed. The next step is for > Stefan > and Steve to get together [somewhere not on the PSARC aliases] and > discuss > these issues, and to then come back with their resolutions and/or an > updated > proposal. > > -John > > From John.Fischer@sun.com Wed Sep 3 13:06:13 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m83K6CrY004537 for ; Wed, 3 Sep 2008 13:06:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m83K64mD012560 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Sep 2008 21:06:11 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6M00B05YIARX00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 13:06:10 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6M00FWAYI9PTB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 13:06:10 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m83K692d025039 for ; Wed, 03 Sep 2008 13:06:09 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6M00A01XODRS00@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 13:06:09 -0700 (PDT) Received: from [192.168.10.13] ([76.20.56.47]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6M0092AYI8P4G0@fe-sfbay-09.sun.com>; Wed, 03 Sep 2008 13:06:09 -0700 (PDT) Date: Wed, 03 Sep 2008 13:06:01 -0700 From: John Fischer Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48BEE73F.5000003@sun.com> Sender: John.Fischer@sun.com To: "Garrett D'Amore" Cc: John Plocher , Stefan Teleman , PSARC-ext@sun.com, Stephen.Clamage@sun.com, John Fischer Reply-to: John.Fischer@sun.com Message-id: <48BEEE29.10106@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> <48B4E6DB.1040207@Sun.Com> <48BED9A9.4030306@Sun.Com> <48BEE73F.5000003@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 1606 PSARC, Sorry I missed the meeting today. I had to cover a Solaris P-Team meeting for my organization. I'll work with Stefan and Steve Clamage to resolve issues. Thanks, John Garrett D'Amore wrote: > I'm not sure if members of other ARCs (LSARC) can derail PSARC cases. > If so, then no problem here. If not, please take this message as > indicating that I am derailing this case (in other words, if John can't > derail it, then I can.) > > As one of the more vociferous detractors for this case, it probably > would be a good idea to CC me on the conversation between Stefan and Steve. > > -- Garrett > > John Plocher wrote: >> John Plocher wrote on the 26th of September: >>> I'm really disappointed that the compiler team hasn't jumped in to this >>> discussion. Have they been contacted and invited? >> >> I just got the following from Steve Clamage, one of the lead engineers >> on the compiler team: >> >>> I was only today made aware of this PSARC case, and I would like to >>> derail the fast-track if it is not too late. I knew the topic was >>> being discussed, and contributed negative comments to those who >>> mentioned it to me. In short, I think the proposal is >>> counter-productive, >>> makes false statements of fact, and will not (and cannot) have the >>> good effects it claims. >> >> Please consider this fasttrack case derailed. The next step is for >> Stefan >> and Steve to get together [somewhere not on the PSARC aliases] and >> discuss >> these issues, and to then come back with their resolutions and/or an >> updated >> proposal. >> >> -John >> >> > From bart.smaalders@Sun.COM Wed Sep 3 16:47:56 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m83NlteW016621 for ; Wed, 3 Sep 2008 16:47:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m83Nls6b057725; Wed, 3 Sep 2008 17:47:54 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6N00M018RUIS00@brm-avmta-1.central.sun.com>; Wed, 03 Sep 2008 17:47:54 -0600 (MDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6N00H1P8RT4H50@brm-avmta-1.central.sun.com>; Wed, 03 Sep 2008 17:47:53 -0600 (MDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m83Nlqgl029061; Wed, 03 Sep 2008 23:47:52 +0000 (GMT) Date: Wed, 03 Sep 2008 16:47:52 -0700 From: Bart Smaalders Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48BED9A9.4030306@Sun.Com> To: John Plocher Cc: Stefan Teleman , John.Fischer@Sun.COM, PSARC-ext@Sun.COM, Stephen.Clamage@Sun.COM Message-id: <48BF2228.4040206@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> <48B4E6DB.1040207@Sun.Com> <48BED9A9.4030306@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 1406 John Plocher wrote: > John Plocher wrote on the 26th of September: >> I'm really disappointed that the compiler team hasn't jumped in to this >> discussion. Have they been contacted and invited? > > I just got the following from Steve Clamage, one of the lead engineers > on the compiler team: > >> I was only today made aware of this PSARC case, and I would like to >> derail the fast-track if it is not too late. I knew the topic was >> being discussed, and contributed negative comments to those who >> mentioned it to me. In short, I think the proposal is counter-productive, >> makes false statements of fact, and will not (and cannot) have the >> good effects it claims. > > Please consider this fasttrack case derailed. The next step is for Stefan > and Steve to get together [somewhere not on the PSARC aliases] and discuss > these issues, and to then come back with their resolutions and/or an > updated > proposal. > > -John > > I'd love to see a more detailed explanation of the material issues in this case. Whatever Steve has asserted may very well be true, but derailing a case based on unspecific assertions via excerpted mail seems dubious, and then burying the discussion off-line doesn't help. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From gww@eng.sun.com Wed Sep 3 17:36:46 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m840ajQm019295 for ; Wed, 3 Sep 2008 17:36:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m840aiaq022787 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 01:36:45 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6N00201B18WL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 18:36:44 -0600 (MDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6N00H6BB174H80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 18:36:43 -0600 (MDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m840ahbp009660; Wed, 03 Sep 2008 17:36:43 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m840Wpph025588; Wed, 03 Sep 2008 17:32:51 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m840WpO6025587; Wed, 03 Sep 2008 17:32:51 -0700 (PDT) Date: Wed, 03 Sep 2008 17:32:51 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC/2008/549 - Apache Standard C++ Library To: John.Plocher@sun.com, bart.smaalders@sun.com Cc: Stefan.Teleman@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stephen.Clamage@sun.com Message-id: <200809040032.m840WpO6025587@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 780 > > Please consider this fasttrack case derailed. The next step is for Stefan > > and Steve to get together [somewhere not on the PSARC aliases] and discuss > > these issues, and to then come back with their resolutions and/or an > > updated > > proposal. > > > > -John > > > > > > I'd love to see a more detailed explanation of the material issues in > this case. > > Whatever Steve has asserted may very well be true, but derailing a > case based on unspecific assertions via excerpted mail seems dubious, > and then burying the discussion off-line doesn't help. The status is still waiting fast-track, so looks like no one has officially derailed. Perhaps "discussing" would be a better official status. Seems like Stefan and Steve are aligned to chat. Gary.. From Stefan.Teleman@sun.com Wed Sep 3 17:37:56 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m840butJ019549 for ; Wed, 3 Sep 2008 17:37:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m840boQq023145; Thu, 4 Sep 2008 01:37:52 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6N00301B33XK00@nwk-avmta-2.sfbay.sun.com>; Wed, 03 Sep 2008 17:37:51 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6N001H7B333R30@nwk-avmta-2.sfbay.sun.com>; Wed, 03 Sep 2008 17:37:51 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m840bneY019942; Wed, 03 Sep 2008 17:37:50 -0700 (PDT) Date: Wed, 03 Sep 2008 20:37:49 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <200809040032.m840WpO6025587@marduk.eng.sun.com> To: Gary Winiger Cc: John.Plocher@sun.com, bart.smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stephen.Clamage@sun.com Reply-to: Stefan Teleman Message-id: <48BF2DDD.6060105@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809040032.m840WpO6025587@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 328 Gary Winiger wrote: > The status is still waiting fast-track, so looks like no one > has officially derailed. Perhaps "discussing" would be a better > official status. Seems like Stefan and Steve are aligned to chat. And chatting we are. :-) --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gdamore@sun.com Wed Sep 3 20:50:45 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m843oiFV022557 for ; Wed, 3 Sep 2008 20:50:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m843oYnJ022553 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 11:50:43 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6N00D01K0H9F00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 20:50:41 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6N001LRK0H3LD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 20:50:41 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m843ofDJ011420 for ; Wed, 03 Sep 2008 20:50:41 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6N00701K0B3Y00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Sep 2008 20:50:41 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6N00JAIK0GJRB0@fe-sfbay-10.sun.com>; Wed, 03 Sep 2008 20:50:40 -0700 (PDT) Date: Wed, 03 Sep 2008 20:50:00 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <200809040032.m840WpO6025587@marduk.eng.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: John.Plocher@sun.com, Bart.Smaalders@sun.com, Stefan.Teleman@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stephen.Clamage@sun.com Message-id: <48BF5AE8.1050505@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809040032.m840WpO6025587@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1115 Gary Winiger wrote: >>> Please consider this fasttrack case derailed. The next step is for Stefan >>> and Steve to get together [somewhere not on the PSARC aliases] and discuss >>> these issues, and to then come back with their resolutions and/or an >>> updated >>> proposal. >>> >>> -John >>> >>> >>> >> I'd love to see a more detailed explanation of the material issues in >> this case. >> I believe that I offered a lot of detail about my material concerns in this case. Please go back in the mail log. >> Whatever Steve has asserted may very well be true, but derailing a >> case based on unspecific assertions via excerpted mail seems dubious, >> and then burying the discussion off-line doesn't help. >> > > The status is still waiting fast-track, so looks like no one > has officially derailed. Perhaps "discussing" would be a better > official status. Seems like Stefan and Steve are aligned to chat. > I thought John officially derailed it. At this point, if John doesn't derail it, then I will -- if only so that we can offer some much needed advice. -- Garrett From John.Plocher@sun.com Wed Sep 3 22:17:52 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m845HpYR025556 for ; Wed, 3 Sep 2008 22:17:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m845Hfmn019371 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 13:17:50 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6N00H03O1NLX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 03 Sep 2008 22:17:47 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6N00EGJO1NR530@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 03 Sep 2008 22:17:47 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m845HlrZ013902 for ; Wed, 03 Sep 2008 22:17:47 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6N00001NXJ7P00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 03 Sep 2008 22:17:47 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6N00322O1FRTE0@fe-sfbay-09.sun.com>; Wed, 03 Sep 2008 22:17:46 -0700 (PDT) Date: Wed, 03 Sep 2008 22:17:37 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48BF5AE8.1050505@sun.com> Sender: John.Plocher@sun.com To: "Garrett D'Amore" Cc: Gary Winiger , Bart.Smaalders@sun.com, Stefan.Teleman@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stephen.Clamage@sun.com Message-id: <48BF6F71.5090505@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809040032.m840WpO6025587@marduk.eng.sun.com> <48BF5AE8.1050505@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 986 Garrett D'Amore wrote: > I thought John officially derailed it. > > At this point, if John doesn't derail it, then I will -- if only so that > we can offer some much needed advice. My afternoon has been pretty hectic, and I am just now following up on the dozen or so things I should have gotten done earlier... After some more thought, derailing the case is premature; stopping the clock and keeping it from auto-approving before the compiler team's perspective is injected into the conversation is what is important. So, the case is in "waiting need spec" state, waiting for Steve and Stefan (and whomever else feels the spirit moving in them) to mind-meld... I would like to hear back from Stefan and Steve on their discussion; in particular, if they still have a large disconnect. To Bart's comment, after the mind meld, I would like Steve to come up with a more ARC-actionable list of concerns if he still feels that this case should derail into a full review. -John From Stephen.Clamage@sun.com Thu Sep 4 07:48:54 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84Ems6P011110 for ; Thu, 4 Sep 2008 07:48:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84Emcu1016807 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 07:48:54 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00I0PEHGYI00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 04 Sep 2008 08:48:52 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O005PVEHFWQC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 04 Sep 2008 08:48:51 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84Empsa028143 for ; Thu, 04 Sep 2008 07:48:51 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00601CWT6700@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 04 Sep 2008 07:48:51 -0700 (PDT) Received: from [129.146.86.208] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O001KJEHAV490@fe-sfbay-09.sun.com>; Thu, 04 Sep 2008 07:48:47 -0700 (PDT) Date: Thu, 04 Sep 2008 07:48:46 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48BF6F71.5090505@Sun.Com> Sender: Stephen.Clamage@sun.com To: John Plocher Cc: "Garrett D'Amore" , Gary Winiger , Bart.Smaalders@sun.com, Stefan.Teleman@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48BFF54E.7040701@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809040032.m840WpO6025587@marduk.eng.sun.com> <48BF5AE8.1050505@sun.com> <48BF6F71.5090505@Sun.Com> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 1980 On 09/03/08 22:17, John Plocher wrote: > Garrett D'Amore wrote: >> I thought John officially derailed it. >> >> At this point, if John doesn't derail it, then I will -- if only so >> that we can offer some much needed advice. > > > My afternoon has been pretty hectic, and I am just now > following up on the dozen or so things I should have > gotten done earlier... > > After some more thought, derailing the case is premature; > stopping the clock and keeping it from auto-approving before > the compiler team's perspective is injected into the > conversation is what is important. > > So, the case is in "waiting need spec" state, waiting for > Steve and Stefan (and whomever else feels the spirit moving > in them) to mind-meld... > > I would like to hear back from Stefan and Steve on their > discussion; in particular, if they still have a large > disconnect. To Bart's comment, after the mind meld, I > would like Steve to come up with a more ARC-actionable > list of concerns if he still feels that this case should > derail into a full review. > > -John As we were requested to do, Stefan and I are conducting an off-line discussion of the issues. Garrett D'Amore and John Fischer asked to be included in the discussion. I can forward copies of the email exchanges so far to anyone else who is interested, and include you in future cc lists. The short version of my position is that the Apache headers and runtime libraries should not be part of an ON consolidation, but should be provided by the Sun Studio compiler team. The headers should be part of the compiler, not installed in /usr/include, and the runtime libraries should be delivered into Solaris by the Sun Studio team just as other C++ runtime libraries are currently delivered. The C++ compiler team already has plans to do what I suggest, but we were planning to do it in a future compiler release. We could move more quickly, if necessary. --- Steve Clamage, stephen.clamage@sun.com From Michael.Schuster@sun.com Thu Sep 4 10:11:45 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84HBiQZ016794 for ; Thu, 4 Sep 2008 10:11:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m84HBXCF000121 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 18:11:43 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O0092VL3HOR00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 10:11:41 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O003CPL3GC7E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 10:11:40 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84HBeDD018177 for ; Thu, 04 Sep 2008 10:11:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00F01KZA1W00@fe-sfbay-09.sun.com> (original mail from Michael.Schuster@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 10:11:40 -0700 (PDT) Received: from [129.146.106.37] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O002YUL3A43B0@fe-sfbay-09.sun.com>; Thu, 04 Sep 2008 10:11:34 -0700 (PDT) Date: Thu, 04 Sep 2008 10:11:34 -0700 From: Michael Schuster Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48BFF54E.7040701@sun.com> Sender: Michael.Schuster@sun.com To: Steve Clamage Cc: John Plocher , "Garrett D'Amore" , Gary Winiger , Bart.Smaalders@sun.com, Stefan.Teleman@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48C016C6.1090506@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809040032.m840WpO6025587@marduk.eng.sun.com> <48BF5AE8.1050505@sun.com> <48BF6F71.5090505@Sun.Com> <48BFF54E.7040701@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080714) Status: RO Content-Length: 902 On 09/04/08 07:48, Steve Clamage wrote: > The short version of my position is that the Apache headers and runtime > libraries should not be part of an ON consolidation, but should be > provided by the Sun Studio compiler team. The headers should be part of > the compiler, not installed in /usr/include, and the runtime libraries > should be delivered into Solaris by the Sun Studio team just as other > C++ runtime libraries are currently delivered. > > The C++ compiler team already has plans to do what I suggest, but we > were planning to do it in a future compiler release. We could move more > quickly, if necessary. would it be unreasonable to ask for a committment date from the compiler team for this delivery, to be recorded in this case, given that Stefan could integrate in a few days? Michael -- Michael Schuster http://blogs.sun.com/recursion Recursion, n.: see 'Recursion' From gww@sac.sfbay.sun.com Thu Sep 4 10:41:00 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84Hf0O0017903 for ; Thu, 4 Sep 2008 10:41:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84HexoZ000010; Thu, 4 Sep 2008 10:41:00 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00C0FMGBJX00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Sep 2008 10:40:59 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O00AY3MGAOE10@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Sep 2008 10:40:59 -0700 (PDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m84Heva4003418; Thu, 04 Sep 2008 10:40:57 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84Hev5W017900; Thu, 04 Sep 2008 10:40:57 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m84HevPa017899; Thu, 04 Sep 2008 10:40:57 -0700 (PDT) Date: Thu, 04 Sep 2008 10:40:57 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC/2008/549 - Apache Standard C++ Library To: Joep.Vesseur@sun.com, John.Plocher@sun.com, Stephen.Clamage@sun.com Cc: Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stefan.Teleman@sun.com, gdamore@sun.com, gww@eng.sun.com Message-id: <200809041740.m84HevPa017899@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 820 > The short version of my position is that the Apache headers and runtime > libraries should not be part of an ON consolidation, but should be > provided by the Sun Studio compiler team. The headers should be part of > the compiler, not installed in /usr/include, and the runtime libraries > should be delivered into Solaris by the Sun Studio team just as other > C++ runtime libraries are currently delivered. My understanding is that such things as KDE depend on this library. If correct, is the proposal that Sun Studio needs to be purchased/installed in order to run KDE? Gary.. > > The C++ compiler team already has plans to do what I suggest, but we > were planning to do it in a future compiler release. We could move more > quickly, if necessary. > > --- > Steve Clamage, stephen.clamage@sun.com > From Stephen.Clamage@sun.com Thu Sep 4 10:56:01 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84Hu11W018713 for ; Thu, 4 Sep 2008 10:56:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84Htv0D005206 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 10:56:01 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O0081RN5C5F00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 11:56:00 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O0063DN5BY610@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 11:55:59 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84HtxbL025085 for ; Thu, 04 Sep 2008 10:55:59 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00901MJJ3F00@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 10:55:59 -0700 (PDT) Received: from [129.146.86.208] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00F5FN52CU50@fe-sfbay-09.sun.com>; Thu, 04 Sep 2008 10:55:51 -0700 (PDT) Date: Thu, 04 Sep 2008 10:55:50 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <200809041740.m84HevPa017899@sac.sfbay.sun.com> Sender: Stephen.Clamage@sun.com To: Gary Winiger Cc: Joep.Vesseur@sun.com, John.Plocher@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stefan.Teleman@sun.com, gdamore@sun.com, gww@eng.sun.com Message-id: <48C02126.3060000@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 1742 Only the libstdcxx runtime libraries would be needed to use the application, and they will be part of Solaris. You would not need access to a Sun Studio installation to run the application. More generally: - Sun Studio is free, just like Solaris. You can use it at no cost to create applications that you then sell. (Support is not free.) - Some runtime libraries that might be used by an application built with Sun Studio are not installed with Solaris. Those libraries are freely distributable with the application. Example: Sun Studio includes a garbage-collecting library, libgc. If you choose to use it as part of an application, you can freely distribute libgc with your application. In short, building an application with Sun Studio never requires that application users have access to Sun Studio. --- Steve Clamage, stephen.clamage@sun.com On 09/04/08 10:40, Gary Winiger wrote: >> The short version of my position is that the Apache headers and runtime >> libraries should not be part of an ON consolidation, but should be >> provided by the Sun Studio compiler team. The headers should be part of >> the compiler, not installed in /usr/include, and the runtime libraries >> should be delivered into Solaris by the Sun Studio team just as other >> C++ runtime libraries are currently delivered. > > My understanding is that such things as KDE depend on this library. > If correct, is the proposal that Sun Studio needs to be > purchased/installed in order to run KDE? > > Gary.. >> The C++ compiler team already has plans to do what I suggest, but we >> were planning to do it in a future compiler release. We could move more >> quickly, if necessary. >> >> --- >> Steve Clamage, stephen.clamage@sun.com >> From Nicolas.Williams@sun.com Thu Sep 4 11:01:43 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84I1gsU018955 for ; Thu, 4 Sep 2008 11:01:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m84I1ZMc021637; Thu, 4 Sep 2008 19:01:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00E1ZNEQKY00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Sep 2008 11:01:38 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O00AY2NEOO530@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Sep 2008 11:01:36 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m84I1Ych002245; Thu, 04 Sep 2008 13:01:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m84I1X3W002244; Thu, 04 Sep 2008 13:01:33 -0500 (CDT) Date: Thu, 04 Sep 2008 13:01:33 -0500 From: Nicolas Williams Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <200809041740.m84HevPa017899@sac.sfbay.sun.com> To: Gary Winiger Cc: Joep.Vesseur@sun.com, John.Plocher@sun.com, Stephen.Clamage@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stefan.Teleman@sun.com, gdamore@sun.com, gww@eng.sun.com Message-id: <20080904180133.GX1524@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1847 On Thu, Sep 04, 2008 at 10:40:57AM -0700, Gary Winiger wrote: > > The short version of my position is that the Apache headers and runtime > > libraries should not be part of an ON consolidation, but should be > > provided by the Sun Studio compiler team. The headers should be part of > > the compiler, not installed in /usr/include, and the runtime libraries > > should be delivered into Solaris by the Sun Studio team just as other > > C++ runtime libraries are currently delivered. > > My understanding is that such things as KDE depend on this library. > If correct, is the proposal that Sun Studio needs to be > purchased/installed in order to run KDE? The C++ runtime and misc. libraries, like the C runtime and misc. libraries, need to be part of the installed system, not part of the compiler suite, at least if the runtime takes the form of shared ELF objects (as opposed to being statically linked). The fact that there exist ABI incompatibilities between different compilers and even different versions of the same compiler, and the need (I assume!) to ship BOTH Sun Studio AND g++ means that we have to find a way to deal with multiple C++ runtimes and libraries. I could be wrong about this assumption. Perhaps we can ship just one of these C++ compilers, but I doubt it. It'd be nice to have similar functionality in Sun Studio and g++, but given the C++ ABI issues that can't be the most important issue from the ARC's point of view, right? It's got to be to find a way for libraries built with both compilers to be available on the installed system, and to find a way to keep from confusing developers. That is, IMO, we should bite the bullet and deal with the multiplicity of C++ ABIs. We should, of course, try to keep those to an absolute minimum (that would 2, until g++ breaks its ABI next anyways). Nico -- From gdamore@Sun.COM Thu Sep 4 11:20:14 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84IKERm019865 for ; Thu, 4 Sep 2008 11:20:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84IK9lu014309 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 11:20:13 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O0022TO9NXZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 11:20:12 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O002L6O9NNN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 11:20:11 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84IKANQ029571 for ; Thu, 04 Sep 2008 11:20:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00N01NZC2500@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 11:20:10 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00586O9DIC10@fe-sfbay-09.sun.com>; Thu, 04 Sep 2008 11:20:02 -0700 (PDT) Date: Thu, 04 Sep 2008 11:19:18 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C02126.3060000@sun.com> Sender: Garrett.Damore@Sun.COM To: Steve Clamage Cc: Gary Winiger , Joep.Vesseur@Sun.COM, John.Plocher@Sun.COM, Bart.Smaalders@Sun.COM, John.Fischer@Sun.COM, PSARC-ext@Sun.COM, Stefan.Teleman@Sun.COM, gww@eng.sun.com Message-id: <48C026A6.9000107@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <48C02126.3060000@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2090 Steve Clamage wrote: > Only the libstdcxx runtime libraries would be needed to use the > application, and they will be part of Solaris. You would not need > access to a Sun Studio installation to run the application. > > More generally: > > - Sun Studio is free, just like Solaris. You can use it at no cost to > create applications that you then sell. (Support is not free.) > > - Some runtime libraries that might be used by an application built > with Sun Studio are not installed with Solaris. Those libraries are > freely distributable with the application. Example: Sun Studio > includes a garbage-collecting library, libgc. If you choose to use it > as part of an application, you can freely distribute libgc with your > application. > > In short, building an application with Sun Studio never requires that > application users have access to Sun Studio. There are actually better cases where the compiler folks provide bits that are delivered *with* Solaris (but in a separate consolidation from ON). libm, libC, etc. I'd recommend that this apache libstdc++ could be handled the same way. -- Garrett > > --- > Steve Clamage, stephen.clamage@sun.com > > > On 09/04/08 10:40, Gary Winiger wrote: >>> The short version of my position is that the Apache headers and runtime >>> libraries should not be part of an ON consolidation, but should be >>> provided by the Sun Studio compiler team. The headers should be part >>> of the compiler, not installed in /usr/include, and the runtime >>> libraries should be delivered into Solaris by the Sun Studio team >>> just as other C++ runtime libraries are currently delivered. >> >> My understanding is that such things as KDE depend on this library. >> If correct, is the proposal that Sun Studio needs to be >> purchased/installed in order to run KDE? >> >> Gary.. >>> The C++ compiler team already has plans to do what I suggest, but we >>> were planning to do it in a future compiler release. We could move >>> more quickly, if necessary. >>> >>> --- >>> Steve Clamage, stephen.clamage@sun.com >>> From gdamore@sun.com Thu Sep 4 11:28:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84ISFpJ020000 for ; Thu, 4 Sep 2008 11:28:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m84IS3kq020215 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 02:28:14 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00A13ON18A00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:28:13 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O006PJON1Y630@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:28:13 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84ISCtn000810 for ; Thu, 04 Sep 2008 11:28:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00A01LOAKP00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 11:28:12 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00EZ6OMOQ0D0@fe-sfbay-10.sun.com>; Thu, 04 Sep 2008 11:28:01 -0700 (PDT) Date: Thu, 04 Sep 2008 11:27:17 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <20080904180133.GX1524@Sun.COM> Sender: Garrett.Damore@sun.com To: Nicolas Williams Cc: Gary Winiger , Joep.Vesseur@sun.com, John.Plocher@sun.com, Stephen.Clamage@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stefan.Teleman@sun.com, gww@eng.sun.com Message-id: <48C02885.30709@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3436 Nicolas Williams wrote: > On Thu, Sep 04, 2008 at 10:40:57AM -0700, Gary Winiger wrote: > >>> The short version of my position is that the Apache headers and runtime >>> libraries should not be part of an ON consolidation, but should be >>> provided by the Sun Studio compiler team. The headers should be part of >>> the compiler, not installed in /usr/include, and the runtime libraries >>> should be delivered into Solaris by the Sun Studio team just as other >>> C++ runtime libraries are currently delivered. >>> >> My understanding is that such things as KDE depend on this library. >> If correct, is the proposal that Sun Studio needs to be >> purchased/installed in order to run KDE? >> > > The C++ runtime and misc. libraries, like the C runtime and misc. > libraries, need to be part of the installed system, not part of the > compiler suite, at least if the runtime takes the form of shared ELF > objects (as opposed to being statically linked). > > The fact that there exist ABI incompatibilities between different > compilers and even different versions of the same compiler, and the need > (I assume!) to ship BOTH Sun Studio AND g++ means that we have to find a > way to deal with multiple C++ runtimes and libraries. I could be wrong > about this assumption. Perhaps we can ship just one of these C++ > compilers, but I doubt it. > > It'd be nice to have similar functionality in Sun Studio and g++, but > given the C++ ABI issues that can't be the most important issue from the > ARC's point of view, right? It's got to be to find a way for libraries > built with both compilers to be available on the installed system, and > to find a way to keep from confusing developers. > > That is, IMO, we should bite the bullet and deal with the multiplicity > of C++ ABIs. We should, of course, try to keep those to an absolute > minimum (that would 2, until g++ breaks its ABI next anyways). > And in fact, I've suggested that we do just this -- deliver the libstdc++ as a separate consolidation (or perhaps with other Studio-supplied consolidations -- libm, libC). The consolidation could have binaries for both gcc and Studio supplied. Somehow, I do think we need to have separate library search paths for g++ versus Studio. Maybe we already do -- I don't use C++ so its not a problem I normally need to worry about. I confess I'd rather have the library developed and supplied by the studio folks. The reasons for this are: 1) the studio folks can then add supporting switches (and runtime detection) for the library to the compilers 2) there is far less likely to be binary interface breakage if only one entity is delivering binaries from a single source repo 3) the studio folks can also address include and library search path problems properly in their compilers 4) makes it easier to deal with making this available for S10 updates as well (only a single common source repo, no need for separate source trees) All that said, I'm willing to yield on these issues *if* the project team and the Studio team can come to an agreement which will provide a promise of *binary* and *source* compatibility both, for applications going forward. (Put another way, if my compatibility concerns, which are the main issues I have at stake here, can be suitably resolved by the parties concerned -- both the project team and the compiler folks, then I'm happy.) -- Garrett From Stephen.Clamage@Sun.COM Thu Sep 4 11:49:26 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84InQO2020558 for ; Thu, 4 Sep 2008 11:49:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84InPYu029543 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 11:49:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O0030BPMBZF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 11:49:23 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O00206PMBNK30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 11:49:23 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84InNHx003909 for ; Thu, 04 Sep 2008 11:49:23 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00J01OIT1000@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 11:49:23 -0700 (PDT) Received: from [129.146.86.208] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O005NRPM8ICG0@fe-sfbay-09.sun.com>; Thu, 04 Sep 2008 11:49:20 -0700 (PDT) Date: Thu, 04 Sep 2008 11:49:19 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C02885.30709@sun.com> Sender: Stephen.Clamage@Sun.COM To: "Garrett D'Amore" Cc: Nicolas Williams , Gary Winiger , Joep.Vesseur@Sun.COM, John.Plocher@Sun.COM, Bart.Smaalders@Sun.COM, John.Fischer@Sun.COM, PSARC-ext@Sun.COM, Stefan.Teleman@Sun.COM, gww@eng.sun.com Message-id: <48C02DAF.1090302@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 1760 Regarding g++, let's take a step back. There is nothing special about the Apache library. It is an implementation of the API (programming interface) described by the C++ standard. *We* care about it because the two implementations of the C++ standard library currently supplied with Sun Studio are each missing features that some applications need. ("Why" is a long story.) If you write to the C++ standard API, it should not matter which implementation you use. It will matter only if you have a deficient implementation. (Missing features, non-standard behavior, or poor performance, for example.) G++ comes with its own implementation of the C++ standard library that is quite standard-conforming. You should be able to build the apps with g++ without the Apache library. (If you have tried and found that they don't work, I would be surprised, because nearly all Open Source apps are developed using gcc, then tweaked to work with other compilers.) I think that if we created a version of libstdcxx built with g++, there would be no users. Using libstdcxx with g++ has at least the same issues as using libcstdcxx with Sun Studio without direct compiler support -- command lines get rather tricky. And it's not clear that libstdcxx would have significant advantages over the g++ library in any case. G++ has an additional trouble spot: the g++ ABI is not particularly stable. If you build a library with one version of g++, you cannot be sure it will work with another compiler version. If we provided a g++ version of libstdcxx, we would have to document it as known to work with only a specific version of g++. My recommendation is not to consider further a g++ version of libstdcxx. --- Steve Clamage, stephen.clamage@sun.com From Nicolas.Williams@sun.com Thu Sep 4 11:56:54 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84Iusgb021025 for ; Thu, 4 Sep 2008 11:56:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84IumY2027069; Thu, 4 Sep 2008 11:56:53 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00C0NPYR8N00@brm-avmta-1.central.sun.com>; Thu, 04 Sep 2008 12:56:51 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O0065QPYRXN60@brm-avmta-1.central.sun.com>; Thu, 04 Sep 2008 12:56:51 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m84IunxR002304; Thu, 04 Sep 2008 13:56:49 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m84Iumto002303; Thu, 04 Sep 2008 13:56:48 -0500 (CDT) Date: Thu, 04 Sep 2008 13:56:48 -0500 From: Nicolas Williams Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C02DAF.1090302@sun.com> To: Steve Clamage Cc: "Garrett D'Amore" , Gary Winiger , Joep.Vesseur@sun.com, John.Plocher@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stefan.Teleman@sun.com, gww@eng.sun.com Message-id: <20080904185648.GE1524@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 400 On Thu, Sep 04, 2008 at 11:49:19AM -0700, Steve Clamage wrote: > My recommendation is not to consider further a g++ version of libstdcxx. But only because g++ has a good enough alternative already. It would be nice if we could avoid revisiting this every time a project comes along to integrate some C++ library. If that's not this ARC case, oh well. But eventually this will have to be tackled. From John.Plocher@sun.com Thu Sep 4 12:07:59 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84J7wLb021240 for ; Thu, 4 Sep 2008 12:07:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m84J7ghe003813 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 03:07:57 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00L09QH85R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:07:56 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O00AK3QH7OEA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:07:55 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84J7t2a005415 for ; Thu, 04 Sep 2008 12:07:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00201Q3UEW00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:07:54 -0700 (PDT) Received: from wp668.local ([192.18.41.196]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00EFIQGU4B00@fe-sfbay-10.sun.com>; Thu, 04 Sep 2008 12:07:42 -0700 (PDT) Date: Thu, 04 Sep 2008 12:07:42 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <20080904185648.GE1524@Sun.COM> Sender: John.Plocher@sun.com To: Nicolas Williams Cc: Steve Clamage , "Garrett D'Amore" , Gary Winiger , Joep.Vesseur@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stefan.Teleman@sun.com, gww@eng.sun.com Message-id: <48C031FE.2000508@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 412 Nicolas Williams wrote: > It would be > nice if we could avoid revisiting this every time a project comes along > to integrate some C++ library. We already have a stake in this sandbox: Don't use g++ to build/deliver C++ libraries on *Solaris, period. Use Studio's C++ instead. We made that choice for all the reasons discussed here, and (IMO) this is not the time or place to revisit it. -John From gdamore@sun.com Thu Sep 4 12:08:57 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84J8vJX021269 for ; Thu, 4 Sep 2008 12:08:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84J8vcF002299 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 12:08:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O0040FQIWP600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:08:56 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O0022CQIUNQ40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:08:54 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84J8sov005576 for ; Thu, 04 Sep 2008 12:08:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00201Q3UEW00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:08:54 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00EYPQIP4B00@fe-sfbay-10.sun.com>; Thu, 04 Sep 2008 12:08:49 -0700 (PDT) Date: Thu, 04 Sep 2008 12:08:06 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C02DAF.1090302@sun.com> Sender: Garrett.Damore@sun.com To: Steve Clamage Cc: Nicolas Williams , Gary Winiger , Joep.Vesseur@sun.com, John.Plocher@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stefan.Teleman@sun.com, gww@eng.sun.com Message-id: <48C03216.5050804@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2445 Steve Clamage wrote: > Regarding g++, let's take a step back. > > There is nothing special about the Apache library. It is an > implementation of the API (programming interface) described by the C++ > standard. *We* care about it because the two implementations of the > C++ standard library currently supplied with Sun Studio are each > missing features that some applications need. ("Why" is a long story.) > > If you write to the C++ standard API, it should not matter which > implementation you use. It will matter only if you have a deficient > implementation. (Missing features, non-standard behavior, or poor > performance, for example.) > > G++ comes with its own implementation of the C++ standard library that > is quite standard-conforming. You should be able to build the apps > with g++ without the Apache library. (If you have tried and found that > they don't work, I would be surprised, because nearly all Open Source > apps are developed using gcc, then tweaked to work with other compilers.) Ah, that was not something I was aware of -- I thought GNU C++'s library also fell short of the mark. Given that it's not, I'm surprised that Apache decided to create their own implementation instead of just telling folks to "use Gnu C++". I guess we should be glad they took the time to make an alternate implementation available for us! > > I think that if we created a version of libstdcxx built with g++, > there would be no users. Using libstdcxx with g++ has at least the > same issues as using libcstdcxx with Sun Studio without direct > compiler support -- command lines get rather tricky. And it's not > clear that libstdcxx would have significant advantages over the g++ > library in any case. Okay, if other folks can corroborate your claims, then I agree we can safely dispense with any need for a g++ port. > > G++ has an additional trouble spot: the g++ ABI is not particularly > stable. If you build a library with one version of g++, you cannot be > sure it will work with another compiler version. If we provided a g++ > version of libstdcxx, we would have to document it as known to work > with only a specific version of g++. Yeah, good point. I'm surprised more people don't complain about this instability. > > My recommendation is not to consider further a g++ version of libstdcxx. Concur, provided that no contradictory information to your claims surface. -- Garrett From gdamore@sun.com Thu Sep 4 12:10:23 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84JANWP021287 for ; Thu, 4 Sep 2008 12:10:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84JAJOM039822 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 13:10:22 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00L01QL9EU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:10:21 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O00A81QL9OAB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:10:21 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84JALhu005786 for ; Thu, 04 Sep 2008 12:10:21 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00201Q3UEW00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:10:21 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00ET7QL84B10@fe-sfbay-10.sun.com>; Thu, 04 Sep 2008 12:10:21 -0700 (PDT) Date: Thu, 04 Sep 2008 12:09:37 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <20080904185648.GE1524@Sun.COM> Sender: Garrett.Damore@sun.com To: Nicolas Williams Cc: Steve Clamage , Gary Winiger , Joep.Vesseur@sun.com, John.Plocher@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stefan.Teleman@sun.com, gww@eng.sun.com Message-id: <48C03271.6060108@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 739 Nicolas Williams wrote: > On Thu, Sep 04, 2008 at 11:49:19AM -0700, Steve Clamage wrote: > >> My recommendation is not to consider further a g++ version of libstdcxx. >> > > But only because g++ has a good enough alternative already. It would be > nice if we could avoid revisiting this every time a project comes along > to integrate some C++ library. > > If that's not this ARC case, oh well. But eventually this will have to > be tackled. > Yes, it will. But unlike other middleware libraries, I think this library is fundamental to the implementation of the language. Probably KDE, when it comes along with extensive middleware libraries, will need to cross this hurdle if nobody else does so first. -- Garrett From gdamore@sun.com Thu Sep 4 12:11:25 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84JBPdZ021304 for ; Thu, 4 Sep 2008 12:11:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84JBPp2006937 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 12:11:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O0041NQMZS400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:11:23 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O002B2QMXNQ40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:11:21 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84JBLRq007334 for ; Thu, 04 Sep 2008 12:11:21 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00D01Q732500@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:11:21 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00GN1QMM3YB0@fe-sfbay-09.sun.com>; Thu, 04 Sep 2008 12:11:10 -0700 (PDT) Date: Thu, 04 Sep 2008 12:10:27 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C031FE.2000508@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Nicolas Williams , Steve Clamage , Gary Winiger , Joep.Vesseur@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stefan.Teleman@sun.com, gww@eng.sun.com Message-id: <48C032A3.3070509@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 559 John Plocher wrote: > Nicolas Williams wrote: >> It would be >> nice if we could avoid revisiting this every time a project comes along >> to integrate some C++ library. > > We already have a stake in this sandbox: > > Don't use g++ to build/deliver C++ libraries on *Solaris, > period. Use Studio's C++ instead. Oh, cool! Do you happen to know offhand what the case number for that opinion would be? -- Garrett > > We made that choice for all the reasons discussed here, and > (IMO) this is not the time or place to revisit it. > > -John > From Stefan.Teleman@sun.com Thu Sep 4 12:14:40 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84JEete021444 for ; Thu, 4 Sep 2008 12:14:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m84JEXwV023679; Thu, 4 Sep 2008 20:14:34 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00409QS9W200@nwk-avmta-2.sfbay.sun.com>; Thu, 04 Sep 2008 12:14:33 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O0023TQS8NN50@nwk-avmta-2.sfbay.sun.com>; Thu, 04 Sep 2008 12:14:32 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m84JEVTq001137; Thu, 04 Sep 2008 12:14:31 -0700 (PDT) Date: Thu, 04 Sep 2008 15:14:27 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C032A3.3070509@sun.com> To: "Garrett D'Amore" Cc: John Plocher , Nicolas Williams , Steve Clamage , Gary Winiger , Joep.Vesseur@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, gww@eng.sun.com Reply-to: Stefan Teleman Message-id: <48C03393.5040203@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 589 Garrett D'Amore wrote: > John Plocher wrote: >> Nicolas Williams wrote: >>> It would be >>> nice if we could avoid revisiting this every time a project comes along >>> to integrate some C++ library. >> >> We already have a stake in this sandbox: >> >> Don't use g++ to build/deliver C++ libraries on *Solaris, >> period. Use Studio's C++ instead. > > Oh, cool! Do you happen to know offhand what the case number for that > opinion would be? > PSARC/2002/348 (International Components for Unicode). --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From John.Plocher@Sun.COM Thu Sep 4 12:31:13 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84JVCCx010757 for ; Thu, 4 Sep 2008 12:31:13 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84JVCBe048386 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 13:31:12 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O0052PRJZHY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:31:11 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O002UMRJXND50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:31:09 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84JV9AZ008482 for ; Thu, 04 Sep 2008 12:31:09 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00D01QRWKN00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:31:09 -0700 (PDT) Received: from wp668.local ([192.18.41.196]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O004A4RJSBG40@fe-sfbay-09.sun.com>; Thu, 04 Sep 2008 12:31:05 -0700 (PDT) Date: Thu, 04 Sep 2008 12:31:03 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C032A3.3070509@sun.com> Sender: John.Plocher@Sun.COM To: "Garrett D'Amore" Cc: Nicolas Williams , Steve Clamage , Gary Winiger , Joep.Vesseur@Sun.COM, Bart.Smaalders@Sun.COM, John.Fischer@Sun.COM, PSARC-ext@Sun.COM, Stefan.Teleman@Sun.COM, gww@eng.sun.com Message-id: <48C03777.40508@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 45504 Garrett D'Amore wrote: > John Plocher wrote: >> Nicolas Williams wrote: >>> It would be >>> nice if we could avoid revisiting this every time a project comes along >>> to integrate some C++ library. >> >> We already have a stake in this sandbox: >> >> Don't use g++ to build/deliver C++ libraries on *Solaris, >> period. Use Studio's C++ instead. > > Oh, cool! Do you happen to know offhand what the case number for that > opinion would be? LSARC 1993/550 C++ ABI LSARC 1992/026 tools.h++ PSARC 1993/071 Bundling libC.so with Solaris BestPractices/ToDo/20q.C++Guidelines.html has a dated but still valid take on this topic. (Sorry, not out on OS.o, included here for now...) --------------------------------------------------------------------------------------------- Software -> C++ Guidelines --------------------------------------------------------------------------------------------- Background ARC cases for C++ LSARC 1993/550 C++ ABI This case has a specification and an opinion, but the opinion is not yet finalized (at this writing). The C++ Object Binary Interface (OBI) has been split out of this case. LSARC 1992/026 tools.h++ PSARC 1993/071 Bundling libC.so with Solaris --------------------------------------------------------------------------------------------- Advice LSARC Guidelines for Products Using C++ Language Revision: 1.0.3 of July 22th, 1994 Drafted by: Dean Stanton, Evan Adams, Don Woods HTML conversion: John Plocher 1.0 Problem Description LSARC found it necessary to provide guidance to Sun software developers who are considering using the C++ language. Indeed, many Sun groups are already developing in C++, and encountering compatibility problems. C++ has become a widely-used implementation and interface specification vehicle. And yet the C++ language lacks a stable ABI (Application Binary Interface) standard; no two compiler releases (from SunPro or from other vendors) necessarily have compatible binary forms for binary layout of objects or function calling sequences. Hence, the calling sequences generated by one compiler are not guaranteed to be compatible with those generated by another brand of compiler or another major release of compiler from the same provider. And an interface implemented by one compiler may not be usable (or may not function correctly) when invoked by compatible source code compiled by another compiler. An additional binary-compatibility problem plagues software libraries (whether statically linked, dynamically linked, or dlopen-ed): binary object layout is affected not only by the specified description of the object, but also by the private data included in the class (in the header file used at compile time). A library interface specification should be independent of its implementation, so that a revised implementation may be substituted (say, in a later library software release asynchronous to the application), and still function correctly. Most developers address this now by wrapping an interface-only class around the implementation class. This problem may eventually be solved by the C++ Object Binary Interface (OBI) project[Reference 1]. Alan Sloane calls it ``evolution'', and an earlier C++ ABI document addressed it with extern "shared". These Guidelines collect in one place the committee's requirements and advice on using C++, and call out details related to libC, the C++ library. The cfront-based C++ library is bundled into Solaris, starting with 10/93. But each libC is useful only to compatible compiler releases. 1.1 Compiler Background Information The following table presents the current status of SunPro C++ compilers, and their matching C++ libraries. It also shows conjecture that the next release will likely be binary-incompatible with SPARCompilers 3.x, but conforming to a hopefully-standard-and-stable C++ ABI. This ABI is the subject of LSARC case 1993/550[1]. Workshop C++ Release Base libC Dynamic C++ Library C++ Library first Release Number Number Technology Version Bundled 2.0.1 3.0.1 cfront libC.so.3 2.3 (10/93) ``all''[2] 3.0 4.0 cafe compiler libC.so.5[2 2.4 (4/94) ``end-user'' 3.0.1 4.0.1 caf' compiler libC.so.5[3] 2.4.1? ``end-user'' 4.0? 5.0? caf' + ABI[1] libC.so.6? (No Guess) 1.2 Binary Incompatibility Due to Build Platform Solaris 4/94 fixes bug #1091835 by changing a declaration in from: typedef enum boolean { B_TRUE, B_FALSE } boolean_t; to: typedef enum { B_TRUE, B_FALSE } boolean_t; to become POSIX-conformant. Unfortunately, the presence/absence of the enum tag affects the C++ name-mangling of function arguments (etc.) involving boolean_t. The mangled name will differ when compiled with pre-4/94 header files, versus 4/94 and later (including the Solaris Developers Conference CD), when using either cfront or caf'. A C++ interface compiled prior to Solaris 4/94 involving boolean_t will be callable only when compiled using a copy of sys/types.h with boolean reinserted, on 4/94 or later. However, distributing such a header file will run up against the PSARC packaging rules[2]. Users may need to be instructed to build their own. They must not build theirs in /usr/include/sys, however, because their system would then be incompatible with POSIX and modern C++ interfaces. 2.0 Introduction to the C++ Guidelines It is critical to differentiate C++ implementation (which may be used to implement a C interface, for which there is a stable ABI) from C++ interfaces (which lack a stable ABI). C++ interfaces are discouraged, but allowed, subject to restrictions specified in these Guidelines. This includes imported C++ interfaces as well as exported. Example imported C++ interfaces are the C++ utility classes from RogueWave, known as Tools.h++[3], and the C++ library itself, libC. There were several issues discussed, some specific to C++, and others dealing with dynamic-linking, compiler revisions, and other topics.[4] The committee discussed many possible differentiators: * Using C++ only for implementation, versus for interface specification * Bundled versus unbundled products * Applications versus libraries * Dynamic (shared) libraries versus static (archive) libraries The committee decided that most of these choices affected only detailed advice and brought up discussion of ancillary issues. Nonetheless, to make these Guidelines more useful, applications are presented separately from libraries. 3.0 Applications May be Implemented in C++ An application development team may use C++ internally, as long as it does not offer any C++-based interfaces. An application commonly has no programming-language-based interface at all, using only a CLI or GUI and non-language-specific file formats. C++ application developers face the following issues: 1. They must ensure that the proper version of libC is available or they must avoid the need for libC. (See section 1.1.) 2. They must ensure that the proper version of any other libraries written in C++ are also available. 3. It is very difficult to use multiple C++ libraries if they have been compiled with different compilers. 3.1 Applications and libC A program written in C++ will, by default, be dynamically linked with libC, the C++ runtime library. This library implements the new and delete operators, the I/O streams routines, exception handling, etc. Therefore, these programs need to have the appropriate libC available at runtime. Section 1.1 shows which C++ libraries are bundled with which Solaris releases. Applications built with a C++ compiler whose library is bundled may depend on the bundled C++ library. If the application does not need to run on prior Solaris releases, then its developers need not worry about C++ library access, except perhaps which clusters must be installed. 3.1.1 When Applications Cannot Depend on the Bundled libC Applications cannot depend on the bundled libC in the following cases: Bundled Products if the libC needed by the compiler you used is not bundled (yet). Unbundled Products if the product supports earlier Solaris releases, previous to those that bundled the libC needed by the compiler you used. Such applications must ensure that the proper version of libC is available. This can be done by co-packaging libC, statically linking with libC, or eliminating the dependency upon libC. 3.1.2 Co-packaging libC.so An unbundled application that needs libC may include the package that contains libC. The package names are SUNWlibC for SC3.x and SUNWlibCf for SC2.x. These packages are now available as patches: 101242-03 for SUNWlibC and 101246-02 for SUNWlibCf. The README file of C++ 4.0 contains information about these patches. Any unbundled product can ship these patches on their CD. 3.1.3 Linking Statically to libC is an Option An application product that chooses to link statically to the appropriate libC would use the -nolib option, as described on the appropriate CC(1) manpage, like: CC -o mycommand my.o other.o -nolib -lsunmath -lm \ -Bstatic -lC -lC mtstubs \ -Bdynamic -lw -lc The trick is to get libC static, but libc dynamic. (The compiler driver adds both of these libraries for you automatically, so it is difficult to find the correct spot for -Bstatic; the -nolib option asks CC not to add in the libraries.) 3.1.4 Eliminating the libC Dependency Projects that wish their C++ implementation software to run on systems prior to the bundling of the matching libC may avoid dependency on libC, as described later for libraries. In this way, their application or library doesn't need to find libC at runtime. 3.2 Unbundled Dynamic Libraries are Problematic, Independent of C++ If an unbundled application[4] depends on an unbundled dynamic library (with a C++ or any other interface), the proper install location for the dynamic library is /opt/some_path/lib, and the application must assure the library is found at runtime. This is typically achieved with the -R link option (or LD_RUN_PATH), with the LD_LIBRARY_PATH environment variable as a last resort. If the package containing the library must be installed somewhere else, system administrators may need to 1. mount the package onto /opt/some_path on each target machine on which the application may be run; or 2. make /opt/some_path a symlink on each target machine to the installation location; or 3. set the users' LD_LIBRARY_PATH environment variable, for each user of the application, perhaps via scripts similar to /usr/dist/exe's. LSARC would welcome a proposal for a better solution, such as including some centrally-administered places into the list of locations automatically searched for dynamic libraries. (Below, there are additional guidelines on delivering dynamic C++ libraries.) 3.3 Multiple Libraries using Different Compilers One awkward case to consider is an application that depends on two or more libraries with C++ interfaces: one that exists only for an older compiler, and one that exists only for a newer compiler with incompatible calling conventions. The C++ calling convention can be side-stepped - for example, using C wrappers. But even then, if the libraries require incompatible C++ runtime libraries, they cannot be co-resident in one process. To build such an application requires sophistication, if it is to be performed at all. Techniques we've identified are: 1. Use two processes, one compiled with each compiler. These could use compiler-independent IPC to communicate. 2. Use a C-callable (i.e., stable-ABI based) ``wrapper'' layer, as described in Appendix F of reference [5], between the portions of the application compiled with each compiler. Even if the two portions did not depend on incompatible libC runtimes, there still might be problems with call-back functions or exceptions, which depend on C++ call-stack details, Because of these problems, option 2 is not recommended. 4.0 C++ May be Used for Library Implementation We first consider the case that is easy to permit: A library development team may use C++ internally, as long as it neither exports nor imports any C++ interfaces, including libC. Generally, this means the library exports a C-callable interface, but sports a C++ implementation. Importing or exporting any C++ interface ties the library to a particular C++ compiler until a stable ABI exists. The dependency on particular C++ calling conventions and/or runtime libraries lead to restrictions on applications using the library, as discussed in section 3.3, even though the C calling sequence is compatible, because the other side of the C++ interface might use a different compiler, and the two runtimes might conflict. See section 3.3. 4.1. Avoiding libC is an Option Projects that wish their C++ implementation software to run on systems prior to the bundling of the matching libC may avoid dependency on libC. Another reason to avoid libC is that a client - even of a library's C interface - may be using C++. If the client wants to use a different compiler and libC from the one the library needs, the two C++ libraries would conflict. The same could arise if the client wanted to use two libraries implemented in C++ that needed different libC versions. Avoiding library dependency on libC is encouraged, but it is difficult to assure that no C++ interfaces are imported. No real tools exist to verify lack of libC importation. Until additional guidelines are provided to help programs avoid accidental dependencies on libC, avoid the following libC features: 1. C++ I/O streams (perhaps use libc I/O instead). 2. C++ exceptions (try, throw, and catch must be avoided - use explicit arguments and tests instead). 3. new and delete operators. Supply class-specific new and delete operators instead.[5] 4. new[], and delete[] operators. Classes cannot provide their own implementations for these array operators; therefore, these operators must be avoided. Do not use arrays of classes in any context - static, automatic, or in a structure; these use library routines to implement construction and destruction. Instead, use arrays of pointers to the objects. Re-implementation of libC public entry points is strongly discouraged, due to support problems of multiple implementations. Any exception would require justification and explicit ARC approval. 4.2. Avoid C++ Exposure in C Interfaces Libraries with C++ interfaces incur additional problems (and hence additional restrictions imposed by these guidelines). In using a C interface and a C++ implementation, care must be taken that no C++ interface sneaks in. Pointers to C++ objects may be handed across a C interface (as an opaque handle), but only the library that produced the pointer can interpret (dereference) it. 4.3. Conventions for Naming Library Symbols The committee regrets that there is not a widely disseminated naming conventions document. The only naming conventions document we know of is from 1987[6], which is pre-C++. A summary is presented here, along with application to C++. When C++ compilers support the namespace feature, we will need additional conventions for their use. 1. All external symbol names in a library and in its public header files should begin with a prefix (e.g., dbm_ or Dbm).[6] In C++, these are symbols that could be referenced with the :: scope resolution operator. A large library may use a handful of prefixes, or sub-prefixes (e.g., dbm_core_ and dbm_util_). C++ class names are external names, and should be prefixed. C++ members, including methods, are effectively prefixed with the class name by the compiler, and therefore do not need special naming. Names that need not be external may be static instead of prefixed. 2. typedef, struct, and enum names, enum tags and constants should all be prefixed, if they have file scope. If these names are scoped within a C++ class, they do not need special naming. Macros should be prefixed, as well. For example, use DBM_MAX_LENGTH, not MAX_LENGTH nor MAX_DBM_LENGTH. Each header file should have a single prefix; multiple header files for the same library may share the same prefix. 3. These prefixes must be documented, so that clients avoid any accidental use of them. 4. Functions or global data symbols that are private to a package must have a prefix that begins with an underscore. The naming convention would also mandate case, underscores, and conventions such as _t (for types) or _H (for header-file guards), which aren't addressed here, but are addressed in the Project DOE C++ Programming Style Guide[7]. While this Style Guide is not universally accepted, PSARC/1992/075 mandated that future Ivy and Trellis C++ interfaces be defined in accordance with this Style Guide. Deviations from the Style Guide in C++ interfaces (but not in implementation) should be pointed out during ARC review. Project DOE intends to update the Style Guide and obtain ARC approval for the new C++ style guidelines. After ARC approval, these guidelines should be used by projects unless the project gains an ARC exemption. 5. Libraries that Export or Import a C++ Interface are Restricted In addition to sharing the problems listed above for C++ implementations, until a stable ABI exists, importing or exporting any C++ interface ties a library to a particular C++ compiler. One notable C++ interface commonly imported is libC. (See first footnote.) 5.1. Precedent - Libraries with C++ Interfaces are Strongly Discouraged until the ABI is Stable In consideration of the restrictions that follow, LSARC strongly discourages libraries from importing or exporting C++ interfaces until C++ compilers offer a stable binary interface. Reasons that a C++ interface might be justified include: 1. Needing client extensibility via subclassing. 2. C++ interface specified by a standard, such as OMG CORBA. 3. Library is intended specifically to support users of C++. 4. Software purchased to fill a need happens to have one or more C++ interfaces. 5.2. Sentiment for Forbidding C++ Interfaces Before ABI is Stable Some committee members wish to forbid libraries with C++ interfaces until there is a stable C++ ABI. The majority, however, feel the risks and advantages may be weighed as a business decision, as long as the architectural limitations are known. The following sections describe restrictions that apply to libraries with C++ interfaces. 5.3. Precedent - C++ Interfaces Could be Classified Public Due to the lack of a C++ ABI, a C++ binary interface might be modified by changes to the compiler, even if the source-code-level interface is stable. Therefore, a project shipping a library with a C++ interface should plan to ship multiple versions of that library for use with different compilers[8] due to market considerations.[7] If this is understood by the project team and steering committee, such an interface could be classified as Public or Standard. These considerations also apply to libraries or applications using a binary interface based on the C++ compiler. Shipping source code might be a reasonable alternative prior to the ABI for a utility library not intended to be used by other libraries. 5.4. Linking Multiple libC Instances is Discouraged When faced with the situation of two pieces of code each requiring a different version of libC, it was deemed impractical to link in both versions of libC and expect things work correctly. While the name-mangling of the different compilers should not conflict, the implementation of the two instances of libC are very likely to conflict. Therefore, a library using libC will be unusable by applications using an incompatible C++ compiler and unusable in the same process as any other library using a different compiler's libC. This may unreasonably limit the library's potential market. 5.5. Libraries Must Not Link Statically to libC As section A.3 explains, both static and dynamic libraries must link dynamically to libC or avoid dependency on it entirely. 5.6. Precedent - Conventions for Naming Libraries with C++ Interfaces To ease support and use of multiple versions of a library offering a C++ API, LSARC requires the following naming convention of such a library. Any exception should be explicitly approved by the appropriate ARC. 1. A brief substring indicating the compiler's binary interface should be established by the compiler vendor and shared by every library offering a C++ API that uses that compiler (or one with a compatible binary interface). One example is ``-SC3'' for SPARCompilers 3.x. SAC should know what strings have been established, and assure that only one string is used for each ABI. The stable, standard C++ ABI (once available) could use the null string. 2. This string must appear in the library name. Following the example, a library might be named ``libfoo-SC3.so.1''. There may be a symbolic link without the version number suffix which points to the latest compatible version of the library (``libfoo-SC3.so -> libfoo-SC3.so.1'' in the example), but there must not be a symbolic link without the binary interface substring. The rationale for this requirement is that users of a library with a C++ interface don't want the ``latest''; they want one compatible with their compiler. 3. Users will be instructed to link with the library name including the binary interface substring. If ``-SC3'' is the substring, users might link with -lfoo-SC3. Using this scheme, a customer could switch library versions in an obvious way when upgrading to a newer compiler. A single Makefile edit could change all libraries. (That is, the user might represent his library references using -lfoo${CPLUSPLUS_ABI} -lbar${CPLUSPLUS_ABI}.) The committee requires this convention for static libraries, as well, so that dynamic and static libraries (if they are ever both offered) will share the same ``root name'' (prior to the .a and .so suffix). 5.6.1. Discussion of Library Naming Convention The convention applies to libraries with C++ Application Programming Interface (API). XGL 3.x and XIL 1.x have C-callable APIs, but C++ System Programming Interfaces. They need not adhere to this naming convention. They may use other versioning techniques to determine whether hardware-specific libraries with C++ interfaces are compatible with the library. The rejected alternative is to merely use library ``version numbers''. (The filenames of the two libraries based on different compilers must be different, so they can be present simultaneously.) The version number would be bumped whenever the binary interface changed. This is either because the source-level interface changed or because an incompatible compiler created it. LSARC notes that the bundled libC chose this alternative. In fact, the naming convention in section 5.6 above came from Chuck McManis' Minority Opinion of the PSARC opinion on bundling libC[8]. The committee rationalizes that libC is a special case because it is not generally mentioned in Makefiles. (It is usually added implicitly by linking via the CC compile driver.) The advantage of the new convention is that library version numbers are still available for identifying source-level compatibility. A filename ``namespace'' separate from the library version number indicates a compiler binary interface version. Library users need not remember which library versions are compatible with their specific compiler; this information is visible. The contrary arguments were that version numbers alone are adequate, few developers are likely to use multiple libraries offering C++ APIs, and that libraries have other distinguishing characteristics (such as MT-safeness and standards-compliance) that are not apparent in the names; names can't encode all library properties without being unwieldy. The committee favored the new convention nonetheless. 5.7. Precedent - Packaging Convention for Libraries Exporting a C++ Interface Projects which have libraries exporting a C++ interface should deliver such libraries in a separate package from non-C++ components, at least until there is a C++ ABI. Any exception should be explicitly approved by the appropriate ARC. It is acceptable for multiple C++ libraries depending on the same compiler to be co-packaged. The rationale for this requirement is that future product releases will likely add libraries for newer compilers, and ``sweep out'' libraries compatible with old compilers to a ``backwards-compatibility'' cluster, deem the old versions Obsolete[9], and eventually remove them completely. Separate packages are good for things we intend to someday ``sweep out''. 5.7.1. Discussion of Packaging Convention The general packaging guideline is that organizing files into more packages is more flexible. Projects should group packages into small clusters, so that the user doesn't have to select every (tiny) package one-by-one, but can select the appropriate cluster instead, killing multiple birds with one stone. The overhead of creating additional packages is a small amount of disk space, and a small packaging-engineering effort. These effects are minor. Files on which the library depends or vice versa need not be co-packaged. Listing the dependent packages is sufficient. 5.8. Bundled Libraries with C++ Interfaces Any bundled dynamic library with a C++ interface must continue to provide a version of the dynamic library compatible with the same compiler binary interface ``forever''.[8] Such a project must get explicit approval from their steering committee before integration. This approval should consider the issues of multiple versions of the library, one for each binary-incompatible version of C++: * Customer Support for multiple versions. * Maintenance and patching of multiple versions. * Disk consumption (on both distribution media and customer disk) of multiple versions. Static libraries might not need to ship old versions of the library ``forever,'' because each application is compiled only with the correct compiler, and is linked with the matching library, after which no runtime library compatibility problem occurs. Nonetheless, there is likely a business case to ship multiple versions, because a portion of the customer base might not be ready or willing to update to the newer compiler release. If a bundled library needs a version of libC, the appropriate dynamic C++ library would need to be bundled. 5.9. Unbundled Libraries with C++ Interfaces Unbundled dynamic libraries might not need to provide a version for the same compiler binary interface ``forever'', because the ISV already has the responsibility of redistributing the library along with the application to all end-users, and a new version of the dynamic library using a newer compiler doesn't change that. Any single application would be compiled with only one compiler, and need to be delivered with only the matching dynamic library. However, multiple versions of any library with a C++ interface might still be needed as a business decision, even for compilers older than current when the library is released. Otherwise, customers who have paid for an older compiler would be unable to use it to invoke the (newer) library. See the issues in the preceding section. An unbundled (static or dynamic) library product that depends on libC may need to ship the appropriate libC if the product supports earlier Solaris releases, previous to those that bundled the libC needed by the compiler you used. 5.10. Interfaces Based on C++ Templates Templates are expanded at compile time. Therefore, the expansion of the template becomes part of the binary interface based on the template source interface, and must not be changed between releases without ARC approval. Templates are equivalent to macros in this respect. Developers should also be aware that multiple generated template expansions could bloat a product. Appendix A: Additional Advice Regarding Dynamic Libraries The following sections provide additional information about dynamic libraries, that is not specific to C++, but may not be widely known. See reference [10] for more information. A.1. Dynamic versus Static Library Performance To oversimplify the performance ramifications, a single application will run slightly faster when statically linked to its support library or libraries. This is partly due to avoiding runtime relocation and indirection, and partly due to compilation for absolute addressing, rather than Position Independent Code (PIC). However, multiple applications can all share the text segment of a shared library, which reduces their size (on disk and in memory), and can avoid page-faulting because some other process has brought in the pages of the shared library text that this application needs, or by using them has kept them from being paged out. This means overall system performance is generally increased by use of dynamic libraries. Hence, for any library expected to be used by more than one process at a time, shared/dynamic libraries are preferable from a performance standpoint. Any such library should be shipped either in dynamic-library form, or in both dynamic and static forms. A.2. Unbundled Dynamic Libraries Unbundled dynamic libraries are problematic, even without use of C++. Both the application and the dynamic library must be provided to its end user, and both must be addressed at runtime. This can't presently be simply handled for the end user by a system administrator, because the application and dynamic library are typically installed on a single server, and then shared by many end users on multiple ``execution'' hosts. It is unfortunate that dynamic libraries are problematic, because a good shared library implementation is one of Sun's value-added strengths. The performance advantage of sharing libraries and the added flexibility of runtime linking in some cases outweighs the distribution problem and the hazard of being unable to locate the dynamic library at runtime due to inadequate installation or incorrect configuration. We impose the following guidelines for unbundled dynamic libraries, whether C++ is involved, or not: 1. The library or libraries must be distributed in a separate package of their own[9], so that multiple applications could distribute them. The installation directory for this package need not match the package name, nor contain the libraries from only a single package. But the directory name should be owned and managed by the provider/owner of the shared library. 2. Use of ld's -R option (or the LD_RUN_PATH environment variable) must be recommended for use by developers of software importing the library or libraries, so that end-users need not use LD_LIBRARY_PATH (if installing everything normally). See section 3.2. A.3. Libraries Must Not Link Statically with Other Libraries Libraries must not statically link in subordinate libraries that anyone else may use in their application. This causes the resultant library to assume the dependencies of both libraries. This issue is not specific to C++. ARC members have seen this problem without involvement of C++. If a dynamic library D links statically to any static library S, only the portions of S used by D are inserted into D. If an application A uses D and also some additional portion of S, the portion of S inserted by D may not be of the same revision as the portion of S inserted by A. The two portions of S may not share compatible internal (e.g., project private) interfaces, and therefore may not work together. This can be very difficult to detect and debug. This comes up when C++ library developers try to solve the libC unstable-binary-interface issue by statically linking in parts of libC. The implementation of libC included by the portion of libC brought in statically at link time may be incompatible with the implementation of additional portions of libC brought in by an application (or another library) implemented in C++, even if they have binary-compatible external interfaces, due to revised implementations. If the functionality is only present in an archive library, the applications should link with the static library. This error can normally be caught by link-editing a dynamic library with -z text. This will flag non-pic code (position independent code), which is what is typically in a static archive library. A dynamic-library developer can also verify that no archive has been linked in by using the LD_OPTIONS environment variable with the value -Ddetail,libs when building the dynamic library. This prints the path of all dependent libraries searched for. If the search for any dependent library finds a .a file before or instead of a .so file, then an archive library will be used. A.4. How the Correct Version of libC.so is Found When a library or application is linked with an implicit or explicit dependency on the dynamic C++ library, libC.so, the presence of other versions of libC.so libraries at link time or run time will not cause an incompatible libC.so to be used. Each compiler driver adds ld -L options to force its own version of libC.so to be found at link time. This may actually be a sym-link to /usr/lib/libC.so.N as described in reference [8]. The version number found in this library (not merely in its filename) is saved in the library or application ELF file that depends on it. At runtime, the dynamic loader selects the C++ library named with this version number.[10] This selection might be influenced by the builder's LD_RUN_PATH environment variable and the user's LD_LIBRARY_PATH environment variable (typically set up by system administrators). Appendix B: Additional Advice for C++ Users B.1. Expected C++ Binary Interfaces SunPro's C++ compiler developers inform us to expect only one more C++ binary interface after SPARCompilers 3.0 (which is caf' ; see footnote 1). The next release will be binary-incompatible with SPARCompilers 3.x, but conforming to a hopefully-standard-and-stable C++ ABI. This ABI is the subject of LSARC case 1993/550[1]. B.2. Name Mangling Differences The C++ name ``mangling'' algorithm is different between cfront (that is, SPARCompilers 2.0 aka C++ 3.0), and caf' (that is, SPARCompilers 3.0 aka C++ 4.0). We have been convinced this incompatibility is a feature (until the C++ ABI is stable). LSARC required future C++ compilers to change the name mangling as well, whenever the ABI is changed incompatibly. In particular, LSARC required that the proposed standard ABI[1] specify name mangling different from that of SPARCompilers 3.0. B.3. Frequently Asked Questions A list of Frequently-Asked-Questions about C++ and their answers is in reference [11]. This is not specific to Sun or Solaris. Appendix C: Reference Material [1] LSARC case 1993/550, C++ ABI, has a specification and an opinion, but the opinion is not yet finalized (at this writing). The C++ Object Binary Interface (OBI) has been split out of this case. [2] PSARC Packaging opinion 1991/061 http://sac.eng/Archives/BestPractices/ToDo/packaging.rules/packaging.rules.txt [3] Tools.h++ case is LSARC/1992/026. Opinion is /shared/sac/LSARC/1992/026/opinion.ms [4] Mail discussion for this case is in /shared/sac/PSARC/1993/571/mail . [5] SPARCompilers C++ 3.0.1 Programmers Guide, part #800-6986-11, is available on-line in the SunPro AnswerBook. The manuals for SPARCompilers C++ 4.0 include: SPARCompiler C++ 4.0 User's Guide 801-4727-05 SPARCompiler C++ 4.0 Language System Product Reference Manual 801-4728-05 Tools.h++ Intro and Reference Manual 801-4317-05 Object Oriented Programming Article 801-5058-05 As Close As Possible to C - But No Closer Article 801-5057-05 [6] Naming Conventions for Software Packages, Evan Adams, et. al., June 21, 1987. This is available on-line only in Interleaf format. SAC would welcome a conversion to a modern form, such as Frame. The authors are willing to send a hardcopy of this document to requesters. [7] Project DOE C++ Programming Style Guide, SunSoft part #801-3842, available in /net/bigdoe.eng/export/DOE/doc/DOEPI/doc/C++_StyleGuide,v2.0.1.ps and the Project DOE C++ Programming Style Guide Quick Reference, SunSoft part #801-3967, /net/bigdoe.eng/export/DOE/doc/DOEPI/doc/C++_StyleGuide.QuickRef,v2.0.1.ps This document includes a Bibliography. Both documents are available in hardcopy from the Copy Center; E-mail a request to ``copyrequest@snail.Sun.COM''. [8] PSARC's opinion on Bundling libC.so with Solaris /shared/sac/PSARC/1993/071/opinion.ms [9] PSARC Interface Taxonomy Addition: the Obsolete classification /shared/sac/PSARC/1993/226/opinion.ms [10] The SunOS 5.1 Linker and Libraries Manual, part #801-2869-10. More recent versions may be available via AnswerBook (instead of paper). [11] The Frequently-Asked-Questions for newsgroup comp.lang.c++ (in plain ASCII text format, but arguably dated) is in /net/bigdoe.eng/export/DOE/doc/DOEPI/doc/comp.lang.C++.FAQ _________________________ FOOTNOTES 1. LSARC case 1993/550. 2. In Solaris 10/93, the intention was to bundle the libC.so.4 from cafe'; however, due to a last-minute change in caf''s name mangling, the bundled libC that should match caf' does not, causing incompatibility and consternation. These libC versions are in different packages, in the ``all'' cluster. Starting with 4/94, both cafe''s libC.so.5 and cfront's libC.so.3 will be moved to the ``end-user'' cluster, so more users will have it installed. Solaris 2.4 for x86 does not bundle libC, though Solaris 2.5 for x86 may. 3. But, alas, the libC.so.5 that is bundled with Solaris 2.4 will work with C++ 4.0 but won't work with C++ 4.0.1. The latest libC.so.5 patch, 101242-06, will work with both C++ 4.0 and 4.0.1. 4. Bundled applications cannot depend on any unbundled component. 5. One might derive all classes from one that implements new and delete. You may want to allow the user to override your implementation, similar to the way caf''s libC allows the user to override its ``default'' implementations. 6. Exceptions may be granted by an ARC for extremely primitive functionality, comparable to the C library, or for names defined by standards. When possible, we should influence standards to abide by these reasonable naming conventions. 7. For instance, the particular compiler that can call a library might be superseded during the life of that library, and cease to be sold. Another version of the same problem: a new compiler might not be readily accepted because some popular bundled library is not yet released in a form callable by this new compiler. 8. The committee explicitly defines ``forever'' to mean ``until a major release'' or until the dynamic library for that binary interface is obsoleted using the Obsolete classification process[9]. 9. Our package installation software will assure that the end-user has one copy of the dynamic library, but not multiple instances in different directories. Furthermore, the installation software will accept an updated version of this package to replace an older version, but not vice versa. Note that any software license agreements from the original library vendor need to permit free redistribution of the shared library (but not necessarily any header files, etc.). 10. As Cris Perdue pointed out, it is interesting to note that there is no such safeguard for multiple versions of the usual system libraries such as the C library, libc.so. If Sun would wish to support incompatible major versions on the same machine, some provision would have to be made. (Users might have to reference the version number explicitly.) _________________________ --------------------------------------------------------------------------------------------- ARC Policies 1. Applications may be implemented in C++. (See Section 3.) 2. Libraries may be freely implemented in C++ as long as they only export C interfaces. (Section 4.) 3. Libraries implemented in C++ may avoid dependence on the C++ library, libC. Otherwise, they should link dynamically to libC, and perhaps ship the required libC package. (Sections 4.1, 5.5, and A.3.) 4. Libraries exporting C++ interfaces are discouraged until they use a stable C++ ABI. (Section 5.) 5. A naming convention requires that a library offering a C++ API include a compiler binary interface identifier in its name, such as libfoo-SC3. (Section 5.6.) 6. A packaging convention requires the separation of libraries exporting C++ interfaces from compiler-independent packages. (Section 5.7.) 7. Information and advice in these guidelines may be useful for languages other than C++. Additional advice and reference materials are also provided in the Appendices. From gdamore@sun.com Thu Sep 4 12:46:56 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84JktW9011132 for ; Thu, 4 Sep 2008 12:46:55 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m84Jkmjc017019 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 03:46:54 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00103SA4W700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:46:52 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O00A3BSA3O6E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:46:51 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84JkpV3011927 for ; Thu, 04 Sep 2008 12:46:51 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00L01S7LFQ00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:46:51 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O004OJSA2BGB0@fe-sfbay-09.sun.com>; Thu, 04 Sep 2008 12:46:51 -0700 (PDT) Date: Thu, 04 Sep 2008 12:46:07 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C03393.5040203@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John Plocher , Nicolas Williams , Steve Clamage , Gary Winiger , Joep.Vesseur@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, gww@eng.sun.com Message-id: <48C03AFF.7060103@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2827 Stefan Teleman wrote: > > > Garrett D'Amore wrote: >> John Plocher wrote: >>> Nicolas Williams wrote: >>>> It would be >>>> nice if we could avoid revisiting this every time a project comes >>>> along >>>> to integrate some C++ library. >>> >>> We already have a stake in this sandbox: >>> >>> Don't use g++ to build/deliver C++ libraries on *Solaris, >>> period. Use Studio's C++ instead. >> >> Oh, cool! Do you happen to know offhand what the case number for >> that opinion would be? >> > > PSARC/2002/348 (International Components for Unicode). > Thank you. I don't see Gnu C++ mentioned explicitly, but it seems like some specific comments were made about compiler flags, etc. that necessarily preclude Gnu C++. Please review the last paragraph in section 4.1.8. I don't know if the policy has been superseded, but the case clearly recognizes the binary compatibility problems, and tried to set a policy against Evolving or Stable. (Which today would mean Committed.) I take that precedent to mean that it would be inappropriate for any binary compatibility level to be granted beyond Uncommitted. And Consolidation or Project Private seems even better (the case recommends this), with individual contracts for specific use outside of the consolidation or project. If this case wishes to propose a new C++ Standard library, with a higher level of binary stability, then I think it would be appropriate to escalate this to a full case. The full case would describe how the binary compatibility guarantees would be used, and might then create itself a precedent for how middleware C++ could solve the binary compatibility problem. It would necessarily need to involve input from both compiler teams and the project team (and possibly potential consumers such as KDE as well.) I guess at this point, I have the feeling that we need a way to standardize upon a single C++ ABI, combining the results of the C++ compiler implementation *and* the "standard" libraries. This feels like something that needs to be resolved with a scope that falls well outside the fair bounds of a fast track. Right now, it doesn't seem like any of our binary compatibility guarantees apply to any dynamically linked C++ code, and this case (as proposed) proposes to set new precedent here. Alternatively, if this library were delivered within a project or consolidation, not for use outside of the project/consolidation (and no additional "public" C++ library dependencies were exposed otuside of the project/consolidation), then I'd be OK with this as a fast track. That would rescope this effort rather drastically, but then it would also suggest that this particular project should deliver as part of a larger whole such as KDE, rather than as a separate case unto itself. -- Garrett From Stephen.Clamage@sun.com Thu Sep 4 12:55:02 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84Jt1VV011638 for ; Thu, 4 Sep 2008 12:55:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m84Jsv7Q009234 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 20:55:00 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00601SNNDY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:54:59 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O002IPSNNND70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:54:59 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84Jsx2d011350 for ; Thu, 04 Sep 2008 12:54:59 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00G01SG7WH00@fe-sfbay-10.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 12:54:59 -0700 (PDT) Received: from [129.146.86.208] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O003K4SNLMJ50@fe-sfbay-10.sun.com>; Thu, 04 Sep 2008 12:54:57 -0700 (PDT) Date: Thu, 04 Sep 2008 12:54:57 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C03216.5050804@sun.com> Sender: Stephen.Clamage@sun.com To: "Garrett D'Amore" Cc: Nicolas Williams , Gary Winiger , Joep.Vesseur@sun.com, John.Plocher@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, Stefan.Teleman@sun.com, gww@eng.sun.com Message-id: <48C03D11.5040101@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <48C03216.5050804@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 3668 On 09/04/08 12:08, Garrett D'Amore wrote: > Steve Clamage wrote: >> Regarding g++, let's take a step back. >> >> There is nothing special about the Apache library. It is an >> implementation of the API (programming interface) described by the C++ >> standard. *We* care about it because the two implementations of the >> C++ standard library currently supplied with Sun Studio are each >> missing features that some applications need. ("Why" is a long story.) >> >> If you write to the C++ standard API, it should not matter which >> implementation you use. It will matter only if you have a deficient >> implementation. (Missing features, non-standard behavior, or poor >> performance, for example.) >> >> G++ comes with its own implementation of the C++ standard library that >> is quite standard-conforming. You should be able to build the apps >> with g++ without the Apache library. (If you have tried and found that >> they don't work, I would be surprised, because nearly all Open Source >> apps are developed using gcc, then tweaked to work with other compilers.) > > Ah, that was not something I was aware of -- I thought GNU C++'s library > also fell short of the mark. Given that it's not, I'm surprised that > Apache decided to create their own implementation instead of just > telling folks to "use Gnu C++". I guess we should be glad they took > the time to make an alternate implementation available for us! The source code for the g++ runtime libraries make extensive use of g++ extensions. Few compilers other than g++ can compile the code. Still other good implementations exist, but they are either proprietary or must be purchased. For Sun, the cost to distribute the best commercial library (Dinkumware) would be prohibitive to include in a product that we don't charge for, and the source code could not be made public in any event. > >> >> I think that if we created a version of libstdcxx built with g++, >> there would be no users. Using libstdcxx with g++ has at least the >> same issues as using libcstdcxx with Sun Studio without direct >> compiler support -- command lines get rather tricky. And it's not >> clear that libstdcxx would have significant advantages over the g++ >> library in any case. > > Okay, if other folks can corroborate your claims, then I agree we can > safely dispense with any need for a g++ port. You (for some definition of "you") should try building with g++. My guess is that everything will just work. > >> >> G++ has an additional trouble spot: the g++ ABI is not particularly >> stable. If you build a library with one version of g++, you cannot be >> sure it will work with another compiler version. If we provided a g++ >> version of libstdcxx, we would have to document it as known to work >> with only a specific version of g++. > > Yeah, good point. I'm surprised more people don't complain about this > instability. G++ users expect to recompile everything if they change compilers. ISVs who use g++ don't distribute dynamic libraries. They also tend to stick with one centrally-controlled compiler for years at at time. For example, Google did not move away from gcc 2.95 until June 2006! They made the new compiler available for unit testing months ahead of time, switched compilers globally at the same instant, then recompiled their entire code base. This is not the kind of world we are used to here at Sun. :-) > >> >> My recommendation is not to consider further a g++ version of libstdcxx. > > Concur, provided that no contradictory information to your claims surface. > > -- Garrett > --- Steve Clamage, stephen.clamage@sun.com From John.Plocher@Sun.COM Thu Sep 4 13:26:39 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84KQc1p012922 for ; Thu, 4 Sep 2008 13:26:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84KQaGj028641 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 13:26:38 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O0070NU4EO700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 13:26:38 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O002EZU4DNL90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 13:26:37 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84KQbab017218 for ; Thu, 04 Sep 2008 13:26:37 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00E01TU7FA00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 13:26:37 -0700 (PDT) Received: from wp668.local ([192.18.41.196]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00IDAU4B1RE0@fe-sfbay-09.sun.com>; Thu, 04 Sep 2008 13:26:35 -0700 (PDT) Date: Thu, 04 Sep 2008 13:26:35 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C03AFF.7060103@sun.com> Sender: John.Plocher@Sun.COM To: "Garrett D'Amore" Cc: Stefan Teleman , Nicolas Williams , Steve Clamage , Gary Winiger , Joep.Vesseur@Sun.COM, Bart.Smaalders@Sun.COM, John.Fischer@Sun.COM, PSARC-ext@Sun.COM, gww@eng.sun.com Message-id: <48C0447B.2050002@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 675 Garrett D'Amore wrote: > I don't see Gnu C++ mentioned explicitly, It mentions C++ ABI - something that Studio has and g++ does not. From an ARC perspective, that is all that really matters. Note the dates on the document - 1993-ish. One reason it is not on OS.o is that it needs updating, which is not a trivial job. > Right now, it doesn't seem like any of our binary compatibility > guarantees apply to any dynamically linked C++ code, Rather, dynamically linked C++ libraries that are NOT ABI Compliant. Studio C++ does generate ABI Compliant code, g++ does not. > and this case (as > proposed) proposes to set new precedent here. What would that be? -John From Stephen.Clamage@sun.com Thu Sep 4 13:28:50 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84KSoAm012988 for ; Thu, 4 Sep 2008 13:28:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84KSmOB002317 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 14:28:49 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O0070DU80RC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 13:28:48 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O002SJU7ZNI80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 13:28:47 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84KSl8n015600 for ; Thu, 04 Sep 2008 13:28:47 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00701TWXEE00@fe-sfbay-10.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 13:28:47 -0700 (PDT) Received: from [129.146.86.208] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00H1PU7WVU50@fe-sfbay-10.sun.com>; Thu, 04 Sep 2008 13:28:44 -0700 (PDT) Date: Thu, 04 Sep 2008 13:28:44 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C03AFF.7060103@sun.com> Sender: Stephen.Clamage@sun.com To: "Garrett D'Amore" Cc: Stefan Teleman , John Plocher , Nicolas Williams , Gary Winiger , Joep.Vesseur@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, gww@eng.sun.com Message-id: <48C044FC.7070906@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 3464 On 09/04/08 12:46, Garrett D'Amore wrote: > Stefan Teleman wrote: >> > > I guess at this point, I have the feeling that we need a way to > standardize upon a single C++ ABI, combining the results of the C++ > compiler implementation *and* the "standard" libraries. This feels like > something that needs to be resolved with a scope that falls well outside > the fair bounds of a fast track. > > Right now, it doesn't seem like any of our binary compatibility > guarantees apply to any dynamically linked C++ code, and this case (as > proposed) proposes to set new precedent here. > > Alternatively, if this library were delivered within a project or > consolidation, not for use outside of the project/consolidation (and no > additional "public" C++ library dependencies were exposed otuside of the > project/consolidation), then I'd be OK with this as a fast track. That > would rescope this effort rather drastically, but then it would also > suggest that this particular project should deliver as part of a larger > whole such as KDE, rather than as a separate case unto itself. > > -- Garrett > I have no opinion about whether you should deal with ABI issues in this ARC case. But let me put the C++ ABI status into context. I wrote a rather long paper in 2002 on this topic. The gory details are here: http://developers.sun.com/solaris/articles/CC_abi/CC_abi_content.html SUMMARY: The C++ Standard allows many degrees of implementation freedom, leading to incompatible ABIs. The C++ Committee chose not to specify an ABI because - One would have to be specified for every different architecture, and new architectures come along every year. - Different OS's have incompatible ABI requirements, so you need an ABI for every combination of architecture and OS. - Different ABI design choices have different performance characteristics. The market should be able to choose among trade-offs. - From time to time a new solution to an ABI problem is discovered. A fixed ABI prevents innovation. Sun C++ 3.x was based on Cfront, which generated C source code that was then compiled by the C compiler. Sun C++ 4.x in 1993 compiled directly to object code. Going through C source code created inefficiencies that need not be suffered in a new compiler, so this compiler got a new ABI. The 1998 C++ standard added features and changed features that could not be supported by, or required changes in, the C++ 4.x ABI. C++ 5.x therefore got a new ABI. For compatibility, C++ 5.x can also generate the C++ 4.x ABI. The C++ 5.x ABI has known bugs that we cannot fix without breaking binary compatibility. To help customers who could not work around the ABI bugs, we added an undocumented compiler option to generate a correct ABI, but one that was incompatible with the default ABI. The 2010 C++ Standard will require a new ABI for at least the library. Some basic language features arguably require an ABI change. We will take advantage of this situation to release C++ 6.x with a new ABI that fixes known bugs, and a fully-conforming library (almost certainly Apache libstdcxx). We will support the C++ 5.x ABI and continue to provide libCstd. Whether we will provide STLport is not yet decided. CONCLUSION: 1. Sometimes bugs are discovered and you have to choose between stability and correctness. 2. Changes in the language definition can require an incompatible ABI. --- Steve Clamage, stephen.clamage@sun.com From gdamore@sun.com Thu Sep 4 14:13:41 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84LDeHm015356 for ; Thu, 4 Sep 2008 14:13:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m84LDZXR014928 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 05:13:39 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00A0DWAOZQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 14:13:36 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O003G2WAOEKC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 14:13:36 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84LDaGu021729 for ; Thu, 04 Sep 2008 14:13:36 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00I01VWUYE00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 14:13:36 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00NSTWAK3D20@fe-sfbay-09.sun.com>; Thu, 04 Sep 2008 14:13:33 -0700 (PDT) Date: Thu, 04 Sep 2008 14:12:50 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C0447B.2050002@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Stefan Teleman , Nicolas Williams , Steve Clamage , Gary Winiger , Joep.Vesseur@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, PSARC-ext@sun.com, gww@eng.sun.com Message-id: <48C04F52.9050005@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1813 John Plocher wrote: > Garrett D'Amore wrote: >> I don't see Gnu C++ mentioned explicitly, > > It mentions C++ ABI - something that Studio has and g++ does not. > From an ARC perspective, that is all that really matters. > > Note the dates on the document - 1993-ish. One reason it is not > on OS.o is that it needs updating, which is not a trivial job. > >> Right now, it doesn't seem like any of our binary compatibility >> guarantees apply to any dynamically linked C++ code, > > Rather, dynamically linked C++ libraries that are NOT ABI Compliant. > Studio C++ does generate ABI Compliant code, g++ does not. > >> and this case (as proposed) proposes to set new precedent here. > > What would that be? You've supplied (in previous e-mail) other documents providing more detail than the reference Stefan supplied. Anyway, this case essentially proposes to create a new ABI, *not* based on version 5 libC, but based on a different library (I'm not talking about the Compiler's ABI, but the "overall" ABI composed of the library and the compiler combined.) While this might not be the large precedent I first thought it was, I still don't think it appropriate to do so without a full case. It violates the normal obviousness and non-controversialness rules for fast tracks. A reduced-scope delivery of the library, with project or consolidation private bindings would be satisfactory So, let me put this into direct, actionable terms: 1) If the project is willing to reduce the scope to project or consolidation private, then I withdraw my objections. 2) Else, *I* will derail the project. (Note that derail != deny, but it affords us time to ensure that the project is properly reviewed, and the opportunity to give appropriate advice.) Is that sufficiently clear enough? -- Garrett From Stefan.Teleman@sun.com Thu Sep 4 14:33:35 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84LXYFg016620 for ; Thu, 4 Sep 2008 14:33:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m84LXKMn016763; Thu, 4 Sep 2008 22:33:30 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00A03X7RKH00@nwk-avmta-2.sfbay.sun.com>; Thu, 04 Sep 2008 14:33:27 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O0020UX7QNND0@nwk-avmta-2.sfbay.sun.com>; Thu, 04 Sep 2008 14:33:26 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m84LXOJ8023985; Thu, 04 Sep 2008 14:33:25 -0700 (PDT) Date: Thu, 04 Sep 2008 17:33:24 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C04F52.9050005@sun.com> To: "Garrett D'Amore" Cc: John Plocher , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@sun.com, Bart.Smaalders@sun.com Reply-to: Stefan Teleman Message-id: <48C05424.9000205@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id m84LXYFg016620 Status: RO Content-Length: 2385 Garrett D'Amore wrote: > John Plocher wrote: >> Garrett D'Amore wrote: >>> I don't see Gnu C++ mentioned explicitly, >> It mentions C++ ABI - something that Studio has and g++ does not. >> From an ARC perspective, that is all that really matters. >> >> Note the dates on the document - 1993-ish. One reason it is not >> on OS.o is that it needs updating, which is not a trivial job. >> >>> Right now, it doesn't seem like any of our binary compatibility >>> guarantees apply to any dynamically linked C++ code, >> Rather, dynamically linked C++ libraries that are NOT ABI Compliant. >> Studio C++ does generate ABI Compliant code, g++ does not. >> >>> and this case (as proposed) proposes to set new precedent here. >> What would that be? > > You've supplied (in previous e-mail) other documents providing more > detail than the reference Stefan supplied. > > Anyway, this case essentially proposes to create a new ABI, *not* based > on version 5 libC, but based on a different library (I'm not talking > about the Compiler's ABI, but the "overall" ABI composed of the library > and the compiler combined.) ¹While this might not be the large precedent > I first thought it was, I still don't think it appropriate to do so > without a full case. It violates the normal obviousness and > non-controversialness rules for fast tracks. > > A reduced-scope delivery of the library, with project or consolidation > private bindings would be satisfactory > > So, let me put this into direct, actionable terms: > > 1) If the project is willing to reduce the scope to project or > consolidation private, then I withdraw my objections. Project/Consolidation Private to whom ? Both KDE and JDS intend to use it. That would defeat the purpose of the integration in the first place. You are essentially saying: 1. We are introducing a Standard compliant library which was not present before. 2. You [ Solaris Developer | Sun Customer ] have been waiting for this library for 10 years. 3. This library tracks the 2003 C++ Standard. 4. You [ Solaris Developer | Sun Customer ] cannot use this library. > 2) Else, *I* will derail the project. (Note that derail != deny, but it > affords us time to ensure that the project is properly reviewed, and the > opportunity to give appropriate advice.) --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gdamore@sun.com Thu Sep 4 15:23:45 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84MNjAC017711 for ; Thu, 4 Sep 2008 15:23:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84MNhQo005547 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 15:23:45 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6O00305ZJJB500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 16:23:43 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6O00M0XZJIC450@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 16:23:43 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84MNgIk000381 for ; Thu, 04 Sep 2008 15:23:42 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00901ZI9UM00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 15:23:42 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O00APOZJHPN50@fe-sfbay-10.sun.com>; Thu, 04 Sep 2008 15:23:42 -0700 (PDT) Date: Thu, 04 Sep 2008 15:22:58 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C05424.9000205@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John Plocher , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@sun.com, Bart.Smaalders@sun.com Message-id: <48C05FC2.7040303@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3928 Stefan Teleman wrote: > > > Garrett D'Amore wrote: >> John Plocher wrote: >>> Garrett D'Amore wrote: >>>> I don't see Gnu C++ mentioned explicitly, >>> It mentions C++ ABI - something that Studio has and g++ does not. >>> From an ARC perspective, that is all that really matters. >>> >>> Note the dates on the document - 1993-ish. One reason it is not >>> on OS.o is that it needs updating, which is not a trivial job. >>> >>>> Right now, it doesn't seem like any of our binary compatibility >>>> guarantees apply to any dynamically linked C++ code, >>> Rather, dynamically linked C++ libraries that are NOT ABI Compliant. >>> Studio C++ does generate ABI Compliant code, g++ does not. >>> >>>> and this case (as proposed) proposes to set new precedent here. >>> What would that be? >> >> You've supplied (in previous e-mail) other documents providing more >> detail than the reference Stefan supplied. >> >> Anyway, this case essentially proposes to create a new ABI, *not* >> based on version 5 libC, but based on a different library (I'm not >> talking about the Compiler's ABI, but the "overall" ABI composed of >> the library and the compiler combined.) > ¹While this might not be the large precedent >> I first thought it was, I still don't think it appropriate to do so >> without a full case. It violates the normal obviousness and >> non-controversialness rules for fast tracks. >> >> A reduced-scope delivery of the library, with project or >> consolidation private bindings would be satisfactory >> >> So, let me put this into direct, actionable terms: >> >> 1) If the project is willing to reduce the scope to project or >> consolidation private, then I withdraw my objections. > > Project/Consolidation Private to whom ? Both KDE and JDS intend to use > it. Then perhaps each of them winds up with their own project private copies. Or perhaps one of them gets a contract from the other. I don't know what the best solution involving non-public binding is. Clearly, a Public Committed API is better. I just don't think a Public Committed API and (more importantly) ABI can be arrived at in the scope of a fast track. > > That would defeat the purpose of the integration in the first place. > > You are essentially saying: > > 1. We are introducing a Standard compliant library which was not > present before. > 2. You [ Solaris Developer | Sun Customer ] have been waiting for this > library for 10 years. > 3. This library tracks the 2003 C++ Standard. > 4. You [ Solaris Developer | Sun Customer ] cannot use this library. I'm saying that this is true *unless* you're willing to step up to the plate to provide the guarantees that would be required, and that I think it would require a full case review in order to fully assess that. I'm *not* saying we can't or shouldn't ship this. I'm saying that we shouldn't do the job improperly. PLEASE, don't make the mistake of believing that that derail == deny. All derail means is that the project falls outside of the scope of "obviousness" that makes it appropriate for a fast track. The large amount of discussion we've already had around this project (and continued levels of "discovery" surrounding the case) strongly represent to me that this case is *not* obvious, and should not be a fast track. *However*, if you're only worried about one or two consumers, and are willing to have a greatly reduced commitment, then I'm willing to stand aside and let it go as a fast track. But lets not pretend that you can create a new C++ ABI (and thats what this case as proposed would do!) without properly addressing the compatibility considerations and without a regular and complete review. -- Garrett > >> 2) Else, *I* will derail the project. (Note that derail != deny, but >> it affords us time to ensure that the project is properly reviewed, >> and the opportunity to give appropriate advice.) > > --Stefan > From Stefan.Teleman@sun.com Thu Sep 4 16:57:58 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m84NvvCg020890 for ; Thu, 4 Sep 2008 16:57:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m84NvsIg002629; Thu, 4 Sep 2008 17:57:54 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6P00A033WIAP00@brm-avmta-1.central.sun.com>; Thu, 04 Sep 2008 17:57:54 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6P00MMH3WHCAA0@brm-avmta-1.central.sun.com>; Thu, 04 Sep 2008 17:57:54 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m84Nvpb8016988; Thu, 04 Sep 2008 16:57:52 -0700 (PDT) Date: Thu, 04 Sep 2008 19:57:51 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C05FC2.7040303@sun.com> To: "Garrett D'Amore" Cc: John Plocher , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@sun.com, Bart.Smaalders@sun.com Reply-to: Stefan Teleman Message-id: <48C075FF.6060608@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id m84NvvCg020890 Status: RO Content-Length: 4849 Garrett D'Amore wrote: > Then perhaps each of them winds up with their own project private > copies. Or perhaps one of them gets a contract from the other. I don't > know what the best solution involving non-public binding is. Clearly, a > Public Committed API is better. I just don't think a Public Committed > API and (more importantly) ABI can be arrived at in the scope of a fast > track. >> >> That would defeat the purpose of the integration in the first place. >> >> You are essentially saying: >> >> 1. We are introducing a Standard compliant library which was not >> present before. >> 2. You [ Solaris Developer | Sun Customer ] have been waiting for this >> library for 10 years. >> 3. This library tracks the 2003 C++ Standard. >> 4. You [ Solaris Developer | Sun Customer ] cannot use this library. > > I'm saying that this is true *unless* you're willing to step up to the > plate to provide the guarantees that would be required, and that I think > it would require a full case review in order to fully assess that. Which guarantees ? The library guarantees ABI stability within Major Release 4 boundaries. It also implements an Industry Standard. As such, it is suitable for a Committed classification. However, you oppose this stability classification. This is one example of a guarantee provided by this library, which you oppose. Where are the specifications for these other guarantees that you are seeking ? Where have these constraints -- controlling these unspecified guarantees -- been defined ? You are opposing the guarantees explicitly provided by the library, and instead, you seek an unspecified set of other guarantees, for which you have not provided constraint definitions. This fast-track cannot address architectural requirements constraints which are: 1. Outside the scope of the case itself. 2. Intangible and/or impossible to define (example: ävoid developer confusion). 3. Based on the introduction of continuously changing requirements, or definitions. > I'm *not* saying we can't or shouldn't ship this. I'm saying that we > shouldn't do the job improperly. > > PLEASE, don't make the mistake of believing that that derail == deny. > All derail means is that the project falls outside of the scope of > "obviousness" that makes it appropriate for a fast track. The large > amount of discussion we've already had around this project (and > continued levels of "discovery" surrounding the case) strongly represent > to me that this case is *not* obvious, and should not be a fast track. The large amount of discussion generated by this case has discovered nothing that was not already specified in the ARC Case. > *However*, if you're only worried about one or two consumers, and are > willing to have a greatly reduced commitment, then I'm willing to stand > aside and let it go as a fast track. > > But lets not pretend that you can create a new C++ ABI (and thats what > this case as proposed would do!) without properly addressing the > compatibility considerations and without a regular and complete review. This is a very good example of constantly changing constraint requirements, and definitions. Nowhere has this cased proposed the creation of a new C++ ABI. Extending the scope of this Case from clearly defined library ABI incompatibilities, to C++ Language ABI compatibility considerations, is a stretch, and it is not supported by the facts. The library incompatibility constraints have been clearly defined in the existing ARC Case. C++ Language ABI considerations are beyond the scope of this Case. It is already known that the next iteration of the C++ Standard will break the existing Compiler ABI, and the library ABI. As such, any considerations of library ABI incompatibility concerning this ARC Case are irrelevant for the next iteration of the library, or for the next Language implementation itself. This library's ABI is incompatible with another two, existing, library ABI's. The three libraries are not equivalent, they do not provide the same facilities, they are not interchangeable, and they are mutually exclusive. Accidental inclusion of the new C++ library is not possible: the new library must be explicitly enabled, and the existing default library must be explicitly disabled in the compiler. Accidental inclusion of the new library's header files is not possible: the header files are not present in the default compiler search path. The Standard C++ Language does not require the inclusion, or linkage, of, the Standard C++ Library, in a program, or library. For example, the libGLU.so (component of OpenGL, currently present in Solaris) is written in C++, and does not use, or link against, the Standard C++ Library at all. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gdamore@sun.com Thu Sep 4 21:48:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m854mIJU028948 for ; Thu, 4 Sep 2008 21:48:18 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m854mHr0011049 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Sep 2008 21:48:18 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6P00715HCIOM00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 21:48:18 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6P00DAYHCHKEC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 21:48:18 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m854mHMM027062 for ; Thu, 04 Sep 2008 21:48:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6P00101H7BZC00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Sep 2008 21:48:17 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6P00KD8HCGNWA0@fe-sfbay-10.sun.com>; Thu, 04 Sep 2008 21:48:17 -0700 (PDT) Date: Thu, 04 Sep 2008 21:47:32 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C075FF.6060608@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John Plocher , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@sun.com, Bart.Smaalders@sun.com Message-id: <48C0B9E4.8070803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 8408 Stefan Teleman wrote: > > > Garrett D'Amore wrote: > >> Then perhaps each of them winds up with their own project private >> copies. Or perhaps one of them gets a contract from the other. I >> don't know what the best solution involving non-public binding is. >> Clearly, a Public Committed API is better. I just don't think a >> Public Committed API and (more importantly) ABI can be arrived at in >> the scope of a fast track. >>> >>> That would defeat the purpose of the integration in the first place. >>> >>> You are essentially saying: >>> >>> 1. We are introducing a Standard compliant library which was not >>> present before. >>> 2. You [ Solaris Developer | Sun Customer ] have been waiting for >>> this library for 10 years. >>> 3. This library tracks the 2003 C++ Standard. >>> 4. You [ Solaris Developer | Sun Customer ] cannot use this library. >> >> I'm saying that this is true *unless* you're willing to step up to >> the plate to provide the guarantees that would be required, and that >> I think it would require a full case review in order to fully assess >> that. > > Which guarantees ? > > The library guarantees ABI stability within Major Release 4 > boundaries. It also implements an Industry Standard. As such, it is > suitable for a Committed classification. However, you oppose this > stability classification. This is one example of a guarantee provided > by this library, which you oppose. > > Where are the specifications for these other guarantees that you are > seeking ? Where have these constraints -- controlling these > unspecified guarantees -- been defined ? > > You are opposing the guarantees explicitly provided by the library, > and instead, you seek an unspecified set of other guarantees, for > which you have not provided constraint definitions. > > This fast-track cannot address architectural requirements constraints > which are: > > 1. Outside the scope of the case itself. > 2. Intangible and/or impossible to define (example: ävoid developer > confusion). > 3. Based on the introduction of continuously changing requirements, or > definitions. Okay, we have a significant failure to communicate. First off, *SOURCE* level commitment is *NOT* the same as binary commitment. The Standard says *nothing* about binary commitment. I understand that the project seeks to provide a conforming implementation of the Standard -- that says *nothing* about compatibility of applications or libraries provided here. All those other "constraints" are certainly *in scope* if you seek to create a new binary ABI for C++ programs. If you're talking about a new stable base library (instead of the shipping libC) then this is what you're doing. Let's be 100% clear here: There are exactly three ways forward for the project team (short of trying to do something to get me ejected from PSARC): 1) reduce the scope of what you're supplying to Project or Consolidation Private or 2) have your case derailed (voluntarily or otherwise) into a full case, and deal with the full consequences of creating a new C++ ABI for Solaris or 3) withdraw your case altogether. My personal preference at this point is #2. Unless you state your intention to follow course 1 or course 3, please consider your case derailed. I'm willing to talk off line with you and the compiler folks to help formulate appropriate materials for a full case. -- Garrett (I have other responses inline below, but they may or may not be worthwhile.) > >> I'm *not* saying we can't or shouldn't ship this. I'm saying that we >> shouldn't do the job improperly. >> >> PLEASE, don't make the mistake of believing that that derail == deny. >> All derail means is that the project falls outside of the scope of >> "obviousness" that makes it appropriate for a fast track. The large >> amount of discussion we've already had around this project (and >> continued levels of "discovery" surrounding the case) strongly >> represent to me that this case is *not* obvious, and should not be a >> fast track. > > The large amount of discussion generated by this case has discovered > nothing that was not already specified in the ARC Case. Not true. The details of the i18n were not specified originally. The plans of the compiler group were not specified. The interaction with g++ was not well specified (nor the fact that g++ support isn't needed.) And, the discovery (at least on my part) of prior case work specifying that we actually already have a C++ ABI that this project would be breaking, may not be new information, but it was new *to me*, and certainly wasn't spelled out in the materials. > >> *However*, if you're only worried about one or two consumers, and are >> willing to have a greatly reduced commitment, then I'm willing to >> stand aside and let it go as a fast track. >> >> But lets not pretend that you can create a new C++ ABI (and thats >> what this case as proposed would do!) without properly addressing the >> compatibility considerations and without a regular and complete review. > > This is a very good example of constantly changing constraint > requirements, and definitions. Nowhere has this cased proposed the > creation of a new C++ ABI. Extending the scope of this Case from > clearly defined library ABI incompatibilities, to C++ Language ABI > compatibility considerations, is a stretch, and it is not supported by > the facts. If you're going to create a Committed C++ library that is incompatible with libC, then by *definition* you are creating a new C++ ABI. Even though you didn't say this was your intent, it is the natural effect of what you're proposing to deliver. > > The library incompatibility constraints have been clearly defined in > the existing ARC Case. C++ Language ABI considerations are beyond the > scope of this Case. We seem to be talking across each other. The ABI derives from the *combination* of the compiler used *AND* the base library (or libraries) used. By introducing a new base library, you are creating a new ABI. > > It is already known that the next iteration of the C++ Standard will > break the existing Compiler ABI, and the library ABI. As such, any > considerations of library ABI incompatibility concerning this ARC Case > are irrelevant for the next iteration of the library, or for the next > Language implementation itself. Yes, we don't know what the next iteration of the language, or possibly the library, will do. But our customers *insist* on a stable foundation that doesn't change underneath them. This means that we have to provide some reasonable guarantees that the parts will fit together. You can't slide by on saying "the future changes to the language may break future compatibility"... the precedents already set by the libC integration and C++ ABI cases are against you here. > > This library's ABI is incompatible with another two, existing, library > ABI's. The three libraries are not equivalent, they do not provide the > same facilities, they are not interchangeable, and they are mutually > exclusive. Accidental inclusion of the new C++ library is not > possible: the new library must be explicitly enabled, and the existing > default library must be explicitly disabled in the compiler. > Accidental inclusion of the new library's header files is not > possible: the header files are not present in the default compiler > search path. There are serious problems with the incompatibilities though -- how does a developer know which library should be used? So far we have had exactly *one* recommendation (one allowed library) for developers to build upon. Other choices were verboten because of binary incompatibilities (though individual applications were and remain free to choose an alternate C++ base library, such use has many caveats and effectively prevents granting any kind of Committed binding to C++ libraries *other* than those built upon libC. > > The Standard C++ Language does not require the inclusion, or linkage, > of, the Standard C++ Library, in a program, or library. For example, > the libGLU.so (component of OpenGL, currently present in Solaris) is > written in C++, and does not use, or link against, the Standard C++ > Library at all. And that isn't a problem. This fact is totally orthogonal to your case or and my concerns. -- Garrett From Stefan.Teleman@Sun.COM Thu Sep 4 22:10:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m855ANln029399 for ; Thu, 4 Sep 2008 22:10:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m855A7gL012747; Fri, 5 Sep 2008 06:10:18 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6P00805ID2RD00@nwk-avmta-2.sfbay.sun.com>; Thu, 04 Sep 2008 22:10:14 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6P00D1WID1KNE0@nwk-avmta-2.sfbay.sun.com>; Thu, 04 Sep 2008 22:10:13 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m855ACjW009808; Thu, 04 Sep 2008 22:10:12 -0700 (PDT) Date: Fri, 05 Sep 2008 01:10:11 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C0B9E4.8070803@sun.com> To: "Garrett D'Amore" Cc: John Plocher , John.Fischer@Sun.COM, Joep.Vesseur@Sun.COM, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@Sun.COM, Bart.Smaalders@Sun.COM Reply-to: Stefan Teleman Message-id: <48C0BF33.2080407@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id m855ANln029399 Status: RO Content-Length: 4253 Garrett D'Amore wrote: >>> I'm saying that this is true *unless* you're willing to step up to >>> the plate to provide the guarantees that would be required, and that >>> I think it would require a full case review in order to fully assess >>> that. >> >> Which guarantees ? >> >> The library guarantees ABI stability within Major Release 4 >> boundaries. It also implements an Industry Standard. As such, it is >> suitable for a Committed classification. However, you oppose this >> stability classification. This is one example of a guarantee provided >> by this library, which you oppose. >> >> Where are the specifications for these other guarantees that you are >> seeking ? Where have these constraints -- controlling these >> unspecified guarantees -- been defined ? >> >> You are opposing the guarantees explicitly provided by the library, >> and instead, you seek an unspecified set of other guarantees, for >> which you have not provided constraint definitions. >> >> This fast-track cannot address architectural requirements constraints >> which are: >> >> 1. Outside the scope of the case itself. >> 2. Intangible and/or impossible to define (example: ävoid developer >> confusion). >> 3. Based on the introduction of continuously changing requirements, or >> definitions. > > Okay, we have a significant failure to communicate. > > First off, *SOURCE* level commitment is *NOT* the same as binary > commitment. 1. What is the definition of *SOURCE* level commitment ? Please explain, for the record. 2. How does this definition of source level commitment apply to this Case ? Please explain, for the record. > The Standard says *nothing* about binary commitment. Correct. It has already been explained to you why the Standard Committee chose to make that decision. However, the *IMPLEMENTATION* of the library makes a very clear binary compatibility commitment. This commitment has already been stated in the Case Materials. > I understand that the project seeks to provide a conforming implementation > of the Standard -- that says *nothing* about compatibility of > applications or libraries provided here. The ARC Case explicitly states *ALL* the compatibility constraints. The integration provides no applications, only a shared library and associated header files. The assertion that the ARC Case says nothing about compatibility of applications or libraries provided here, is false. > All those other "constraints" are certainly *in scope* if you seek to > create a new binary ABI for C++ programs. I am not, and I have already stated that this Case does not introduce a new C++ ABI. You have made this assertion. This assertion is not supported by the facts. > If you're talking about a new > stable base library (instead of the shipping libC) then this is what > you're doing. This is precisely *NOT* what I am doing. Nowhere has this case proposed the introduction of a "new stable base library instead of the shipping libC". The existing libCstd.so will continue to ship. The existing libCrun.so is needed by the Apache Library. The assertion, or inference, that the Apache Library proposed by this Case attempts to replace the existing libCstd.so, is false. > Let's be 100% clear here: > > There are exactly three ways forward for the project team (short of > trying to do something to get me ejected from PSARC): For the record, I am not interested in backroom politics. Maybe I should be. > 1) reduce the scope of what you're supplying to Project or Consolidation > Private > > or > > 2) have your case derailed (voluntarily or otherwise) into a full case, > and deal with the full consequences of creating a new C++ ABI for Solaris > > or > > 3) withdraw your case altogether. > > My personal preference at this point is #2. Unless you state your > intention to follow course 1 or course 3, please consider your case > derailed. I'm willing to talk off line with you and the compiler folks > to help formulate appropriate materials for a full case. I will not reduce the scope to Project/Consolidation Private, I will not voluntarily derail, nor will I voluntarily withdraw it. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From carlsonj@phorcys.east.sun.com Fri Sep 5 04:19:57 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85BJvL8007744 for ; Fri, 5 Sep 2008 04:19:57 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m85BJrwI047120; Fri, 5 Sep 2008 05:19:55 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6P00E03ZH6Y200@brm-avmta-1.central.sun.com>; Fri, 05 Sep 2008 05:19:54 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6P001JNZH4EJ90@brm-avmta-1.central.sun.com>; Fri, 05 Sep 2008 05:19:53 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m85BJqqG016401; Fri, 05 Sep 2008 07:19:52 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m85BJq2a016398; Fri, 05 Sep 2008 07:19:52 -0400 (EDT) Date: Fri, 05 Sep 2008 07:19:52 -0400 From: James Carlson Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C0BF33.2080407@Sun.COM> To: Stefan Teleman Cc: PSARC-ext@sun.com, Steve Clamage Message-id: <18625.5592.514157.718611@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> Status: RO Content-Length: 1583 Stefan Teleman writes: > > My personal preference at this point is #2. Unless you state your > > intention to follow course 1 or course 3, please consider your case > > derailed. I'm willing to talk off line with you and the compiler folks > > to help formulate appropriate materials for a full case. > > I will not reduce the scope to Project/Consolidation Private, I will not > voluntarily derail, nor will I voluntarily withdraw it. I don't want to get drawn back into this absurd back-and-forth, but I'll still offer one point of possibly useful clarification: "derail" is in no way related to "deny." "Derail" simply means that we need to get this project on the PSARC agenda as soon as possible (Wednesday next week would be the earliest regularly scheduled meeting, but in the past we've scheduled meetings outside of the usual time in order to handle extraordinary requests) so that it can be discussed in real time, rather than by email flame fest. Given the volume of email, even if this case were to be approved as originally written, I don't think I'm alone in being confused about the implications. That's a clear "this is not suitable for fast-track treatment" sign, as fast-tracks are supposed to be "obvious" and "non-controversial." Derailing (voluntarily or otherwise) looks to me like the best way forward for the project team. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gdamore@sun.com Fri Sep 5 06:56:00 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85DtxqX012164 for ; Fri, 5 Sep 2008 06:55:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m85DttWf027576 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 14:55:58 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q0070D6P8F300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 06:55:56 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q005BZ6P72GC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 06:55:55 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m85DttCE012893 for ; Fri, 05 Sep 2008 06:55:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q00I016O2E700@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 06:55:55 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q002JR6P68AC0@fe-sfbay-09.sun.com>; Fri, 05 Sep 2008 06:55:55 -0700 (PDT) Date: Fri, 05 Sep 2008 06:55:07 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C0BF33.2080407@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John Plocher , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@sun.com, Bart.Smaalders@sun.com Message-id: <48C13A3B.7080908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1054 Stefan Teleman wrote: > > >> 1) reduce the scope of what you're supplying to Project or >> Consolidation Private >> >> or >> >> 2) have your case derailed (voluntarily or otherwise) into a full >> case, and deal with the full consequences of creating a new C++ ABI >> for Solaris >> >> or >> >> 3) withdraw your case altogether. >> >> My personal preference at this point is #2. Unless you state your >> intention to follow course 1 or course 3, please consider your case >> derailed. I'm willing to talk off line with you and the compiler >> folks to help formulate appropriate materials for a full case. > > I will not reduce the scope to Project/Consolidation Private, I will > not voluntarily derail, nor will I voluntarily withdraw it. Okay, then I am derailing this project. The next step is probably for you to meet with me offline, so I can explain my concerns (and possibly with other people), and figure out what materials are appropriate for a full case. Then you'll need to ask the ARC coordinator for a slot. -- Garrett From John.Fischer@sun.com Fri Sep 5 10:46:02 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85Hk10C020665 for ; Fri, 5 Sep 2008 10:46:02 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m85Hjx1I058467 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 11:46:01 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q0070VHCP8S00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 10:46:01 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q003M9HCOYE20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 10:46:00 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m85Hk0kr029391 for ; Fri, 05 Sep 2008 10:46:00 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q00901H51TB00@fe-sfbay-10.sun.com> (original mail from John.Fischer@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 10:46:00 -0700 (PDT) Received: from [192.168.10.13] ([76.20.56.47]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q00ML9HCM1250@fe-sfbay-10.sun.com>; Fri, 05 Sep 2008 10:45:59 -0700 (PDT) Date: Fri, 05 Sep 2008 10:45:47 -0700 From: John Fischer Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C0BF33.2080407@Sun.COM> Sender: John.Fischer@sun.com To: Stefan Teleman Cc: "Garrett D'Amore" , John Plocher , Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@sun.com, Bart.Smaalders@sun.com, John Fischer Reply-to: John.Fischer@sun.com Message-id: <48C1704B.7000709@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 6216 Stefan, The project being derailed by a committee member means that the case can still move forward. However, additional materials must be created or a meeting scheduled to discuss the remaining issues. It does not mean that the case has been denied. It simply means that the committee can not make a decision based upon the discussion and materials. This is a procedural issue for us to navigate through the process. It simply means that we need a slightly different approach and is out of our hands on keeping the "train on the rails". As Garrett has pointed out there are a couple of different routes that the project team can go down. These options being: 1. modify the case to address the concerns 2. schedule a meeting with additional materials addressing the concerns 3. withdraw the case It is clear that you do not want to withdraw the case. I agree it is necessary for JDS and KDE moving forward. So that is out of the question. It is also clear that making the interfaces Project Private is also out of the question as it is needed by various consolidations and also would be beneficial to our customers. Lowering the interface from Committed to either Volatile or Uncommitted might work as the interface could be used internally and customers could us it understanding that the interface might change in the future. This might also allow the project to move forward. Alternatively if you want to move forward and keep the interfaces Committed then we will need to schedule a meeting with appropriate materials. It looks like the materials need to be updated with at least stating that the interfaces implement I18N and there might be a little bit more to add just to clarify various points. I would also expect to see some sort of document describing the transition plans from SFW to the DevPro group. Thanks, John Stefan Teleman wrote: > > > Garrett D'Amore wrote: > >>>> I'm saying that this is true *unless* you're willing to step up to >>>> the plate to provide the guarantees that would be required, and that >>>> I think it would require a full case review in order to fully assess >>>> that. >>> >>> Which guarantees ? >>> >>> The library guarantees ABI stability within Major Release 4 >>> boundaries. It also implements an Industry Standard. As such, it is >>> suitable for a Committed classification. However, you oppose this >>> stability classification. This is one example of a guarantee provided >>> by this library, which you oppose. >>> >>> Where are the specifications for these other guarantees that you are >>> seeking ? Where have these constraints -- controlling these >>> unspecified guarantees -- been defined ? >>> >>> You are opposing the guarantees explicitly provided by the library, >>> and instead, you seek an unspecified set of other guarantees, for >>> which you have not provided constraint definitions. >>> >>> This fast-track cannot address architectural requirements constraints >>> which are: >>> >>> 1. Outside the scope of the case itself. >>> 2. Intangible and/or impossible to define (example: ävoid developer >>> confusion). >>> 3. Based on the introduction of continuously changing requirements, >>> or definitions. >> >> Okay, we have a significant failure to communicate. >> >> First off, *SOURCE* level commitment is *NOT* the same as binary >> commitment. > > 1. What is the definition of *SOURCE* level commitment ? Please explain, > for the record. > 2. How does this definition of source level commitment apply to this > Case ? Please explain, for the record. > >> The Standard says *nothing* about binary commitment. > > Correct. It has already been explained to you why the Standard Committee > chose to make that decision. > > However, the *IMPLEMENTATION* of the library makes a very clear binary > compatibility commitment. This commitment has already been stated in the > Case Materials. > >> I understand that the project seeks to provide a conforming >> implementation of the Standard -- that says *nothing* about >> compatibility of applications or libraries provided here. > > The ARC Case explicitly states *ALL* the compatibility constraints. The > integration provides no applications, only a shared library and > associated header files. The assertion that the ARC Case says nothing > about compatibility of applications or libraries provided here, is false. > >> All those other "constraints" are certainly *in scope* if you seek to >> create a new binary ABI for C++ programs. > > I am not, and I have already stated that this Case does not introduce a > new C++ ABI. You have made this assertion. This assertion is not > supported by the facts. > >> If you're talking about a new stable base library (instead of the >> shipping libC) then this is what you're doing. > > This is precisely *NOT* what I am doing. Nowhere has this case proposed > the introduction of a "new stable base library instead of the shipping > libC". The existing libCstd.so will continue to ship. The existing > libCrun.so is needed by the Apache Library. > > The assertion, or inference, that the Apache Library proposed by this > Case attempts to replace the existing libCstd.so, is false. > >> Let's be 100% clear here: >> >> There are exactly three ways forward for the project team (short of >> trying to do something to get me ejected from PSARC): > > For the record, I am not interested in backroom politics. Maybe I should > be. > >> 1) reduce the scope of what you're supplying to Project or >> Consolidation Private >> >> or >> >> 2) have your case derailed (voluntarily or otherwise) into a full >> case, and deal with the full consequences of creating a new C++ ABI >> for Solaris >> >> or >> >> 3) withdraw your case altogether. >> >> My personal preference at this point is #2. Unless you state your >> intention to follow course 1 or course 3, please consider your case >> derailed. I'm willing to talk off line with you and the compiler >> folks to help formulate appropriate materials for a full case. > > I will not reduce the scope to Project/Consolidation Private, I will not > voluntarily derail, nor will I voluntarily withdraw it. > > --Stefan > From gdamore@sun.com Fri Sep 5 10:56:33 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85HuWCn021010 for ; Fri, 5 Sep 2008 10:56:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m85HuQJV008508 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 18:56:31 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q00J09HU6BL00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 11:56:30 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q004K2HU50VB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 11:56:29 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m85HuTxD000931 for ; Fri, 05 Sep 2008 10:56:29 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q00501HN24L00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 10:56:29 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q00MR9HU112A0@fe-sfbay-10.sun.com>; Fri, 05 Sep 2008 10:56:25 -0700 (PDT) Date: Fri, 05 Sep 2008 10:55:36 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1704B.7000709@sun.com> Sender: Garrett.Damore@sun.com To: John.Fischer@sun.com Cc: Stefan Teleman , John Plocher , Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@sun.com, Bart.Smaalders@sun.com Message-id: <48C17298.3020706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 7147 Volatile binding with an admonishment in the man pages indicating the compatibility hazards associated would be an agreeable compromise. (Uncommitted is, IMO, still a higher level of commitment than I'd be happy with, at least not without some kind of formal plan to ensure compatibility continuity.) One of the implications of such a binding (Volatile), is that projects which build other C++ shared libraries upon this one cannot have a commitment level higher than Volatile either. Note that the Volatile commitment level could be *increased* at a future point in time, if the project team is able to bring a case justifying such an increase (i.e. address the compatibility concerns) to ARC. -- Garrett John Fischer wrote: > Stefan, > > The project being derailed by a committee member means that the case > can still move forward. However, additional materials must be created > or a meeting scheduled to discuss the remaining issues. It does not > mean that the case has been denied. It simply means that the committee > can not make a decision based upon the discussion and materials. This > is a procedural issue for us to navigate through the process. It simply > means that we need a slightly different approach and is out of our > hands on keeping the "train on the rails". > > As Garrett has pointed out there are a couple of different routes that > the project team can go down. These options being: > > 1. modify the case to address the concerns > 2. schedule a meeting with additional materials addressing > the concerns > 3. withdraw the case > > It is clear that you do not want to withdraw the case. I agree it > is necessary for JDS and KDE moving forward. So that is out of the > question. > > It is also clear that making the interfaces Project Private is also > out of the question as it is needed by various consolidations and > also would be beneficial to our customers. Lowering the interface > from Committed to either Volatile or Uncommitted might work as the > interface could be used internally and customers could us it > understanding that the interface might change in the future. This > might also allow the project to move forward. > > Alternatively if you want to move forward and keep the interfaces > Committed then we will need to schedule a meeting with appropriate > materials. It looks like the materials need to be updated with at > least stating that the interfaces implement I18N and there might be > a little bit more to add just to clarify various points. I would also > expect to see some sort of document describing the transition plans from > SFW to the DevPro group. > > Thanks, > > John > > > Stefan Teleman wrote: >> >> >> Garrett D'Amore wrote: >> >>>>> I'm saying that this is true *unless* you're willing to step up to >>>>> the plate to provide the guarantees that would be required, and >>>>> that I think it would require a full case review in order to fully >>>>> assess that. >>>> >>>> Which guarantees ? >>>> >>>> The library guarantees ABI stability within Major Release 4 >>>> boundaries. It also implements an Industry Standard. As such, it is >>>> suitable for a Committed classification. However, you oppose this >>>> stability classification. This is one example of a guarantee >>>> provided by this library, which you oppose. >>>> >>>> Where are the specifications for these other guarantees that you >>>> are seeking ? Where have these constraints -- controlling these >>>> unspecified guarantees -- been defined ? >>>> >>>> You are opposing the guarantees explicitly provided by the library, >>>> and instead, you seek an unspecified set of other guarantees, for >>>> which you have not provided constraint definitions. >>>> >>>> This fast-track cannot address architectural requirements >>>> constraints which are: >>>> >>>> 1. Outside the scope of the case itself. >>>> 2. Intangible and/or impossible to define (example: ävoid developer >>>> confusion). >>>> 3. Based on the introduction of continuously changing requirements, >>>> or definitions. >>> >>> Okay, we have a significant failure to communicate. >>> >>> First off, *SOURCE* level commitment is *NOT* the same as binary >>> commitment. >> >> 1. What is the definition of *SOURCE* level commitment ? Please >> explain, for the record. >> 2. How does this definition of source level commitment apply to this >> Case ? Please explain, for the record. >> >>> The Standard says *nothing* about binary commitment. >> >> Correct. It has already been explained to you why the Standard >> Committee chose to make that decision. >> >> However, the *IMPLEMENTATION* of the library makes a very clear >> binary compatibility commitment. This commitment has already been >> stated in the Case Materials. >> >>> I understand that the project seeks to provide a conforming >>> implementation of the Standard -- that says *nothing* about >>> compatibility of applications or libraries provided here. >> >> The ARC Case explicitly states *ALL* the compatibility constraints. >> The integration provides no applications, only a shared library and >> associated header files. The assertion that the ARC Case says nothing >> about compatibility of applications or libraries provided here, is >> false. >> >>> All those other "constraints" are certainly *in scope* if you seek >>> to create a new binary ABI for C++ programs. >> >> I am not, and I have already stated that this Case does not introduce >> a new C++ ABI. You have made this assertion. This assertion is not >> supported by the facts. >> >>> If you're talking about a new stable base library (instead of the >>> shipping libC) then this is what you're doing. >> >> This is precisely *NOT* what I am doing. Nowhere has this case >> proposed the introduction of a "new stable base library instead of >> the shipping libC". The existing libCstd.so will continue to ship. >> The existing libCrun.so is needed by the Apache Library. >> >> The assertion, or inference, that the Apache Library proposed by this >> Case attempts to replace the existing libCstd.so, is false. >> >>> Let's be 100% clear here: >>> >>> There are exactly three ways forward for the project team (short of >>> trying to do something to get me ejected from PSARC): >> >> For the record, I am not interested in backroom politics. Maybe I >> should be. >> >>> 1) reduce the scope of what you're supplying to Project or >>> Consolidation Private >>> >>> or >>> >>> 2) have your case derailed (voluntarily or otherwise) into a full >>> case, and deal with the full consequences of creating a new C++ ABI >>> for Solaris >>> >>> or >>> >>> 3) withdraw your case altogether. >>> >>> My personal preference at this point is #2. Unless you state your >>> intention to follow course 1 or course 3, please consider your case >>> derailed. I'm willing to talk off line with you and the compiler >>> folks to help formulate appropriate materials for a full case. >> >> I will not reduce the scope to Project/Consolidation Private, I will >> not voluntarily derail, nor will I voluntarily withdraw it. >> >> --Stefan >> From John.Plocher@sun.com Fri Sep 5 10:59:52 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85HxpCS021048 for ; Fri, 5 Sep 2008 10:59:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m85Hxkaq009993 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 18:59:51 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q00J0NHZQH000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 11:59:50 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q0048WHZO0SF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 11:59:48 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m85Hxm2p014147 for ; Fri, 05 Sep 2008 10:59:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q00M01HMKX000@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 10:59:48 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q002S0HZMCFA0@fe-sfbay-09.sun.com>; Fri, 05 Sep 2008 10:59:46 -0700 (PDT) Date: Fri, 05 Sep 2008 10:59:45 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1704B.7000709@sun.com> Sender: John.Plocher@sun.com To: John.Fischer@sun.com Cc: Stefan Teleman , Joep.Vesseur@sun.com, Steve Clamage , PSARC-ext@sun.com Message-id: <48C17391.8070903@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 520 John Fischer wrote: > 1. modify the case to address the concerns > 2. schedule a meeting with additional materials addressing > the concerns 2a. schedule an information-only meeting to discuss the case AS IT IS TODAY and its implications, with the intent of having a followup meeting where a revised/expanded spec is provided. IMO, it is critical that SteveC from the compiler team be at whatever PSARC meeting is held. > 3. withdraw the case This last, IMO, would be a very bad choice. -John From Stephen.Clamage@sun.com Fri Sep 5 11:06:43 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85I6g72021195 for ; Fri, 5 Sep 2008 11:06:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m85I6cDk027299 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 02:06:41 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q00905IB3G400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 11:06:39 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q003EFIB2YO50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 11:06:38 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m85I6cII015525 for ; Fri, 05 Sep 2008 11:06:38 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q00501HN24L00@fe-sfbay-10.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 11:06:38 -0700 (PDT) Received: from [129.146.86.208] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q00MKYIAW12G0@fe-sfbay-10.sun.com>; Fri, 05 Sep 2008 11:06:32 -0700 (PDT) Date: Fri, 05 Sep 2008 11:06:32 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C17391.8070903@Sun.Com> Sender: Stephen.Clamage@sun.com To: John Plocher Cc: John.Fischer@sun.com, Stefan Teleman , Joep.Vesseur@sun.com, PSARC-ext@sun.com Message-id: <48C17528.1010007@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17391.8070903@Sun.Com> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 810 I am eager to attend any such meeting. :-) I will be away at a C++ Committee meeting the week of Sep 15-19 and will be unavailable even by phone. I will have email, however. --- Steve Clamage, stephen.clamage@sun.com On 09/05/08 10:59, John Plocher wrote: > John Fischer wrote: >> 1. modify the case to address the concerns >> 2. schedule a meeting with additional materials addressing >> the concerns > > 2a. schedule an information-only meeting to discuss the case AS IT > IS TODAY and its implications, with the intent of having a followup > meeting where a revised/expanded spec is provided. > > IMO, it is critical that SteveC from the compiler team be at whatever > PSARC meeting is held. > >> 3. withdraw the case > > This last, IMO, would be a very bad choice. > > -John From John.Plocher@sun.com Fri Sep 5 11:07:59 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85I7xCe021240 for ; Fri, 5 Sep 2008 11:07:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m85I7xUt023988 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 11:07:59 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q00K3ZIDA1T00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 12:07:58 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q004H3ID712E0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 12:07:55 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m85I7sZG015768 for ; Fri, 05 Sep 2008 11:07:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q00M01HMKX000@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 11:07:54 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q002OBID5CFF0@fe-sfbay-09.sun.com>; Fri, 05 Sep 2008 11:07:53 -0700 (PDT) Date: Fri, 05 Sep 2008 11:07:52 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C17298.3020706@sun.com> Sender: John.Plocher@sun.com To: "Garrett D'Amore" Cc: John.Fischer@sun.com, Stefan Teleman , Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@sun.com, Bart.Smaalders@sun.com Message-id: <48C17578.4040704@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 1051 Garrett D'Amore wrote: > One of the implications of such a binding (Volatile), is that projects > which build other C++ shared libraries upon this one cannot have a > commitment level higher than Volatile either. Braap. Bad Architecture Alert. The whole reason we provide abstractions like consolidations and components is precisely so that we can provide "higher than Volatile" expectations for things that theselves may exhibit "less than Volatile" stability. There is no reason this couldn't be made a part of the KDE consolidation, and maintained by them as Committed interfaces for use by any KDE consumers who need it. Volatile means "can change", not "will change", and both the Apache C++ Lib and the KDE projects certainly seem to meet the basic ARC expectations of managing the compatible evolution of their component. If the C++ basis that KDE builds upon were to change incompatibly, I'd expect KDE to react by producing a major release - again, just like the ARC would expect. Nothing here requires KDE to be Volatile. -John From gdamore@sun.com Fri Sep 5 11:58:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85IwJF0022160 for ; Fri, 5 Sep 2008 11:58:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m85Iw4Ud003165 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 19:58:18 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q00E11KP4Y100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 11:58:16 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q003X2KP3YH80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 11:58:15 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m85IwFFw011297 for ; Fri, 05 Sep 2008 11:58:15 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q00501HN24L00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 11:58:15 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q0005EKP0CLB0@fe-sfbay-10.sun.com>; Fri, 05 Sep 2008 11:58:13 -0700 (PDT) Date: Fri, 05 Sep 2008 11:57:24 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C17578.4040704@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: John.Fischer@sun.com, Stefan Teleman , Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@sun.com, Bart.Smaalders@sun.com Message-id: <48C18114.9020604@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3149 John Plocher wrote: > Garrett D'Amore wrote: >> One of the implications of such a binding (Volatile), is that >> projects which build other C++ shared libraries upon this one cannot >> have a commitment level higher than Volatile either. > > Braap. Bad Architecture Alert. The whole reason we provide abstractions > like consolidations and components is precisely so that we can provide > "higher than Volatile" expectations for things that theselves may exhibit > "less than Volatile" stability. > > There is no reason this couldn't be made a part of the KDE consolidation, > and maintained by them as Committed interfaces for use by any KDE > consumers > who need it. Volatile means "can change", not "will change", and both > the > Apache C++ Lib and the KDE projects certainly seem to meet the basic ARC > expectations of managing the compatible evolution of their component. > > If the C++ basis that KDE builds upon were to change incompatibly, I'd > expect KDE to react by producing a major release - again, just like the > ARC would expect. > > Nothing here requires KDE to be Volatile. We're not talking about something that is delivered with Consolidation Private binding... we're talking about (assuming Volatile binding) something that could change underneath KDE. Such a change would be devastating to binary compatibility for applications linking against KDE C++ libraries. If KDE has a way to shield applications underneath from such a binary breakage, then its a different story altogether. However, my understanding is that in this case (unlike more simple cases involving only C), there isn't a way for KDE to do that. I.e. with C++ code, if application #include's a KDE header, which itself #include's a libstdc++ header, the binary bits of the application *very* likely contain details of the underlying libstdc++ implementation encoded in them. C++ is reasonably good at providing good programmatic boundaries between interface and implementation at the *source* code level. However, it falls down completely at the *binary* level. (Which isn't to say that libraries simply *can't* prevent this sort of problem -- merely that the expectation should *not* be that they do, because it will probably require some rather grotesque contortions on the part of the library to do so.) Now, if the library (KDE) never #include's "standard" C++ headers (provided by this library) in its own headers (that it exports to applications), but only uses them in .cxx (or .cpp or .C or whatever) implementation files, then I agree that there is no problem. (Although the consuming application may itself still wind up needing to have its own dependency upon the libstdc++, but that issue is largely orthogonal as far as something like KDE is concerned.) To put this in comparison, imagine if almost all of the standard C functions were simply *macros* rather than functions, and the macros made references to volatile innards of the C library. While the *API* might be "clean" and safe, the *ABI* would most certainly not be. This is the situation that we're in with C++, I think. -- Garrett From John.Plocher@sun.com Fri Sep 5 14:25:32 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85LPWR5027174 for ; Fri, 5 Sep 2008 14:25:32 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m85LPU2p063839 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 15:25:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q0080JRII4100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 14:25:30 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q000SNRIHAS50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 14:25:29 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m85LPTjV016886 for ; Fri, 05 Sep 2008 14:25:29 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q00101REAH900@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 14:25:29 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q00A5IRI7A250@fe-sfbay-09.sun.com>; Fri, 05 Sep 2008 14:25:19 -0700 (PDT) Date: Fri, 05 Sep 2008 14:25:18 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C18114.9020604@sun.com> Sender: John.Plocher@sun.com To: "Garrett D'Amore" Cc: John.Fischer@sun.com, Stefan Teleman , Joep.Vesseur@sun.com, Steve Clamage , PSARC-ext@sun.com Message-id: <48C1A3BE.6070503@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 1454 Garrett D'Amore wrote: > If KDE has a way to shield applications underneath from such a binary > breakage, then its a different story altogether. It easily can do that. The key is to realize that "binary compatibility" is not a forever thing, or a global thing, but lasts only until a Major release of a consolidation is released as part of a larger product. If KDE were to make this C++ library a standard part of its consolidation, then KDE could promise to never change it incompatibly unless KDE itself were to produce a Major release of KDE. In the same way as we would not expect or require absolute binary compatibility between KDE.old clients and KDE.major.new servers, we would not require absolute binary compatibility from its C++ library. > To put this in comparison, imagine if almost all of the standard C > functions were simply *macros* rather than functions, and the macros > made references to volatile innards of the C library. If we did this, our promise would have to be "binary compatibility guarenteed only until we changed things incompatibly", at which point we would have to up the major version number of ON (and thus SunOS and Solaris because of the transitive law of maximal inconvenience...) For stuff like libc and core ON, absolute compatibility over eons is a no brainer; elsewhere it may easily have less (or even no) value. All this proves is that binary compatibility isn't a global constant. -John From gdamore@sun.com Fri Sep 5 14:47:11 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85LlA1i027647 for ; Fri, 5 Sep 2008 14:47:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m85Ll1R0004146 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 22:47:09 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q00A01SIJIE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 14:47:07 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q000FYSIJAS70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 14:47:07 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m85Ll7fU004217 for ; Fri, 05 Sep 2008 14:47:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q00101S6CH100@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 14:47:07 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q003XCSIDYUE0@fe-sfbay-10.sun.com>; Fri, 05 Sep 2008 14:47:02 -0700 (PDT) Date: Fri, 05 Sep 2008 14:46:13 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1A3BE.6070503@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: John.Fischer@sun.com, Stefan Teleman , Joep.Vesseur@sun.com, Steve Clamage , PSARC-ext@sun.com Message-id: <48C1A8A5.3020505@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1A3BE.6070503@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3306 John Plocher wrote: > Garrett D'Amore wrote: >> If KDE has a way to shield applications underneath from such a binary >> breakage, then its a different story altogether. > > It easily can do that. The key is to realize that "binary compatibility" > is not a forever thing, or a global thing, but lasts only until a Major > release of a consolidation is released as part of a larger product. > > If KDE were to make this C++ library a standard part of its > consolidation, > then KDE could promise to never change it incompatibly unless KDE itself > were to produce a Major release of KDE. > > In the same way as we would not expect or require absolute binary > compatibility between KDE.old clients and KDE.major.new servers, > we would not require absolute binary compatibility from its C++ > library. True. But this would mean integrating the C++ library as a project private module, right (and so KDE would not directly be exporting any of this library's interfaces)? The project team has rejected that proposal. > >> To put this in comparison, imagine if almost all of the standard C >> functions were simply *macros* rather than functions, and the macros >> made references to volatile innards of the C library. > > If we did this, our promise would have to be "binary compatibility > guarenteed only until we changed things incompatibly", at which point > we would have to up the major version number of ON (and thus SunOS > and Solaris because of the transitive law of maximal inconvenience...) Right. The point is, the project as proposed creates just such a mess. > > For stuff like libc and core ON, absolute compatibility over eons is > a no brainer; elsewhere it may easily have less (or even no) value. I'd argue that a C++ base ABI is almost as critical for C++ as libc is for C. Certainly if we're going to bless it with some kind of "Standard" or "Committed" binding (as the case has requested) then compatibility should have some meaningful value. > > All this proves is that binary compatibility isn't a global constant. This is one of the cases where binary compatibility is *really* important, though. I don't really care if Gnome breaks compatibility (though hopefully other people do!) for middleware, but this bit of piece is potentially a foundation for *all* C++ code. Its just about as critical for C++ code as libc is for C code. (Yes, you can write libraries that don't link against the Standard C++ library, and you can also make C libraries that don't rely on libc. However, the *norm* is that these baselines are *safe* for building new software upon, and most libraries can be expected to use them.) For the record, I've not said that we can't allow for change, or even incompatible change here. All I've said is that this has to be properly thought out (with the ramifications for other bits that build upon this well considered), rather than shoved through while declaring that compatibility is irrelevant. IMO, such a position would be highly irresponsible. We wouldn't just swap out the Solaris kernel and replace it with a Linux kernel (even as an "option") without careful consideration. Yet, in many ways, the ramifications of this change are as sweeping for C++ development as a new kernel would be. -- Garrett From Stefan.Teleman@sun.com Fri Sep 5 15:36:21 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85MaK2W029125 for ; Fri, 5 Sep 2008 15:36:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m85MaAag020515; Fri, 5 Sep 2008 23:36:16 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q00G01USEOB00@brm-avmta-1.central.sun.com>; Fri, 05 Sep 2008 16:36:14 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q000MCUSDLT90@brm-avmta-1.central.sun.com>; Fri, 05 Sep 2008 16:36:14 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m85MaB20005907; Fri, 05 Sep 2008 15:36:12 -0700 (PDT) Date: Fri, 05 Sep 2008 18:36:08 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C18114.9020604@sun.com> To: "Garrett D'Amore" Cc: John Plocher , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@sun.com, Bart.Smaalders@sun.com Reply-to: Stefan Teleman Message-id: <48C1B458.2020301@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 8842 Garrett D'Amore wrote: > John Plocher wrote: >> Garrett D'Amore wrote: >>> One of the implications of such a binding (Volatile), is that >>> projects which build other C++ shared libraries upon this one cannot >>> have a commitment level higher than Volatile either. >> >> Braap. Bad Architecture Alert. The whole reason we provide abstractions >> like consolidations and components is precisely so that we can provide >> "higher than Volatile" expectations for things that theselves may exhibit >> "less than Volatile" stability. >> >> There is no reason this couldn't be made a part of the KDE consolidation, >> and maintained by them as Committed interfaces for use by any KDE >> consumers >> who need it. Volatile means "can change", not "will change", and both >> the >> Apache C++ Lib and the KDE projects certainly seem to meet the basic ARC >> expectations of managing the compatible evolution of their component. >> >> If the C++ basis that KDE builds upon were to change incompatibly, I'd >> expect KDE to react by producing a major release - again, just like the >> ARC would expect. >> >> Nothing here requires KDE to be Volatile. > > We're not talking about something that is delivered with Consolidation > Private binding... we're talking about (assuming Volatile binding) > something that could change underneath KDE. Such a change would be > devastating to binary compatibility for applications linking against KDE > C++ libraries. > > If KDE has a way to shield applications underneath from such a binary > breakage, then its a different story altogether. However, my > understanding is that in this case (unlike more simple cases involving > only C), there isn't a way for KDE to do that. This ARC Case is not about KDE, but about the Standard C++ Library. What KDE may or may not expose in its header files, and how it handles implementation delegation design patterns is for a different ARC Case. > I.e. with C++ code, if application #include's a KDE header, which itself > #include's a libstdc++ header, the binary bits of the application > *very* likely contain details of the underlying libstdc++ implementation > encoded in them. It is the responsibility of the implementation to shield any private and potentially incompatible implementation details from the publicly exported interfaces. For the purposes of this statement, "interfaces" refers to both source and binary. The principle of separating interface from implementation is one of the Design Principles of the C++ Programming Language, and has been a C++ software design principle ever since the creation of the Language. It has been widely discussed and documented in relevant literature, and it has also been put in practice by many C++ software systems, including, but not limited to, the Apache Standard C++ Library, and/or the existing libCstd.so.1. > C++ is reasonably good at providing good programmatic boundaries between > interface and implementation at the *source* code level. However, it > falls down completely at the *binary* level. (Which isn't to say that > libraries simply *can't* prevent this sort of problem -- merely that the > expectation should *not* be that they do, because it will probably > require some rather grotesque contortions on the part of the library to > do so.) The private implementation details of any particular C++ software system are just that: private. The blanket statement that C++ falls down completely at the binary compatibility level is false, and it is invalidated by existing software practice. It is indeed possible to maintain binary compatibility for a C++ software system, and no grotesque contortions are required to achieve this goal. > Now, if the library (KDE) never #include's "standard" C++ headers > (provided by this library) in its own headers (that it exports to > applications), but only uses them in .cxx (or .cpp or .C or whatever) > implementation files, then I agree that there is no problem. (Although > the consuming application may itself still wind up needing to have its > own dependency upon the libstdc++, but that issue is largely orthogonal > as far as something like KDE is concerned.) The dependency constraint has already been clearly stated in the ARC Case. Although it is generally considered a poor software implementation choice to #include Standard C++ Library header files in application header files exporting public interfaces, the implementation of the Apache Standard C++ Library allows for this inclusion, without breaking ABI [ pursuant to the compatibility constraints described in the ARC Case Materials ]. However, the Language allows for the implicit inclusion of interfaces from the Standard C++ Library [ or for that matter, any other library ], in header files, without the need for explicit #include directives. The Library incompatibility constraint is still in effect: the Apache Standard C++ Library is not compatible with: - any implementation of the Apache Standard C++ Library, which is not at Major Release 4 level - any _other_ implementation of the Standard C++ Library, including, but not limited to: libCstd.so, the GNU Standard C++ Library, STLport, etc. > To put this in comparison, imagine if almost all of the standard C > functions were simply *macros* rather than functions, and the macros > made references to volatile innards of the C library. While the *API* > might be "clean" and safe, the *ABI* would most certainly not be. This > is the situation that we're in with C++, I think. Intentionally, and by Language Design, C++ inline functions, or templates (which is what you are referring to) are *NOT* C macros. C++ inline functions are functions. C++ templates are templates. Their symbols are mangled, they obey all the language overloading rules, they are assigned the implicit "this" pointer by the compiler (if they are class members), and they behave exactly in the same way as any other C++ function. They [ classes ] also implement a distinct type. The complexity of the implementation of C++ functions increases in the case where the class, or function in question, is a template (which is the case with the majority of the classes in the Standard C++ Library). If the class is a template, the compiler instantiates a distinct type, based on the type defined by the class template itself, and on the underlying type upon which the template class is instantiated. This instantiation mechanism alone is fundamentally different than that of C macros. The type instantiation mechanism applies to non-template functions and classes as well. The compiler may or may not decide to eliminate the function call altogether, by inlining in the resulting object file, and this is a private decision of the compiler. The compiler may or may not decide to eliminate the instantiation of the template [ class or function ] altogether, based on internal compiler heuristic rules, and/or based on whether or not the actual template function or template class is actually referenced in the translation unit [ the default compiler decision can be overridden with specific compiler flags, but that facility is besides the point for this discussion ]. This decision, again, is a private decision of the compiler. At this point, your comparison with C macros has fundamentally broken down: there is no guarantee whatsoever that any of the template classes or functions, whose interfaces have been imported by the translation unit via header files, would have actually created the required type and its corresponding instance, and/or that the compiler has, in fact, generated the corresponding symbol(s) in the binary object. The means by which the implementation achieves the asserted ABI compatibility goal is private to the implementation itself. In this particular case, under discussion, this compatibility is enforced by function calls to private, internal implementations of the facilities required by the Language Standard (hence the presence of the shared library object). Attempting to invalidate the ABI compatibility assertion of the implementation by drawing comparisons with C Language macros, or with the C Programming Language in general, is based on incorrect assumptions about the C++ Programming Language, and is bound to fail scrutiny. I am hereby requesting that the PSARC member who has derailed this case provides concrete proof of ABI breakage in the Apache Standard C++ Library, to the PSARC Committee, for review. Concrete proof means: source code, accompanied by an explanation of the breakage. For The Record: KDE has no intention whatsoever to modify the Standard C++ Library in an incompatible way. Thank you. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gdamore@sun.com Fri Sep 5 16:47:47 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m85Nlk2C001509 for ; Fri, 5 Sep 2008 16:47:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m85Nlgvk014456 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 00:47:45 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q00B0BY3J4G00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 16:47:43 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q00A2WY3JEL10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 16:47:43 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m85Nlh0E002394 for ; Fri, 05 Sep 2008 16:47:43 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q00601XZX7J00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 16:47:43 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q00ISGY34DQA0@fe-sfbay-10.sun.com>; Fri, 05 Sep 2008 16:47:29 -0700 (PDT) Date: Fri, 05 Sep 2008 16:46:40 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1B458.2020301@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John Plocher , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, Steve Clamage , PSARC-ext@sun.com, Bart.Smaalders@sun.com Message-id: <48C1C4E0.7090300@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 14595 Thank you for your instructional description of the C++ language with respect to templates. There are a few significant points, that I think you keep missing, or are glossing over: When I said C++ doesn't separate *binary* interface from implementation, I was *not* talking about the nice separation done for the benefit of the programmer. I was talking about separation done across the boundary created by the linker ... AFAIK, C++ does not recognize that there is such an interface boundary. In C++, if an inline function is expanded by the compiler, but makes use of *private* members of the class, then the *binary implementation* of the resulting code is *tied* to the implementation, and if the implementation changes (e.g. by changing the dynamically linked library) then there can be unfortunate consequences. I'm not a template expert, so I'll demonstrate with a simple inline function using C++ circa 1990. class box { int width; int height; /* put more private details here... */ public: void draw(); // private implementation elsewhere public inline int getwidth() { return width; } }; If this is in header, then the implementation parts (the width, the height and their offsets within the class) wind up getting encoded into the binary that includes this header. If the width or the height ever move (e..g by moving another member in front of them in the class), then the binary is busted. Likewise, if the private members change type (e.g. from a uint16_t to a uint32_t), breakage ensues. It is possible to have implementations that don't suffer from this problem, but it requires that the implementation refrain from inline functions, and take care that the headers *only* expose portions of the classes that will never ever change (or change in a way that breaks the binary implementation of the class.) I won't endeavor to describe how this problem may or may not affect templates, as such is out of my area of expertise. I've not kept up with the C++ standards admittedly, but I believe that this aspect of binary compatibility is not one that has been addressed in the standards, and likely not in the specification of the libraries. It is possible that the Apache product has taken great care to avoid this kind of potential breakage, but my first reaction is doubt. Now, that's only *one* aspect of the "compatibility problem." There is a grave and other serious problem, which relates to the fact that this proposal effectively creates a new baseline (i.e. a new ABI) for C++ programs, where programs linked (directly or indirectly) against this library are incompatible with our one and only bless (at this time) ABI, based on the libC that ships with Solaris today. And, the project recognizes that future breakage is not just possible, but *likely*, when either the compiler team ships another project, or when the library needs an update due to changes in the standard. Imagine the plight of the poor user who downloads a program (WhizzyDownloadTracker) which uses two different class libraries. On the one hand, it uses the NiftyNetworking library for networking functionality, and it uses the KDE libraries for user interface work. Well, good thing, the IPS repo contains both NiftyNetworking and KDE. Download both, install, and then download, compile (via ./configure) and install the WhizzyDownloadTracker. All's good, right? Well, a few hours later, when the compile for WhizzyDownloadTracker finally completes, we find out life isn't so good. Because you see, the NiftyNetworking set was not built with the Apache libstdc++, but instead with the "default" libraries that we have been recommending people use for years. The user tries to run the program, and if he's lucky, gets a meaningful link error message. In reality, the error message, if any, that results is probably completely cryptic to the end user, who was just trying to install software. In a worse scenario, the program just dumps core mysteriously. The worst part of the above scenario, apart from the confusion that the poor non-C++-developing victim gets to experience, is that he's downloaded the foundation libraries from a single source (Sun's IPS repo), so they *should* work together, shouldn't they?!? Too bad. So now the user complains to the FOSS authors for WhizzyDownloadTracker, who are unfamiliar with Solaris (they did their development on Linux, see?), and don't know that Solaris has multiple incompatible C++ ABIs, nor how to tell which components were built against which ABI. So, the FOSS author probably gives up, and tells the poor user that he needs to recompile the base libraries (either KDE or NiftyNetworking), so that they are built with compatible libraries. At this point, the FOSS author is laughing at Sun and Solaris, and probably also cheerfully writes a blog somewhere admonishing folks against running Solaris. And, the original user? He's probably given up. Most likely he either he chooses not to use WhizzyDownloadTracker, or winds up giving up on Solaris and switches back to Linux or Windows. Either way he's probably pretty ticked that "Sun" is delivering crapware that just doesn't work together. I don't know if the above illustration clearly enough paints the picture of my features, but I think it certainly demonstrates that we cannot just blithely ignore the issue and pretend it won't affect anyone. -- Garrett Stefan Teleman wrote: > > > Garrett D'Amore wrote: >> John Plocher wrote: >>> Garrett D'Amore wrote: >>>> One of the implications of such a binding (Volatile), is that >>>> projects which build other C++ shared libraries upon this one >>>> cannot have a commitment level higher than Volatile either. >>> >>> Braap. Bad Architecture Alert. The whole reason we provide >>> abstractions >>> like consolidations and components is precisely so that we can provide >>> "higher than Volatile" expectations for things that theselves may >>> exhibit >>> "less than Volatile" stability. >>> >>> There is no reason this couldn't be made a part of the KDE >>> consolidation, >>> and maintained by them as Committed interfaces for use by any KDE >>> consumers >>> who need it. Volatile means "can change", not "will change", and >>> both the >>> Apache C++ Lib and the KDE projects certainly seem to meet the basic >>> ARC >>> expectations of managing the compatible evolution of their component. >>> >>> If the C++ basis that KDE builds upon were to change incompatibly, I'd >>> expect KDE to react by producing a major release - again, just like the >>> ARC would expect. >>> >>> Nothing here requires KDE to be Volatile. >> >> We're not talking about something that is delivered with >> Consolidation Private binding... we're talking about (assuming >> Volatile binding) something that could change underneath KDE. Such a >> change would be devastating to binary compatibility for applications >> linking against KDE C++ libraries. >> >> If KDE has a way to shield applications underneath from such a binary >> breakage, then its a different story altogether. However, my >> understanding is that in this case (unlike more simple cases >> involving only C), there isn't a way for KDE to do that. > > This ARC Case is not about KDE, but about the Standard C++ Library. > What KDE may or may not expose in its header files, and how it handles > implementation delegation design patterns is for a different ARC Case. > >> I.e. with C++ code, if application #include's a KDE header, which >> itself #include's a libstdc++ header, the binary bits of the >> application *very* likely contain details of the underlying libstdc++ >> implementation encoded in them. > > It is the responsibility of the implementation to shield any private > and potentially incompatible implementation details from the publicly > exported interfaces. For the purposes of this statement, "interfaces" > refers to both source and binary. > > The principle of separating interface from implementation is one of > the Design Principles of the C++ Programming Language, and has been a > C++ software design principle ever since the creation of the Language. > It has been widely discussed and documented in relevant literature, > and it has also been put in practice by many C++ software systems, > including, but not limited to, the Apache Standard C++ Library, and/or > the existing libCstd.so.1. > >> C++ is reasonably good at providing good programmatic boundaries >> between interface and implementation at the *source* code level. >> However, it falls down completely at the *binary* level. (Which >> isn't to say that libraries simply *can't* prevent this sort of >> problem -- merely that the expectation should *not* be that they do, >> because it will probably require some rather grotesque contortions on >> the part of the library to do so.) > > The private implementation details of any particular C++ software > system are just that: private. The blanket statement that C++ falls > down completely at the binary compatibility level is false, and it is > invalidated by existing software practice. It is indeed possible to > maintain binary compatibility for a C++ software system, and no > grotesque contortions are required to achieve this goal. > >> Now, if the library (KDE) never #include's "standard" C++ headers >> (provided by this library) in its own headers (that it exports to >> applications), but only uses them in .cxx (or .cpp or .C or whatever) >> implementation files, then I agree that there is no problem. >> (Although the consuming application may itself still wind up needing >> to have its own dependency upon the libstdc++, but that issue is >> largely orthogonal as far as something like KDE is concerned.) > > The dependency constraint has already been clearly stated in the ARC > Case. > > Although it is generally considered a poor software implementation > choice to #include Standard C++ Library header files in application > header files exporting public interfaces, the implementation of the > Apache Standard C++ Library allows for this inclusion, without > breaking ABI [ pursuant to the compatibility constraints described in > the ARC Case Materials ]. However, the Language allows for the > implicit inclusion of interfaces from the Standard C++ Library [ or > for that matter, any other library ], in header files, without the > need for explicit #include directives. > > The Library incompatibility constraint is still in effect: the Apache > Standard C++ Library is not compatible with: > > - any implementation of the Apache Standard C++ Library, which is not > at Major Release 4 level > - any _other_ implementation of the Standard C++ Library, including, > but not limited to: libCstd.so, the GNU Standard C++ Library, STLport, > etc. > >> To put this in comparison, imagine if almost all of the standard C >> functions were simply *macros* rather than functions, and the macros >> made references to volatile innards of the C library. While the >> *API* might be "clean" and safe, the *ABI* would most certainly not >> be. This is the situation that we're in with C++, I think. > > Intentionally, and by Language Design, C++ inline functions, or > templates (which is what you are referring to) are *NOT* C macros. C++ > inline functions are functions. C++ templates are templates. Their > symbols are mangled, they obey all the language overloading rules, > they are assigned the implicit "this" pointer by the compiler (if they > are class members), and they behave exactly in the same way as any > other C++ function. They [ classes ] also implement a distinct type. > > The complexity of the implementation of C++ functions increases in the > case where the class, or function in question, is a template (which is > the case with the majority of the classes in the Standard C++ > Library). If the class is a template, the compiler instantiates a > distinct type, based on the type defined by the class template itself, > and on the underlying type upon which the template class is > instantiated. This instantiation mechanism alone is fundamentally > different than that of C macros. > > The type instantiation mechanism applies to non-template functions and > classes as well. > > The compiler may or may not decide to eliminate the function call > altogether, by inlining in the resulting object file, and this is a > private decision of the compiler. The compiler may or may not decide > to eliminate the instantiation of the template [ class or function ] > altogether, based on internal compiler heuristic rules, and/or based > on whether or not the actual template function or template class is > actually referenced in the translation unit [ the default compiler > decision can be overridden with specific compiler flags, but that > facility is besides the point for this discussion ]. This decision, > again, is a private decision of the compiler. > > At this point, your comparison with C macros has fundamentally broken > down: there is no guarantee whatsoever that any of the template > classes or functions, whose interfaces have been imported by the > translation unit via header files, would have actually created the > required type and its corresponding instance, and/or that the compiler > has, in fact, generated the corresponding symbol(s) in the binary object. > > The means by which the implementation achieves the asserted ABI > compatibility goal is private to the implementation itself. In this > particular case, under discussion, this compatibility is enforced by > function calls to private, internal implementations of the facilities > required by the Language Standard (hence the presence of the shared > library object). > > Attempting to invalidate the ABI compatibility assertion of the > implementation by drawing comparisons with C Language macros, or with > the C Programming Language in general, is based on incorrect > assumptions about the C++ Programming Language, and is bound to fail > scrutiny. > > I am hereby requesting that the PSARC member who has derailed this > case provides concrete proof of ABI breakage in the Apache Standard > C++ Library, to the PSARC Committee, for review. Concrete proof means: > source code, accompanied by an explanation of the breakage. > > For The Record: KDE has no intention whatsoever to modify the Standard > C++ Library in an incompatible way. > > Thank you. > > --Stefan > From John.Plocher@Sun.COM Fri Sep 5 17:09:16 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8609GJk002716 for ; Fri, 5 Sep 2008 17:09:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8609FDi009445 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 17:09:16 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6Q00BF7Z3FYB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 17:09:15 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Q00AZBZ2CEO20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 17:08:36 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8608aoQ004100 for ; Fri, 05 Sep 2008 17:08:36 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Q00901YX9S600@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 17:08:36 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Q007NBZ2BY410@fe-sfbay-09.sun.com>; Fri, 05 Sep 2008 17:08:35 -0700 (PDT) Date: Fri, 05 Sep 2008 17:08:34 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1C4E0.7090300@sun.com> Sender: John.Plocher@Sun.COM To: "Garrett D'Amore" Cc: Stefan Teleman , John.Fischer@Sun.COM, Joep.Vesseur@Sun.COM, Gary Winiger , gww@eng.sun.com, PSARC-ext@Sun.COM, Bart.Smaalders@Sun.COM, Steve Clamage Message-id: <48C1CA02.8060104@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 527 Garrett D'Amore wrote (slightly more verbosely and parenthetically): > C++ programs linked against this library are incompatible > with libC that ships with Solaris today. Where does this claim come from? Are you confusing libstdcxx with libC? The proposal only says: The Apache/RogueWave Standard C++ Library is not binary compatible with the Sun Standard C++ Library [ libCstd.so.1 ], or with the STLport Standard C++ Library. Nowhere does it mention the C++ Runtime support library, libC. -John From Stefan.Teleman@sun.com Fri Sep 5 17:36:12 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m860aBsx003241 for ; Fri, 5 Sep 2008 17:36:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m860a1us003502; Sat, 6 Sep 2008 08:36:04 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6R002090C3HH00@brm-avmta-1.central.sun.com>; Fri, 05 Sep 2008 18:36:03 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6R000NU0C2LNE0@brm-avmta-1.central.sun.com>; Fri, 05 Sep 2008 18:36:03 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m860a1lG026754; Fri, 05 Sep 2008 17:36:01 -0700 (PDT) Date: Fri, 05 Sep 2008 20:36:00 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1C4E0.7090300@sun.com> To: "Garrett D'Amore" Cc: John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, John Plocher , psarc-ext@sun.com, Bart.Smaalders@sun.com, Steve Clamage Reply-to: Stefan Teleman Message-id: <48C1D070.7090609@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2207 Garrett D'Amore wrote: > Thank you for your instructional description of the C++ language with > respect to templates. > > There are a few significant points, that I think you keep missing, or > are glossing over: > > When I said C++ doesn't separate *binary* interface from implementation, > I was *not* talking about the nice separation done for the benefit of > the programmer. I was talking about separation done across the boundary > created by the linker ... AFAIK, C++ does not recognize that there is > such an interface boundary. > > In C++, if an inline function is expanded by the compiler, but makes use > of *private* members of the class, then the *binary implementation* of > the resulting code is *tied* to the implementation, and if the > implementation changes (e.g. by changing the dynamically linked library) > then there can be unfortunate consequences. > > I'm not a template expert, so I'll demonstrate with a simple inline > function using C++ circa 1990. > > class box { > int width; > int height; > /* put more private details here... */ > > public: > void draw(); // private implementation elsewhere > > public inline int getwidth() { return width; } > }; This is a hypothetical example of a very poorly designed C++ class. I would expect to see this type of design from a High School Student, and not from a professional. Certainly not from an industry leader. The quality of this implementation aside, this code excerpt is not from the Apache Standard C++ Library. Could you kindly provide an example of ABI breakage -- any kind of breakage -- from the source code of the Apache Standard C++ Library, currently under discussion ? Incidentally, the problem you are illustrating in your example has been solved about 14 years ago (if not earlier): http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=sr_1_1?ie=UTF8&s=books&qid=1220661045&sr=1-1 Published November 10, 1994. As to which of the Design Patterns addresses this very exact problem is left as an exercise for the reader. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gdamore@sun.com Fri Sep 5 20:36:11 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m863aA04006343 for ; Fri, 5 Sep 2008 20:36:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m863a8a4020801 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 11:36:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6R004038O74W00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 20:36:07 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6R00NKD8O74G70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 20:36:07 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m863a7OY024120 for ; Fri, 05 Sep 2008 20:36:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6R00A018N9IN00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 20:36:07 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6R0007B8O6ZU50@fe-sfbay-10.sun.com>; Fri, 05 Sep 2008 20:36:06 -0700 (PDT) Date: Fri, 05 Sep 2008 20:35:16 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1CA02.8060104@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Stefan Teleman , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, PSARC-ext@sun.com, Bart.Smaalders@sun.com, Steve Clamage Message-id: <48C1FA74.3050705@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1CA02.8060104@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 793 John Plocher wrote: > Garrett D'Amore wrote (slightly more verbosely and parenthetically): >> C++ programs linked against this library are incompatible >> with libC that ships with Solaris today. > > Where does this claim come from? Are you confusing libstdcxx > with libC? > > The proposal only says: > > The Apache/RogueWave Standard C++ Library is not binary compatible > with the Sun Standard C++ Library [ libCstd.so.1 ], or with the > STLport Standard C++ Library. > > Nowhere does it mention the C++ Runtime support library, libC. Hmm... I guess I was confusing libC with libCstd. That does beg two new questions though, which is whether we have any stability guarantees for either STLport or libCstd, and whether libstdc++ is compatible with libC. -- Garrett From gdamore@sun.com Fri Sep 5 20:44:21 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m863iK16006403 for ; Fri, 5 Sep 2008 20:44:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m863iEsG023238 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 6 Sep 2008 11:44:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6R00M0391UMR00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 05 Sep 2008 20:44:18 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6R00M0U91TLL00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 05 Sep 2008 20:44:17 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m863iH4h013509 for ; Fri, 05 Sep 2008 20:44:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6R00M0190YL000@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 05 Sep 2008 20:44:17 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6R0050Q91SE6A0@fe-sfbay-09.sun.com>; Fri, 05 Sep 2008 20:44:17 -0700 (PDT) Date: Fri, 05 Sep 2008 20:43:26 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1D070.7090609@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, John Plocher , PSARC-ext@sun.com, Bart.Smaalders@sun.com, Steve Clamage Message-id: <48C1FC5E.5050205@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3794 Stefan Teleman wrote: > > > Garrett D'Amore wrote: >> Thank you for your instructional description of the C++ language with >> respect to templates. >> >> There are a few significant points, that I think you keep missing, or >> are glossing over: >> >> When I said C++ doesn't separate *binary* interface from >> implementation, I was *not* talking about the nice separation done >> for the benefit of the programmer. I was talking about separation >> done across the boundary created by the linker ... AFAIK, C++ does >> not recognize that there is such an interface boundary. >> >> In C++, if an inline function is expanded by the compiler, but makes >> use of *private* members of the class, then the *binary >> implementation* of the resulting code is *tied* to the >> implementation, and if the implementation changes (e.g. by changing >> the dynamically linked library) then there can be unfortunate >> consequences. >> >> I'm not a template expert, so I'll demonstrate with a simple inline >> function using C++ circa 1990. >> >> class box { >> int width; >> int height; >> /* put more private details here... */ >> >> public: >> void draw(); // private implementation elsewhere >> >> public inline int getwidth() { return width; } >> }; > > This is a hypothetical example of a very poorly designed C++ class. I > would expect to see this type of design from a High School Student, > and not from a professional. Certainly not from an industry leader. > > The quality of this implementation aside, this code excerpt is not > from the Apache Standard C++ Library. > > Could you kindly provide an example of ABI breakage -- any kind of > breakage -- from the source code of the Apache Standard C++ Library, > currently under discussion ? > > Incidentally, the problem you are illustrating in your example has > been solved about 14 years ago (if not earlier): > > http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=sr_1_1?ie=UTF8&s=books&qid=1220661045&sr=1-1 > > > Published November 10, 1994. > > As to which of the Design Patterns addresses this very exact problem > is left as an exercise for the reader. Okay, I'm not interested in debating this further ... or even researching it. I frankly don't have the energy to read the source code for a significant library written in a language I don't work in on a day to day basis. However, if you will assert that there are no binary compatibility problems of this nature (nor any others of a similar nature arising from templates) -- i.e. that the header files do not create a problem, then I don't have a problem. The litmus test for this problem would be to take an application compiled against one version the library, and replace the library underneath it with a different implementation. If the applications still work, then I'm satisfied. If the applications do not work, then we have to make some kind of continuity statements or guarantees about how we manage fixes and upgrades to the library. If Apache's implementation guarantees that this breakage doesn't occur on minor or patch upgrades, then that might be acceptable, although we have to figure out continuity to ensure that the library (or a drop in compatible replacement) will remain available for quite some time. (Standard commitment effectively means ~forever, btw.) That still doesn't address the other major set of concerns I had, about mixing and matching different implementations of the standard libraries. I think I'm unhappy with anything above Volatile commitment without a game plan that ultimately addresses the problem and gets us to a single "recommended" base library implementation. -- Garrett > > --Stefan > From gdamore@sun.com Fri Sep 5 21:07:01 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m86471sD007196 for ; Fri, 5 Sep 2008 21:07:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m86471Um020872 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Sep 2008 21:07:01 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6R00001A3PRB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 21:07:01 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6R00MUHA3OLL10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 21:07:00 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m86470mB017319 for ; Fri, 05 Sep 2008 21:07:00 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6R00501A22FS00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 21:07:00 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6R002BWA3NPW20@fe-sfbay-10.sun.com>; Fri, 05 Sep 2008 21:07:00 -0700 (PDT) Date: Fri, 05 Sep 2008 21:06:09 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1FC5E.5050205@sun.com> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, John Plocher , PSARC-ext@sun.com, Bart.Smaalders@sun.com, Steve Clamage Message-id: <48C201B1.4060803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 5665 Reading the Apache C++ sources (which I didn't want to do, but here you go), I ran into the following example snippet in the include directory (the include file is ): template inline typename basic_streambuf<_CharT, _Traits>::int_type basic_streambuf<_CharT, _Traits>:: sputbackc (char_type __c) { _RWSTD_ASSERT (_C_is_valid ()); if (_C_putback_avail () && traits_type::eq (*(gptr () - 1), __c)) return traits_type::to_int_type (*--_C_gptr); return pbackfail (traits_type::to_int_type (__c)); } In the above example, the inline function has in it bits which appear to me to be implementation details (_C_putback_avail() is protected for example -- I'm not sure whether the *standard* specifies that it exist or not. _C_gptr is certainly a private member of the class, and I "presume" that the standard doesn't specify it, though I've not checked the standard since I don't have a copy of it handy.) The concern here is what happens if those portions of the implementation need to change? (What happens if _C_gptr moves in the class, or the implementation needs to change in a way that _C_gptr doesn't exist at all, or changes type? Bad things, I suspect.) Will the implementation take care to preserve the *existing* functions so that the above inline (which will now have been compiled into various applications) will continue to function, regardless of what other changes may be necessary for the class? I apologize for my apparently childish C++ example earlier -- as I said, I don't work in the language very often. But I *think* I've found a real example from Apache C++ that suffers the same problem. Do you disagree? -- Garrett Garrett D'Amore wrote: > Stefan Teleman wrote: >> >> >> Garrett D'Amore wrote: >>> Thank you for your instructional description of the C++ language >>> with respect to templates. >>> >>> There are a few significant points, that I think you keep missing, >>> or are glossing over: >>> >>> When I said C++ doesn't separate *binary* interface from >>> implementation, I was *not* talking about the nice separation done >>> for the benefit of the programmer. I was talking about separation >>> done across the boundary created by the linker ... AFAIK, C++ does >>> not recognize that there is such an interface boundary. >>> >>> In C++, if an inline function is expanded by the compiler, but makes >>> use of *private* members of the class, then the *binary >>> implementation* of the resulting code is *tied* to the >>> implementation, and if the implementation changes (e.g. by changing >>> the dynamically linked library) then there can be unfortunate >>> consequences. >>> >>> I'm not a template expert, so I'll demonstrate with a simple inline >>> function using C++ circa 1990. >>> >>> class box { >>> int width; >>> int height; >>> /* put more private details here... */ >>> >>> public: >>> void draw(); // private implementation elsewhere >>> >>> public inline int getwidth() { return width; } >>> }; >> >> This is a hypothetical example of a very poorly designed C++ class. I >> would expect to see this type of design from a High School Student, >> and not from a professional. Certainly not from an industry leader. >> >> The quality of this implementation aside, this code excerpt is not >> from the Apache Standard C++ Library. >> >> Could you kindly provide an example of ABI breakage -- any kind of >> breakage -- from the source code of the Apache Standard C++ Library, >> currently under discussion ? >> >> Incidentally, the problem you are illustrating in your example has >> been solved about 14 years ago (if not earlier): >> >> http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=sr_1_1?ie=UTF8&s=books&qid=1220661045&sr=1-1 >> >> >> Published November 10, 1994. >> >> As to which of the Design Patterns addresses this very exact problem >> is left as an exercise for the reader. > > Okay, I'm not interested in debating this further ... or even > researching it. I frankly don't have the energy to read the source > code for a significant library written in a language I don't work in > on a day to day basis. > > However, if you will assert that there are no binary compatibility > problems of this nature (nor any others of a similar nature arising > from templates) -- i.e. that the header files do not create a problem, > then I don't have a problem. > > The litmus test for this problem would be to take an application > compiled against one version the library, and replace the library > underneath it with a different implementation. If the applications > still work, then I'm satisfied. If the applications do not work, then > we have to make some kind of continuity statements or guarantees about > how we manage fixes and upgrades to the library. If Apache's > implementation guarantees that this breakage doesn't occur on minor or > patch upgrades, then that might be acceptable, although we have to > figure out continuity to ensure that the library (or a drop in > compatible replacement) will remain available for quite some time. > (Standard commitment effectively means ~forever, btw.) > > That still doesn't address the other major set of concerns I had, > about mixing and matching different implementations of the standard > libraries. I think I'm unhappy with anything above Volatile > commitment without a game plan that ultimately addresses the problem > and gets us to a single "recommended" base library implementation. > > -- Garrett >> >> --Stefan >> > From Stephen.Clamage@sun.com Fri Sep 5 21:52:05 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m864q40J008733 for ; Fri, 5 Sep 2008 21:52:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m864q1mb011841 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 12:52:03 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6R00203C6PWP00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 21:52:01 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6R00MWUC6PLN30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 21:52:01 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m864q1N4001070 for ; Fri, 05 Sep 2008 21:52:01 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6R00401C61XV00@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 21:52:01 -0700 (PDT) Received: from [10.0.0.5] ([68.126.179.11]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6R008JIC6O2FB0@fe-sfbay-09.sun.com>; Fri, 05 Sep 2008 21:52:00 -0700 (PDT) Date: Fri, 05 Sep 2008 21:51:59 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1C4E0.7090300@sun.com> Sender: Stephen.Clamage@sun.com To: "Garrett D'Amore" Cc: Stefan Teleman , John Plocher , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, PSARC-ext@sun.com, Bart.Smaalders@sun.com Message-id: <48C20C6F.4080908@sun.com> Organization: Sun Microsystems, Inc MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 6457 Garrett is exactly right in his explanation and examples. I covered most of these points in my paper that I mentioned earlier. http://developers.sun.com/solaris/articles/CC_abi/CC_abi_content.html Let me add two comments about inlining. 1. The C++ standard library API includes many tiny functions that are expected to be inlined in order to get acceptable performance. Except possibly when compiling in debug mode, every compiler does in fact inline many functions. 2. At high optimization levels, the Sun compiler optimizer phase might choose to inline any function, even ones not declared inline, unless you explicitly ask it not to. --- Steve Clamage, stephen.clamage@sun.com On 9/5/2008 4:46 PM, Garrett D'Amore wrote: > Thank you for your instructional description of the C++ language with > respect to templates. > > There are a few significant points, that I think you keep missing, or > are glossing over: > > When I said C++ doesn't separate *binary* interface from implementation, > I was *not* talking about the nice separation done for the benefit of > the programmer. I was talking about separation done across the boundary > created by the linker ... AFAIK, C++ does not recognize that there is > such an interface boundary. > > In C++, if an inline function is expanded by the compiler, but makes use > of *private* members of the class, then the *binary implementation* of > the resulting code is *tied* to the implementation, and if the > implementation changes (e.g. by changing the dynamically linked library) > then there can be unfortunate consequences. > > I'm not a template expert, so I'll demonstrate with a simple inline > function using C++ circa 1990. > > class box { > int width; > int height; > /* put more private details here... */ > > public: > void draw(); // private implementation elsewhere > > public inline int getwidth() { return width; } > }; > > If this is in header, then the implementation parts (the width, the > height and their offsets within the class) wind up getting encoded into > the binary that includes this header. If the width or the height ever > move (e..g by moving another member in front of them in the class), then > the binary is busted. Likewise, if the private members change type > (e.g. from a uint16_t to a uint32_t), breakage ensues. > > It is possible to have implementations that don't suffer from this > problem, but it requires that the implementation refrain from inline > functions, and take care that the headers *only* expose portions of the > classes that will never ever change (or change in a way that breaks the > binary implementation of the class.) I won't endeavor to describe how > this problem may or may not affect templates, as such is out of my area > of expertise. > > I've not kept up with the C++ standards admittedly, but I believe that > this aspect of binary compatibility is not one that has been addressed > in the standards, and likely not in the specification of the libraries. > It is possible that the Apache product has taken great care to avoid > this kind of potential breakage, but my first reaction is doubt. > > Now, that's only *one* aspect of the "compatibility problem." > > There is a grave and other serious problem, which relates to the fact > that this proposal effectively creates a new baseline (i.e. a new ABI) > for C++ programs, where programs linked (directly or indirectly) against > this library are incompatible with our one and only bless (at this time) > ABI, based on the libC that ships with Solaris today. > > And, the project recognizes that future breakage is not just possible, > but *likely*, when either the compiler team ships another project, or > when the library needs an update due to changes in the standard. > > Imagine the plight of the poor user who downloads a program > (WhizzyDownloadTracker) which uses two different class libraries. On > the one hand, it uses the NiftyNetworking library for networking > functionality, and it uses the KDE libraries for user interface work. > Well, good thing, the IPS repo contains both NiftyNetworking and KDE. > Download both, install, and then download, compile (via ./configure) and > install the WhizzyDownloadTracker. All's good, right? > > Well, a few hours later, when the compile for WhizzyDownloadTracker > finally completes, we find out life isn't so good. > > Because you see, the NiftyNetworking set was not built with the Apache > libstdc++, but instead with the "default" libraries that we have been > recommending people use for years. The user tries to run the program, > and if he's lucky, gets a meaningful link error message. In reality, > the error message, if any, that results is probably completely cryptic > to the end user, who was just trying to install software. In a worse > scenario, the program just dumps core mysteriously. > > The worst part of the above scenario, apart from the confusion that the > poor non-C++-developing victim gets to experience, is that he's > downloaded the foundation libraries from a single source (Sun's IPS > repo), so they *should* work together, shouldn't they?!? > > Too bad. > > So now the user complains to the FOSS authors for WhizzyDownloadTracker, > who are unfamiliar with Solaris (they did their development on Linux, > see?), and don't know that Solaris has multiple incompatible C++ ABIs, > nor how to tell which components were built against which ABI. > > So, the FOSS author probably gives up, and tells the poor user that he > needs to recompile the base libraries (either KDE or NiftyNetworking), > so that they are built with compatible libraries. > > At this point, the FOSS author is laughing at Sun and Solaris, and > probably also cheerfully writes a blog somewhere admonishing folks > against running Solaris. > > And, the original user? He's probably given up. Most likely he either > he chooses not to use WhizzyDownloadTracker, or winds up giving up on > Solaris and switches back to Linux or Windows. Either way he's probably > pretty ticked that "Sun" is delivering crapware that just doesn't work > together. > > I don't know if the above illustration clearly enough paints the picture > of my features, but I think it certainly demonstrates that we cannot > just blithely ignore the issue and pretend it won't affect anyone. > > -- Garrett From Stephen.Clamage@sun.com Fri Sep 5 22:28:47 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m865Sk5t009178 for ; Fri, 5 Sep 2008 22:28:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m865SfZm011032 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 06:28:45 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6R00109DVSXA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 23:28:40 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6R009QNDVS8KC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 23:28:40 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m865SeLD020622 for ; Fri, 05 Sep 2008 22:28:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6R00I01DO8HI00@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Sep 2008 22:28:39 -0700 (PDT) Received: from [10.0.0.5] ([68.126.179.11]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6R00IF3DVRT700@fe-sfbay-09.sun.com>; Fri, 05 Sep 2008 22:28:39 -0700 (PDT) Date: Fri, 05 Sep 2008 22:28:38 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1FA74.3050705@sun.com> Sender: Stephen.Clamage@sun.com To: "Garrett D'Amore" Cc: John Plocher , Stefan Teleman , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, PSARC-ext@sun.com, Bart.Smaalders@sun.com Message-id: <48C21506.1050806@sun.com> Organization: Sun Microsystems, Inc MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1CA02.8060104@Sun.Com> <48C1FA74.3050705@sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 2764 These are some of the libraries that DevPro delivers into Solaris in package SUNWlibC. libC.so.5: Runtime support for C++ 4.x (1993-1997). Incompatible with any program that uses the C++ standard library. libCrun.so.1: Runtime support for basic language features in C++ 5.x. (new, delete, run-time type identification, exception handling, compiler "helper" routines.) libCstd.so.1: Runtime support for the remainder of the C++ standard library in C++ 5.x. Independent of libstdcxx, we will continue to ship all the above libraries for many years to come. C++ 5.x compilers generate two ABIs: 1. -compat=4 mode for compatibility with C++ 4.x, using libC.so.5. 2. Default standard mode (-compat=5), using some version of the C++ Standard library: libCstd, libstlport, or some other library acquired by a customer. I am using "ABI" here in the sense of how the compiler generates object code for source code constructs. Technically, the standard library is part of the ABI, but it is sometimes useful to separate the specific library from the compiler behavior that does not vary. Even though we will add another ABI to support the 2010 C++ standard, we will continue to support the -compat=5 ABI for many years to come. I expect -compat=5 mode to be the default in that new compiler, to minimize code breakage. Old code can't depend on C++ 2010. New code can use new compiler options. If we ship the Apache libstdcxx with Studio 12 and with the next release ("Ceres"), it will use the -compat=5 ABI. The next compiler, for C++ 2010, will continue to support this same version of libstdcxx in -compat=5 mode, for many years to come. libstlport is not shipped with Solaris, and does not have a stability guarantee. If we ship libstdcxx with Ceres, we will drop libstlport in the following release. --- Steve Clamage, stephen.clamage@sun.com On 9/5/2008 8:35 PM, Garrett D'Amore wrote: > John Plocher wrote: >> Garrett D'Amore wrote (slightly more verbosely and parenthetically): >>> C++ programs linked against this library are incompatible >>> with libC that ships with Solaris today. >> >> Where does this claim come from? Are you confusing libstdcxx >> with libC? >> >> The proposal only says: >> >> The Apache/RogueWave Standard C++ Library is not binary compatible >> with the Sun Standard C++ Library [ libCstd.so.1 ], or with the >> STLport Standard C++ Library. >> >> Nowhere does it mention the C++ Runtime support library, libC. > > Hmm... I guess I was confusing libC with libCstd. > > That does beg two new questions though, which is whether we have any > stability guarantees for either STLport or libCstd, and whether > libstdc++ is compatible with libC. > > -- Garrett > From Stefan.Teleman@sun.com Fri Sep 5 23:57:54 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m866vr33010277 for ; Fri, 5 Sep 2008 23:57:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m866vlu6010915; Sat, 6 Sep 2008 14:57:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6R00403I0BDN00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Sep 2008 23:57:47 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6R00N2ZI0A4KC0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Sep 2008 23:57:46 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m866uug7010922; Fri, 05 Sep 2008 23:57:03 -0700 (PDT) Date: Sat, 06 Sep 2008 02:56:50 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C201B1.4060803@sun.com> To: "Garrett D'Amore" Cc: John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, John Plocher , PSARC-ext@sun.com, Bart.Smaalders@sun.com, Steve Clamage Reply-to: Stefan Teleman Message-id: <48C229B2.7080002@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 5504 Garrett D'Amore wrote: > Reading the Apache C++ sources (which I didn't want to do, but here you > go), I ran into the following example snippet in the include directory > (the include file is ): > > template > inline typename basic_streambuf<_CharT, _Traits>::int_type > basic_streambuf<_CharT, _Traits>:: > sputbackc (char_type __c) > { > _RWSTD_ASSERT (_C_is_valid ()); > > if (_C_putback_avail () && traits_type::eq (*(gptr () - 1), __c)) > return traits_type::to_int_type (*--_C_gptr); > > return pbackfail (traits_type::to_int_type (__c)); > } > > > In the above example, the inline function has in it bits which appear to > me to be implementation details (_C_putback_avail() is protected for > example -- I'm not sure whether the *standard* specifies that it exist > or not. _C_gptr is certainly a private member of the class, and I > "presume" that the standard doesn't specify it, though I've not checked > the standard since I don't have a copy of it handy.) > > The concern here is what happens if those portions of the implementation > need to change? (What happens if _C_gptr moves in the class, or the > implementation needs to change in a way that _C_gptr doesn't exist at > all, or changes type? Bad things, I suspect.) These changes cannot be made. Not for the duration of Major Release 4. This is what the Standard says about this particular member function: 27.5.2.2.4 Putback int_type sputbackc(char_type c); 1 Returns: If the input sequence putback position is not available, or if traits::eq(c, gptr()[-1]) is false, returns pbackfail(traits::to_int_type(c)). Otherwise, decrements the next pointer for the input sequence and returns traits::to_int_type (*gptr()). The function _C_putback_avail() is private to this implementation of the Library (in the Apache Library's case all functions, or data members whose names begin with "_C" are private to the implementation). The pointer _C_gptr (or a functional equivalent thereof) is mandated by the Standard. This naming convention is a warning to the developer of the application consuming the interfaces exposed by : Do Not Use These Functions Directly Under Any Circumstances Whatsoever. Also, the fact that is is protected imposes restrictions on access. The important aspect is that the gptr() (which Apache calls _C_gptr) is explicitly mentioned in the Standard. If you compare version 4.2.1 of this Standard header file with the same header file from versions 4.2.0, or 4.1.3, you will see that the changes made to this header file do not break binary compatibility. > Will the implementation take care to preserve the *existing* functions > so that the above inline (which will now have been compiled into various > applications) will continue to function, regardless of what other > changes may be necessary for the class? The implementation *must* preserve those functions and data members (or functional equivalents thereof) which are mandated by the Standard. These cannot be changed in any way -- they are immutable. New, non-virtual member functions could be added to this class (non-virtual functions do not affect the size or the layout of the object, or of the __vtbl), provided that their names begins with "_C", and are therefore labeled as private to the implementation. Static member functions could be safely added (they don't even have an implicit "this" pointer at all, and they do not affect the size or the layout of the object), subject to the same naming convention constraints. New virtual member functions, and/or new data members cannot be added, under any circumstances whatsoever. But such additions should not be even considered in the first place -- this version of the Standard is frozen. Adding a virtual function to this class will first and foremost violate the interfaces mandated by the Standard. What could change, with less restrictions, are the private implementation details which can be found in the $(top_srcdir)/src directory, and whose names begin with "__rw". > I apologize for my apparently childish C++ example earlier -- as I said, > I don't work in the language very often. But I *think* I've found a > real example from Apache C++ that suffers the same problem. Do you > disagree? I do not see this example as a reason for binary compatibility breakage concern, provided that the rules for preserving binary compatibility are observed (which I have no reason to believe that they will not be). Everything i've said here i can guarantee that is is also very well known by the Apache/RogueWave developers as well -- most likely much more. No apologies necessary. There are design circumstances in which the developer of the library interface simply knows that the class layout cannot change, ever. For those circumstances, freezing the object layout is appropriate. KDE, and QT, intentionally do not use this approach. For all the library classes which expose public interfaces available to external consumers, the private implementation details are hidden by means of the Bridge or Facade Design Patterns (pImpl pattern). The actual implementation of the header file only exposes member functions, and the only data member is an opaque pointer to the private implementation. The actual private implementation is done in the *.cpp translation unit. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From johnsonnenschein@gmail.com Sat Sep 6 01:25:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m868PNlr012559 for ; Sat, 6 Sep 2008 01:25:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m868PIlj020470 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 09:25:22 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6R00E01M28LE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 01:25:20 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6R00NA8M284JD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 01:25:20 -0700 (PDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m868NMVe027586 for ; Sat, 06 Sep 2008 08:25:19 +0000 (GMT) Received: from mms24es.mms.us.syntegra.com ([150.143.232.70] [150.143.232.70]) by relay23i.sun.com with ESMTP id BT-MMP-3089837 for PSARC-ext@sun.com; Sat, 06 Sep 2008 08:25:19 +0000 (Z) Received: from relay24.sun.com (relay24.sun.com [192.12.251.74]) by mms24es.mms.us.syntegra.com with ESMTP id BT-MMP-100808230 for PSARC-ext@sun.com; Sat, 06 Sep 2008 08:25:19 +0000 (Z) Received: from wa-out-1112.google.com ([209.85.146.182] [209.85.146.182]) by relay24i.sun.com with ESMTP id BT-MMP-25910251 for PSARC-ext@sun.com; Sat, 06 Sep 2008 08:25:18 +0000 (Z) Received: by wa-out-1112.google.com with SMTP id j37so561610waf.22 for ; Sat, 06 Sep 2008 01:25:13 -0700 (PDT) Received: by 10.115.58.18 with SMTP id l18mr10811160wak.177.1220689513341; Sat, 06 Sep 2008 01:25:13 -0700 (PDT) Received: from ?192.168.1.104? ( [76.10.188.43]) by mx.google.com with ESMTPS id m26sm2263406pof.1.2008.09.06.01.25.10 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Sep 2008 01:25:11 -0700 (PDT) Date: Sat, 06 Sep 2008 01:25:08 -0700 From: John Sonnenschein Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C1C4E0.7090300@sun.com> To: "Garrett D'Amore" Cc: Stefan Teleman , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, John Plocher , PSARC-ext@sun.com, Bart.Smaalders@sun.com, Steve Clamage Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=9muvqv5OROh9jyGmk/ANc+DRyjqN8wnXgJK8F99MA6g=; b=FztARZ0oQAgMWHT9WYaKm1TGQwY9fE+1RXsjem737C6VriJxtKkFKf+vFh2+6Sd+DY /KfSAi8lj/x6VO1DPBrZDXowsaJ52IcrONFgtc22m7F5xU7TpQ/Qs7FGTyfWB8PIxQNa uMHTGB66OHOe+x+CAf037m9u9BdEluvsA3hXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=g6nFYDba78r+umIvqAwrK4tWegQpnqLG/NHW6d4m1JH+7ebJe1W3OUWQykt12MK8fQ OxZC9JdDCUo1J5c5mVKVYLH8Do/wcgw27xNoG4Susw0Y7Oims/Aer1lbvBWLcLmbvMNx UwkbPDUBZ3aBeCuVHqacXbURmAz4StuZg4hvs= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.285sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> Status: RO Content-Length: 15751 I may regret throwing my hat in to this ring in the future, but with respect to the example about user downloading $APP and having it not work because it uses $FOO ( linked to libCstd ) and $BAR ( linked to stdcxx ), that would mean that the developer of $APP explicitly linked to both, which is just silly, that $FOO or $BAR changed under it's feet, which would be a different ARC case altogether, or that $FOO/ $BAR had the STL ripped out from under /it's/ feet, and removal of old libraries would be yet another ARC case altogether. Take care -John On 5-Sep-08, at 4:46 PM, Garrett D'Amore wrote: > Thank you for your instructional description of the C++ language with > respect to templates. > > There are a few significant points, that I think you keep missing, or > are glossing over: > > When I said C++ doesn't separate *binary* interface from > implementation, > I was *not* talking about the nice separation done for the benefit of > the programmer. I was talking about separation done across the > boundary > created by the linker ... AFAIK, C++ does not recognize that there is > such an interface boundary. > > In C++, if an inline function is expanded by the compiler, but makes > use > of *private* members of the class, then the *binary implementation* of > the resulting code is *tied* to the implementation, and if the > implementation changes (e.g. by changing the dynamically linked > library) > then there can be unfortunate consequences. > > I'm not a template expert, so I'll demonstrate with a simple inline > function using C++ circa 1990. > > class box { > int width; > int height; > /* put more private details here... */ > > public: > void draw(); // private implementation elsewhere > > public inline int getwidth() { return width; } > }; > > If this is in header, then the implementation parts (the width, the > height and their offsets within the class) wind up getting encoded > into > the binary that includes this header. If the width or the height ever > move (e..g by moving another member in front of them in the class), > then > the binary is busted. Likewise, if the private members change type > (e.g. from a uint16_t to a uint32_t), breakage ensues. > > It is possible to have implementations that don't suffer from this > problem, but it requires that the implementation refrain from inline > functions, and take care that the headers *only* expose portions of > the > classes that will never ever change (or change in a way that breaks > the > binary implementation of the class.) I won't endeavor to describe how > this problem may or may not affect templates, as such is out of my > area > of expertise. > > I've not kept up with the C++ standards admittedly, but I believe that > this aspect of binary compatibility is not one that has been addressed > in the standards, and likely not in the specification of the > libraries. > It is possible that the Apache product has taken great care to avoid > this kind of potential breakage, but my first reaction is doubt. > > Now, that's only *one* aspect of the "compatibility problem." > > There is a grave and other serious problem, which relates to the fact > that this proposal effectively creates a new baseline (i.e. a new ABI) > for C++ programs, where programs linked (directly or indirectly) > against > this library are incompatible with our one and only bless (at this > time) > ABI, based on the libC that ships with Solaris today. > > And, the project recognizes that future breakage is not just possible, > but *likely*, when either the compiler team ships another project, or > when the library needs an update due to changes in the standard. > > Imagine the plight of the poor user who downloads a program > (WhizzyDownloadTracker) which uses two different class libraries. On > the one hand, it uses the NiftyNetworking library for networking > functionality, and it uses the KDE libraries for user interface work. > Well, good thing, the IPS repo contains both NiftyNetworking and KDE. > Download both, install, and then download, compile (via ./configure) > and > install the WhizzyDownloadTracker. All's good, right? > > Well, a few hours later, when the compile for WhizzyDownloadTracker > finally completes, we find out life isn't so good. > > Because you see, the NiftyNetworking set was not built with the Apache > libstdc++, but instead with the "default" libraries that we have been > recommending people use for years. The user tries to run the program, > and if he's lucky, gets a meaningful link error message. In reality, > the error message, if any, that results is probably completely cryptic > to the end user, who was just trying to install software. In a worse > scenario, the program just dumps core mysteriously. > > The worst part of the above scenario, apart from the confusion that > the > poor non-C++-developing victim gets to experience, is that he's > downloaded the foundation libraries from a single source (Sun's IPS > repo), so they *should* work together, shouldn't they?!? > > Too bad. > > So now the user complains to the FOSS authors for > WhizzyDownloadTracker, > who are unfamiliar with Solaris (they did their development on Linux, > see?), and don't know that Solaris has multiple incompatible C++ ABIs, > nor how to tell which components were built against which ABI. > > So, the FOSS author probably gives up, and tells the poor user that he > needs to recompile the base libraries (either KDE or NiftyNetworking), > so that they are built with compatible libraries. > > At this point, the FOSS author is laughing at Sun and Solaris, and > probably also cheerfully writes a blog somewhere admonishing folks > against running Solaris. > > And, the original user? He's probably given up. Most likely he > either > he chooses not to use WhizzyDownloadTracker, or winds up giving up on > Solaris and switches back to Linux or Windows. Either way he's > probably > pretty ticked that "Sun" is delivering crapware that just doesn't work > together. > > I don't know if the above illustration clearly enough paints the > picture > of my features, but I think it certainly demonstrates that we cannot > just blithely ignore the issue and pretend it won't affect anyone. > > -- Garrett > > Stefan Teleman wrote: >> >> >> Garrett D'Amore wrote: >>> John Plocher wrote: >>>> Garrett D'Amore wrote: >>>>> One of the implications of such a binding (Volatile), is that >>>>> projects which build other C++ shared libraries upon this one >>>>> cannot have a commitment level higher than Volatile either. >>>> >>>> Braap. Bad Architecture Alert. The whole reason we provide >>>> abstractions >>>> like consolidations and components is precisely so that we can >>>> provide >>>> "higher than Volatile" expectations for things that theselves may >>>> exhibit >>>> "less than Volatile" stability. >>>> >>>> There is no reason this couldn't be made a part of the KDE >>>> consolidation, >>>> and maintained by them as Committed interfaces for use by any KDE >>>> consumers >>>> who need it. Volatile means "can change", not "will change", and >>>> both the >>>> Apache C++ Lib and the KDE projects certainly seem to meet the >>>> basic >>>> ARC >>>> expectations of managing the compatible evolution of their >>>> component. >>>> >>>> If the C++ basis that KDE builds upon were to change >>>> incompatibly, I'd >>>> expect KDE to react by producing a major release - again, just >>>> like the >>>> ARC would expect. >>>> >>>> Nothing here requires KDE to be Volatile. >>> >>> We're not talking about something that is delivered with >>> Consolidation Private binding... we're talking about (assuming >>> Volatile binding) something that could change underneath KDE. >>> Such a >>> change would be devastating to binary compatibility for applications >>> linking against KDE C++ libraries. >>> >>> If KDE has a way to shield applications underneath from such a >>> binary >>> breakage, then its a different story altogether. However, my >>> understanding is that in this case (unlike more simple cases >>> involving only C), there isn't a way for KDE to do that. >> >> This ARC Case is not about KDE, but about the Standard C++ Library. >> What KDE may or may not expose in its header files, and how it >> handles >> implementation delegation design patterns is for a different ARC >> Case. >> >>> I.e. with C++ code, if application #include's a KDE header, which >>> itself #include's a libstdc++ header, the binary bits of the >>> application *very* likely contain details of the underlying libstdc >>> ++ >>> implementation encoded in them. >> >> It is the responsibility of the implementation to shield any private >> and potentially incompatible implementation details from the publicly >> exported interfaces. For the purposes of this statement, "interfaces" >> refers to both source and binary. >> >> The principle of separating interface from implementation is one of >> the Design Principles of the C++ Programming Language, and has been a >> C++ software design principle ever since the creation of the >> Language. >> It has been widely discussed and documented in relevant literature, >> and it has also been put in practice by many C++ software systems, >> including, but not limited to, the Apache Standard C++ Library, and/ >> or >> the existing libCstd.so.1. >> >>> C++ is reasonably good at providing good programmatic boundaries >>> between interface and implementation at the *source* code level. >>> However, it falls down completely at the *binary* level. (Which >>> isn't to say that libraries simply *can't* prevent this sort of >>> problem -- merely that the expectation should *not* be that they do, >>> because it will probably require some rather grotesque contortions >>> on >>> the part of the library to do so.) >> >> The private implementation details of any particular C++ software >> system are just that: private. The blanket statement that C++ falls >> down completely at the binary compatibility level is false, and it is >> invalidated by existing software practice. It is indeed possible to >> maintain binary compatibility for a C++ software system, and no >> grotesque contortions are required to achieve this goal. >> >>> Now, if the library (KDE) never #include's "standard" C++ headers >>> (provided by this library) in its own headers (that it exports to >>> applications), but only uses them in .cxx (or .cpp or .C or >>> whatever) >>> implementation files, then I agree that there is no problem. >>> (Although the consuming application may itself still wind up needing >>> to have its own dependency upon the libstdc++, but that issue is >>> largely orthogonal as far as something like KDE is concerned.) >> >> The dependency constraint has already been clearly stated in the ARC >> Case. >> >> Although it is generally considered a poor software implementation >> choice to #include Standard C++ Library header files in application >> header files exporting public interfaces, the implementation of the >> Apache Standard C++ Library allows for this inclusion, without >> breaking ABI [ pursuant to the compatibility constraints described in >> the ARC Case Materials ]. However, the Language allows for the >> implicit inclusion of interfaces from the Standard C++ Library [ or >> for that matter, any other library ], in header files, without the >> need for explicit #include directives. >> >> The Library incompatibility constraint is still in effect: the Apache >> Standard C++ Library is not compatible with: >> >> - any implementation of the Apache Standard C++ Library, which is not >> at Major Release 4 level >> - any _other_ implementation of the Standard C++ Library, including, >> but not limited to: libCstd.so, the GNU Standard C++ Library, >> STLport, >> etc. >> >>> To put this in comparison, imagine if almost all of the standard C >>> functions were simply *macros* rather than functions, and the macros >>> made references to volatile innards of the C library. While the >>> *API* might be "clean" and safe, the *ABI* would most certainly not >>> be. This is the situation that we're in with C++, I think. >> >> Intentionally, and by Language Design, C++ inline functions, or >> templates (which is what you are referring to) are *NOT* C macros. C >> ++ >> inline functions are functions. C++ templates are templates. Their >> symbols are mangled, they obey all the language overloading rules, >> they are assigned the implicit "this" pointer by the compiler (if >> they >> are class members), and they behave exactly in the same way as any >> other C++ function. They [ classes ] also implement a distinct type. >> >> The complexity of the implementation of C++ functions increases in >> the >> case where the class, or function in question, is a template (which >> is >> the case with the majority of the classes in the Standard C++ >> Library). If the class is a template, the compiler instantiates a >> distinct type, based on the type defined by the class template >> itself, >> and on the underlying type upon which the template class is >> instantiated. This instantiation mechanism alone is fundamentally >> different than that of C macros. >> >> The type instantiation mechanism applies to non-template functions >> and >> classes as well. >> >> The compiler may or may not decide to eliminate the function call >> altogether, by inlining in the resulting object file, and this is a >> private decision of the compiler. The compiler may or may not decide >> to eliminate the instantiation of the template [ class or function ] >> altogether, based on internal compiler heuristic rules, and/or based >> on whether or not the actual template function or template class is >> actually referenced in the translation unit [ the default compiler >> decision can be overridden with specific compiler flags, but that >> facility is besides the point for this discussion ]. This decision, >> again, is a private decision of the compiler. >> >> At this point, your comparison with C macros has fundamentally broken >> down: there is no guarantee whatsoever that any of the template >> classes or functions, whose interfaces have been imported by the >> translation unit via header files, would have actually created the >> required type and its corresponding instance, and/or that the >> compiler >> has, in fact, generated the corresponding symbol(s) in the binary >> object. >> >> The means by which the implementation achieves the asserted ABI >> compatibility goal is private to the implementation itself. In this >> particular case, under discussion, this compatibility is enforced by >> function calls to private, internal implementations of the facilities >> required by the Language Standard (hence the presence of the shared >> library object). >> >> Attempting to invalidate the ABI compatibility assertion of the >> implementation by drawing comparisons with C Language macros, or with >> the C Programming Language in general, is based on incorrect >> assumptions about the C++ Programming Language, and is bound to fail >> scrutiny. >> >> I am hereby requesting that the PSARC member who has derailed this >> case provides concrete proof of ABI breakage in the Apache Standard >> C++ Library, to the PSARC Committee, for review. Concrete proof >> means: >> source code, accompanied by an explanation of the breakage. >> >> For The Record: KDE has no intention whatsoever to modify the >> Standard >> C++ Library in an incompatible way. >> >> Thank you. >> >> --Stefan >> > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From marc.rocas@gmail.com Sat Sep 6 05:26:14 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m86CQDsv016516 for ; Sat, 6 Sep 2008 05:26:13 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m86CQCZu030370 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 06:26:12 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6R00J03X7OGT00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 05:26:12 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6R00BUIX7OHR10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 05:26:12 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m86CQBbc024516 for ; Sat, 06 Sep 2008 12:26:11 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay14i.sun.com with ESMTP id BT-MMP-767997 for PSARC-ext@sun.com; Sat, 06 Sep 2008 12:26:11 +0000 (Z) Received: from relay18i.sun.com (relay18i.sun.com [129.179.4.128]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-253887 for PSARC-ext@sun.com; Sat, 06 Sep 2008 12:26:09 +0000 (Z) Received: from an-out-0708.google.com ([209.85.132.241] [209.85.132.241]) by relay1i.sun.com with ESMTP id BT-MMP-8247366 for PSARC-ext@sun.com; Sat, 06 Sep 2008 12:26:09 +0000 (Z) Received: by an-out-0708.google.com with SMTP id d31so138759and.92 for ; Sat, 06 Sep 2008 05:26:01 -0700 (PDT) Received: by 10.100.4.1 with SMTP id 1mr13650320and.149.1220703960891; Sat, 06 Sep 2008 05:26:00 -0700 (PDT) Received: by 10.100.92.3 with HTTP; Sat, 06 Sep 2008 05:26:00 -0700 (PDT) Date: Sat, 06 Sep 2008 08:26:00 -0400 From: Marc Rocas Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: To: John Sonnenschein Cc: "Garrett D'Amore" , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, John Plocher , Stefan Teleman , PSARC-ext@sun.com, Bart.Smaalders@sun.com, Steve Clamage , marc.rocas@gmail.com Message-id: <86229f400809060526y60040c1cn6b975e0d04b167ff@mail.gmail.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_WKDLSg/lgPzhjN99UdzQMA)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=yQp3OtgyhcQuqJHdShpAaTv5R1MYzS250ywQy4UCk+g=; b=mP8TAfcLWdDGrAXgm610MV0c1pa40I8JioU9Sizh4JMx5LBlRcY+zQN5x+ioI4P18U p/3rWOdZA6ZI5nioP6dtiWCZ9NtQiWu7Ahf5KVDqvG82SS7NtscAJM5iWZXy4yMQrVA8 gLaZTxtOWhclaXsDmRs3GHclEwO2TwZfz8EUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=ro0Y2JdqE760HeoJB0qAgQ1NcerOrXSDmNzc0hqtjWv0OaF9CRmI45n9YDebqCcNIA gunWgtmxyVX4/RF+5kLpdJjz9TwHnSUg/Sjv+d0Xn9j0QwdPP3w8m/P62IgyAb21SxWZ 0lIsYaWZirXWeIFydVSkQYqOBSDtJwgE1tO4M= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.485sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> Status: RO Content-Length: 39802 --Boundary_(ID_WKDLSg/lgPzhjN99UdzQMA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline You're correct if you assume that a developer is doing so explictly. However, it can easily happen implicitly if an application links in shared objects that in turn depend on a mixture of libraries that should not be combined. Unless a developer audits all shared objects its code links against for their respective dependencies, this issue can happen. At least for SunStudio, the outcome is application crashes that appear to be random and inexplicable unless the developer is already aware of the issue that libC and stlport4 libraries should not be combined. If you work in a large organization and happen to integrate 3rd party code as well for your products, the current state of affairs for Sun Studio requires that such binary audits and other processes be put in place to guard against accidentally combining incompatible C++ libraries. I'm in favor of any new implementations of the standard C++ library being delivered by the compiler engineering group so that I can continue to read the specific caveats for whatever set of libraries from a single piece of documentation (i.e., SunStudio's C++ User Guide). The more places (and options) that a developer has to check for this type of information increases the chances of getting into trouble. --Marc On Sat, Sep 6, 2008 at 4:25 AM, John Sonnenschein < johnsonnenschein@gmail.com> wrote: > I may regret throwing my hat in to this ring in the future, but with > respect to the example about user downloading $APP and having it not > work because it uses $FOO ( linked to libCstd ) and $BAR ( linked to > stdcxx ), that would mean that the developer of $APP explicitly linked > to both, which is just silly, that $FOO or $BAR changed under it's > feet, which would be a different ARC case altogether, or that $FOO/ > $BAR had the STL ripped out from under /it's/ feet, and removal of old > libraries would be yet another ARC case altogether. > > Take care > -John > > On 5-Sep-08, at 4:46 PM, Garrett D'Amore wrote: > > > Thank you for your instructional description of the C++ language with > > respect to templates. > > > > There are a few significant points, that I think you keep missing, or > > are glossing over: > > > > When I said C++ doesn't separate *binary* interface from > > implementation, > > I was *not* talking about the nice separation done for the benefit of > > the programmer. I was talking about separation done across the > > boundary > > created by the linker ... AFAIK, C++ does not recognize that there is > > such an interface boundary. > > > > In C++, if an inline function is expanded by the compiler, but makes > > use > > of *private* members of the class, then the *binary implementation* of > > the resulting code is *tied* to the implementation, and if the > > implementation changes (e.g. by changing the dynamically linked > > library) > > then there can be unfortunate consequences. > > > > I'm not a template expert, so I'll demonstrate with a simple inline > > function using C++ circa 1990. > > > > class box { > > int width; > > int height; > > /* put more private details here... */ > > > > public: > > void draw(); // private implementation elsewhere > > > > public inline int getwidth() { return width; } > > }; > > > > If this is in header, then the implementation parts (the width, the > > height and their offsets within the class) wind up getting encoded > > into > > the binary that includes this header. If the width or the height ever > > move (e..g by moving another member in front of them in the class), > > then > > the binary is busted. Likewise, if the private members change type > > (e.g. from a uint16_t to a uint32_t), breakage ensues. > > > > It is possible to have implementations that don't suffer from this > > problem, but it requires that the implementation refrain from inline > > functions, and take care that the headers *only* expose portions of > > the > > classes that will never ever change (or change in a way that breaks > > the > > binary implementation of the class.) I won't endeavor to describe how > > this problem may or may not affect templates, as such is out of my > > area > > of expertise. > > > > I've not kept up with the C++ standards admittedly, but I believe that > > this aspect of binary compatibility is not one that has been addressed > > in the standards, and likely not in the specification of the > > libraries. > > It is possible that the Apache product has taken great care to avoid > > this kind of potential breakage, but my first reaction is doubt. > > > > Now, that's only *one* aspect of the "compatibility problem." > > > > There is a grave and other serious problem, which relates to the fact > > that this proposal effectively creates a new baseline (i.e. a new ABI) > > for C++ programs, where programs linked (directly or indirectly) > > against > > this library are incompatible with our one and only bless (at this > > time) > > ABI, based on the libC that ships with Solaris today. > > > > And, the project recognizes that future breakage is not just possible, > > but *likely*, when either the compiler team ships another project, or > > when the library needs an update due to changes in the standard. > > > > Imagine the plight of the poor user who downloads a program > > (WhizzyDownloadTracker) which uses two different class libraries. On > > the one hand, it uses the NiftyNetworking library for networking > > functionality, and it uses the KDE libraries for user interface work. > > Well, good thing, the IPS repo contains both NiftyNetworking and KDE. > > Download both, install, and then download, compile (via ./configure) > > and > > install the WhizzyDownloadTracker. All's good, right? > > > > Well, a few hours later, when the compile for WhizzyDownloadTracker > > finally completes, we find out life isn't so good. > > > > Because you see, the NiftyNetworking set was not built with the Apache > > libstdc++, but instead with the "default" libraries that we have been > > recommending people use for years. The user tries to run the program, > > and if he's lucky, gets a meaningful link error message. In reality, > > the error message, if any, that results is probably completely cryptic > > to the end user, who was just trying to install software. In a worse > > scenario, the program just dumps core mysteriously. > > > > The worst part of the above scenario, apart from the confusion that > > the > > poor non-C++-developing victim gets to experience, is that he's > > downloaded the foundation libraries from a single source (Sun's IPS > > repo), so they *should* work together, shouldn't they?!? > > > > Too bad. > > > > So now the user complains to the FOSS authors for > > WhizzyDownloadTracker, > > who are unfamiliar with Solaris (they did their development on Linux, > > see?), and don't know that Solaris has multiple incompatible C++ ABIs, > > nor how to tell which components were built against which ABI. > > > > So, the FOSS author probably gives up, and tells the poor user that he > > needs to recompile the base libraries (either KDE or NiftyNetworking), > > so that they are built with compatible libraries. > > > > At this point, the FOSS author is laughing at Sun and Solaris, and > > probably also cheerfully writes a blog somewhere admonishing folks > > against running Solaris. > > > > And, the original user? He's probably given up. Most likely he > > either > > he chooses not to use WhizzyDownloadTracker, or winds up giving up on > > Solaris and switches back to Linux or Windows. Either way he's > > probably > > pretty ticked that "Sun" is delivering crapware that just doesn't work > > together. > > > > I don't know if the above illustration clearly enough paints the > > picture > > of my features, but I think it certainly demonstrates that we cannot > > just blithely ignore the issue and pretend it won't affect anyone. > > > > -- Garrett > > > > Stefan Teleman wrote: > >> > >> > >> Garrett D'Amore wrote: > >>> John Plocher wrote: > >>>> Garrett D'Amore wrote: > >>>>> One of the implications of such a binding (Volatile), is that > >>>>> projects which build other C++ shared libraries upon this one > >>>>> cannot have a commitment level higher than Volatile either. > >>>> > >>>> Braap. Bad Architecture Alert. The whole reason we provide > >>>> abstractions > >>>> like consolidations and components is precisely so that we can > >>>> provide > >>>> "higher than Volatile" expectations for things that theselves may > >>>> exhibit > >>>> "less than Volatile" stability. > >>>> > >>>> There is no reason this couldn't be made a part of the KDE > >>>> consolidation, > >>>> and maintained by them as Committed interfaces for use by any KDE > >>>> consumers > >>>> who need it. Volatile means "can change", not "will change", and > >>>> both the > >>>> Apache C++ Lib and the KDE projects certainly seem to meet the > >>>> basic > >>>> ARC > >>>> expectations of managing the compatible evolution of their > >>>> component. > >>>> > >>>> If the C++ basis that KDE builds upon were to change > >>>> incompatibly, I'd > >>>> expect KDE to react by producing a major release - again, just > >>>> like the > >>>> ARC would expect. > >>>> > >>>> Nothing here requires KDE to be Volatile. > >>> > >>> We're not talking about something that is delivered with > >>> Consolidation Private binding... we're talking about (assuming > >>> Volatile binding) something that could change underneath KDE. > >>> Such a > >>> change would be devastating to binary compatibility for applications > >>> linking against KDE C++ libraries. > >>> > >>> If KDE has a way to shield applications underneath from such a > >>> binary > >>> breakage, then its a different story altogether. However, my > >>> understanding is that in this case (unlike more simple cases > >>> involving only C), there isn't a way for KDE to do that. > >> > >> This ARC Case is not about KDE, but about the Standard C++ Library. > >> What KDE may or may not expose in its header files, and how it > >> handles > >> implementation delegation design patterns is for a different ARC > >> Case. > >> > >>> I.e. with C++ code, if application #include's a KDE header, which > >>> itself #include's a libstdc++ header, the binary bits of the > >>> application *very* likely contain details of the underlying libstdc > >>> ++ > >>> implementation encoded in them. > >> > >> It is the responsibility of the implementation to shield any private > >> and potentially incompatible implementation details from the publicly > >> exported interfaces. For the purposes of this statement, "interfaces" > >> refers to both source and binary. > >> > >> The principle of separating interface from implementation is one of > >> the Design Principles of the C++ Programming Language, and has been a > >> C++ software design principle ever since the creation of the > >> Language. > >> It has been widely discussed and documented in relevant literature, > >> and it has also been put in practice by many C++ software systems, > >> including, but not limited to, the Apache Standard C++ Library, and/ > >> or > >> the existing libCstd.so.1. > >> > >>> C++ is reasonably good at providing good programmatic boundaries > >>> between interface and implementation at the *source* code level. > >>> However, it falls down completely at the *binary* level. (Which > >>> isn't to say that libraries simply *can't* prevent this sort of > >>> problem -- merely that the expectation should *not* be that they do, > >>> because it will probably require some rather grotesque contortions > >>> on > >>> the part of the library to do so.) > >> > >> The private implementation details of any particular C++ software > >> system are just that: private. The blanket statement that C++ falls > >> down completely at the binary compatibility level is false, and it is > >> invalidated by existing software practice. It is indeed possible to > >> maintain binary compatibility for a C++ software system, and no > >> grotesque contortions are required to achieve this goal. > >> > >>> Now, if the library (KDE) never #include's "standard" C++ headers > >>> (provided by this library) in its own headers (that it exports to > >>> applications), but only uses them in .cxx (or .cpp or .C or > >>> whatever) > >>> implementation files, then I agree that there is no problem. > >>> (Although the consuming application may itself still wind up needing > >>> to have its own dependency upon the libstdc++, but that issue is > >>> largely orthogonal as far as something like KDE is concerned.) > >> > >> The dependency constraint has already been clearly stated in the ARC > >> Case. > >> > >> Although it is generally considered a poor software implementation > >> choice to #include Standard C++ Library header files in application > >> header files exporting public interfaces, the implementation of the > >> Apache Standard C++ Library allows for this inclusion, without > >> breaking ABI [ pursuant to the compatibility constraints described in > >> the ARC Case Materials ]. However, the Language allows for the > >> implicit inclusion of interfaces from the Standard C++ Library [ or > >> for that matter, any other library ], in header files, without the > >> need for explicit #include directives. > >> > >> The Library incompatibility constraint is still in effect: the Apache > >> Standard C++ Library is not compatible with: > >> > >> - any implementation of the Apache Standard C++ Library, which is not > >> at Major Release 4 level > >> - any _other_ implementation of the Standard C++ Library, including, > >> but not limited to: libCstd.so, the GNU Standard C++ Library, > >> STLport, > >> etc. > >> > >>> To put this in comparison, imagine if almost all of the standard C > >>> functions were simply *macros* rather than functions, and the macros > >>> made references to volatile innards of the C library. While the > >>> *API* might be "clean" and safe, the *ABI* would most certainly not > >>> be. This is the situation that we're in with C++, I think. > >> > >> Intentionally, and by Language Design, C++ inline functions, or > >> templates (which is what you are referring to) are *NOT* C macros. C > >> ++ > >> inline functions are functions. C++ templates are templates. Their > >> symbols are mangled, they obey all the language overloading rules, > >> they are assigned the implicit "this" pointer by the compiler (if > >> they > >> are class members), and they behave exactly in the same way as any > >> other C++ function. They [ classes ] also implement a distinct type. > >> > >> The complexity of the implementation of C++ functions increases in > >> the > >> case where the class, or function in question, is a template (which > >> is > >> the case with the majority of the classes in the Standard C++ > >> Library). If the class is a template, the compiler instantiates a > >> distinct type, based on the type defined by the class template > >> itself, > >> and on the underlying type upon which the template class is > >> instantiated. This instantiation mechanism alone is fundamentally > >> different than that of C macros. > >> > >> The type instantiation mechanism applies to non-template functions > >> and > >> classes as well. > >> > >> The compiler may or may not decide to eliminate the function call > >> altogether, by inlining in the resulting object file, and this is a > >> private decision of the compiler. The compiler may or may not decide > >> to eliminate the instantiation of the template [ class or function ] > >> altogether, based on internal compiler heuristic rules, and/or based > >> on whether or not the actual template function or template class is > >> actually referenced in the translation unit [ the default compiler > >> decision can be overridden with specific compiler flags, but that > >> facility is besides the point for this discussion ]. This decision, > >> again, is a private decision of the compiler. > >> > >> At this point, your comparison with C macros has fundamentally broken > >> down: there is no guarantee whatsoever that any of the template > >> classes or functions, whose interfaces have been imported by the > >> translation unit via header files, would have actually created the > >> required type and its corresponding instance, and/or that the > >> compiler > >> has, in fact, generated the corresponding symbol(s) in the binary > >> object. > >> > >> The means by which the implementation achieves the asserted ABI > >> compatibility goal is private to the implementation itself. In this > >> particular case, under discussion, this compatibility is enforced by > >> function calls to private, internal implementations of the facilities > >> required by the Language Standard (hence the presence of the shared > >> library object). > >> > >> Attempting to invalidate the ABI compatibility assertion of the > >> implementation by drawing comparisons with C Language macros, or with > >> the C Programming Language in general, is based on incorrect > >> assumptions about the C++ Programming Language, and is bound to fail > >> scrutiny. > >> > >> I am hereby requesting that the PSARC member who has derailed this > >> case provides concrete proof of ABI breakage in the Apache Standard > >> C++ Library, to the PSARC Committee, for review. Concrete proof > >> means: > >> source code, accompanied by an explanation of the breakage. > >> > >> For The Record: KDE has no intention whatsoever to modify the > >> Standard > >> C++ Library in an incompatible way. > >> > >> Thank you. > >> > >> --Stefan > >> > > > > _______________________________________________ > > opensolaris-arc mailing list > > opensolaris-arc@opensolaris.org > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > --Boundary_(ID_WKDLSg/lgPzhjN99UdzQMA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline
You're correct if you assume that a developer is doing so explictly.  However, it can easily happen implicitly if an application links in shared objects that in turn depend on a mixture of libraries that should not be combined.  Unless a developer audits all shared objects its code links against for their respective dependencies, this issue can happen.  At least for SunStudio, the outcome is application crashes that appear to be random and inexplicable unless the developer is already aware of the issue that libC and stlport4 libraries should not be combined.

If you work in a large organization and happen to integrate 3rd party code as well for your products, the current state of affairs for Sun Studio requires that such binary audits and other processes be put in place to guard against accidentally combining incompatible C++ libraries.

I'm in favor of any new implementations of the standard C++ library being delivered by the compiler engineering group so that I can continue to read the specific caveats for whatever set of libraries from a single piece of documentation (i.e., SunStudio's C++ User Guide).  The more places (and options) that a developer has to check for this type of information increases the chances of getting into trouble.

--Marc


On Sat, Sep 6, 2008 at 4:25 AM, John Sonnenschein <johnsonnenschein@gmail.com> wrote:
I may regret throwing my hat in to this ring in the future, but with
respect to the example about user downloading $APP and having it not
work because it uses $FOO ( linked to libCstd ) and $BAR ( linked to
stdcxx ), that would mean that the developer of $APP explicitly linked
to both, which is just silly, that $FOO or $BAR changed under it's
feet, which would be a different ARC case altogether,  or that $FOO/
$BAR had the STL ripped out from under /it's/ feet, and removal of old
libraries would be yet another ARC case altogether.

Take care
-John

On 5-Sep-08, at 4:46 PM, Garrett D'Amore wrote:

> Thank you for your instructional description of the C++ language with
> respect to templates.
>
> There are a few significant points, that I think you keep missing, or
> are glossing over:
>
> When I said C++ doesn't separate *binary* interface from
> implementation,
> I was *not* talking about the nice separation done for the benefit of
> the programmer.  I was talking about separation done across the
> boundary
> created by the linker ... AFAIK, C++ does not recognize that there is
> such an interface boundary.
>
> In C++, if an inline function is expanded by the compiler, but makes
> use
> of *private* members of the class, then the *binary implementation* of
> the resulting code is *tied* to the implementation, and if the
> implementation changes (e.g. by changing the dynamically linked
> library)
> then there can be unfortunate consequences.
>
> I'm not a template expert, so I'll demonstrate with a simple inline
> function using C++ circa 1990.
>
> class box {
>    int      width;
>    int      height;
>    /* put more private details here... */
>
>   public:
>       void draw();   // private implementation elsewhere
>
>   public inline int getwidth() { return width; }
> };
>
> If this is in header, then the implementation parts (the width, the
> height and their offsets within the class) wind up getting encoded
> into
> the binary that includes this header.  If the width or the height ever
> move (e..g by moving another member in front of them in the class),
> then
> the binary is busted.  Likewise, if the private members change type
> (e.g. from a uint16_t to a uint32_t), breakage ensues.
>
> It is possible to have implementations that don't suffer from this
> problem, but it requires that the implementation refrain from inline
> functions, and take care that the headers *only* expose portions of
> the
> classes that will never ever change (or change in a way that breaks
> the
> binary implementation of the class.)  I won't endeavor to describe how
> this problem may or may not affect templates, as such is out of my
> area
> of expertise.
>
> I've not kept up with the C++ standards admittedly, but I believe that
> this aspect of binary compatibility is not one that has been addressed
> in the standards, and likely not in the specification of the
> libraries.
> It is possible that the Apache product has taken great care to avoid
> this kind of potential breakage, but my first reaction is doubt.
>
> Now, that's only *one* aspect of the "compatibility problem."
>
> There is a grave and other serious problem, which relates to the fact
> that this proposal effectively creates a new baseline (i.e. a new ABI)
> for C++ programs, where programs linked (directly or indirectly)
> against
> this library are incompatible with our one and only bless (at this
> time)
> ABI, based on the libC that ships with Solaris today.
>
> And, the project recognizes that future breakage is not just possible,
> but *likely*, when either the compiler team ships another project, or
> when the library needs an update due to changes in the standard.
>
> Imagine the plight of the poor user who downloads a program
> (WhizzyDownloadTracker) which uses two different class libraries.  On
> the one hand, it uses the NiftyNetworking library for networking
> functionality, and it uses the KDE libraries for user interface work.
> Well, good thing, the IPS repo contains both NiftyNetworking and KDE.
> Download both, install, and then download, compile (via ./configure)
> and
> install the WhizzyDownloadTracker.  All's good, right?
>
> Well, a few hours later, when the compile for WhizzyDownloadTracker
> finally completes, we find out life isn't so good.
>
> Because you see, the NiftyNetworking set was not built with the Apache
> libstdc++, but instead with the "default" libraries that we have been
> recommending people use for years.  The user tries to run the program,
> and if he's lucky, gets a meaningful link error message.  In reality,
> the error message, if any, that results is probably completely cryptic
> to the end user, who was just trying to install software.  In a worse
> scenario, the program just dumps core mysteriously.
>
> The worst part of the above scenario, apart from the confusion that
> the
> poor non-C++-developing victim gets to experience, is that he's
> downloaded the foundation libraries from a single source (Sun's IPS
> repo), so they *should* work together, shouldn't they?!?
>
> Too bad.
>
> So now the user complains to the FOSS authors for
> WhizzyDownloadTracker,
> who are unfamiliar with Solaris (they did their development on Linux,
> see?), and don't know that Solaris has multiple incompatible C++ ABIs,
> nor how to tell which components were built against which ABI.
>
> So, the FOSS author probably gives up, and tells the poor user that he
> needs to recompile the base libraries (either KDE or NiftyNetworking),
> so that they are built with compatible libraries.
>
> At this point, the FOSS author is laughing at Sun and Solaris, and
> probably also cheerfully writes a blog somewhere admonishing folks
> against running Solaris.
>
> And, the original user?  He's probably given up.  Most likely he
> either
> he chooses not to use WhizzyDownloadTracker, or winds up giving up on
> Solaris and switches back to Linux or Windows.  Either way he's
> probably
> pretty ticked that "Sun" is delivering crapware that just doesn't work
> together.
>
> I don't know if the above illustration clearly enough paints the
> picture
> of my features, but I think it certainly demonstrates that we cannot
> just blithely ignore the issue and pretend it won't affect anyone.
>
>    -- Garrett
>
> Stefan Teleman wrote:
>>
>>
>> Garrett D'Amore wrote:
>>> John Plocher wrote:
>>>> Garrett D'Amore wrote:
>>>>> One of the implications of such a binding (Volatile), is that
>>>>> projects which build other C++ shared libraries upon this one
>>>>> cannot have a commitment level higher than Volatile either.
>>>>
>>>> Braap.  Bad Architecture Alert.  The whole reason we provide
>>>> abstractions
>>>> like consolidations and components is precisely so that we can
>>>> provide
>>>> "higher than Volatile" expectations for things that theselves may
>>>> exhibit
>>>> "less than Volatile" stability.
>>>>
>>>> There is no reason this couldn't be made a part of the KDE
>>>> consolidation,
>>>> and maintained by them as Committed interfaces for use by any KDE
>>>> consumers
>>>> who need it.  Volatile means "can change", not "will change", and
>>>> both the
>>>> Apache C++ Lib and the KDE projects certainly seem to meet the
>>>> basic
>>>> ARC
>>>> expectations of managing the compatible evolution of their
>>>> component.
>>>>
>>>> If the C++ basis that KDE builds upon were to change
>>>> incompatibly, I'd
>>>> expect KDE to react by producing a major release - again, just
>>>> like the
>>>> ARC would expect.
>>>>
>>>> Nothing here requires KDE to be Volatile.
>>>
>>> We're not talking about something that is delivered with
>>> Consolidation Private binding... we're talking about (assuming
>>> Volatile binding) something that could change underneath KDE.
>>> Such a
>>> change would be devastating to binary compatibility for applications
>>> linking against KDE C++ libraries.
>>>
>>> If KDE has a way to shield applications underneath from such a
>>> binary
>>> breakage, then its a different story altogether.  However, my
>>> understanding is that in this case (unlike more simple cases
>>> involving only C), there isn't a way for KDE to do that.
>>
>> This ARC Case is not about KDE, but about the Standard C++ Library.
>> What KDE may or may not expose in its header files, and how it
>> handles
>> implementation delegation design patterns is for a different ARC
>> Case.
>>
>>> I.e. with C++ code, if application #include's a KDE header, which
>>> itself #include's a libstdc++ header,  the binary bits of the
>>> application *very* likely contain details of the underlying libstdc
>>> ++
>>> implementation encoded in them.
>>
>> It is the responsibility of the implementation to shield any private
>> and potentially incompatible implementation details from the publicly
>> exported interfaces. For the purposes of this statement, "interfaces"
>> refers to both source and binary.
>>
>> The principle of separating interface from implementation is one of
>> the Design Principles of the C++ Programming Language, and has been a
>> C++ software design principle ever since the creation of the
>> Language.
>> It has been widely discussed and documented in relevant literature,
>> and it has also been put in practice by many C++ software systems,
>> including, but not limited to, the Apache Standard C++ Library, and/
>> or
>> the existing libCstd.so.1.
>>
>>> C++ is reasonably good at providing good programmatic boundaries
>>> between interface and implementation at the *source* code level.
>>> However, it falls down completely at the *binary* level.  (Which
>>> isn't to say that libraries simply *can't* prevent this sort of
>>> problem -- merely that the expectation should *not* be that they do,
>>> because it will probably require some rather grotesque contortions
>>> on
>>> the part of the library to do so.)
>>
>> The private implementation details of any particular C++ software
>> system are just that: private. The blanket statement that C++ falls
>> down completely at the binary compatibility level is false, and it is
>> invalidated by existing software practice. It is indeed possible to
>> maintain binary compatibility for a C++ software system, and no
>> grotesque contortions are required to achieve this goal.
>>
>>> Now, if the library (KDE) never #include's "standard" C++ headers
>>> (provided by this library) in its own headers (that it exports to
>>> applications), but only uses them in .cxx (or .cpp or .C or
>>> whatever)
>>> implementation files, then I agree that there is no problem.
>>> (Although the consuming application may itself still wind up needing
>>> to have its own dependency upon the libstdc++, but that issue is
>>> largely orthogonal as far as something like KDE is concerned.)
>>
>> The dependency constraint has already been clearly stated in the ARC
>> Case.
>>
>> Although it is generally considered a poor software implementation
>> choice to #include Standard C++ Library header files in application
>> header files exporting public interfaces, the implementation of the
>> Apache Standard C++ Library allows for this inclusion, without
>> breaking ABI [ pursuant to the compatibility constraints described in
>> the ARC Case Materials ]. However, the Language allows for the
>> implicit inclusion of interfaces from the Standard C++ Library [ or
>> for that matter, any other library ], in header files, without the
>> need for explicit #include directives.
>>
>> The Library incompatibility constraint is still in effect: the Apache
>> Standard C++ Library is not compatible with:
>>
>> - any implementation of the Apache Standard C++ Library, which is not
>> at Major Release 4 level
>> -  any _other_ implementation of the Standard C++ Library, including,
>> but not limited to: libCstd.so, the GNU Standard C++ Library,
>> STLport,
>> etc.
>>
>>> To put this in comparison, imagine if almost all of the standard C
>>> functions were simply *macros* rather than functions, and the macros
>>> made references to volatile innards of the C library.  While the
>>> *API* might be "clean" and safe, the *ABI* would most certainly not
>>> be.  This is the situation that we're in with C++, I think.
>>
>> Intentionally, and by Language Design, C++ inline functions, or
>> templates (which is what you are referring to) are *NOT* C macros. C
>> ++
>> inline functions are functions. C++ templates are templates. Their
>> symbols are mangled, they obey all the language overloading rules,
>> they are assigned the implicit "this" pointer by the compiler (if
>> they
>> are class members), and they behave exactly in the same way as any
>> other C++ function. They [ classes ] also implement a distinct type.
>>
>> The complexity of the implementation of C++ functions increases in
>> the
>> case where the class, or function in question, is a template (which
>> is
>> the case with the majority of the classes in the Standard C++
>> Library). If the class is a template, the compiler instantiates a
>> distinct type, based on the type defined by the class template
>> itself,
>> and on the underlying type upon which the template class is
>> instantiated. This instantiation mechanism alone is fundamentally
>> different than that of C macros.
>>
>> The type instantiation mechanism applies to non-template functions
>> and
>> classes as well.
>>
>> The compiler may or may not decide to eliminate the function call
>> altogether, by inlining in the resulting object file, and this is a
>> private decision of the compiler. The compiler may or may not decide
>> to eliminate the instantiation of the template [ class or function ]
>> altogether, based on internal compiler heuristic rules, and/or based
>> on whether or not the actual template function or template class is
>> actually referenced in the translation unit [ the default compiler
>> decision can be overridden with specific compiler flags, but that
>> facility is besides the point for this discussion ]. This decision,
>> again, is a private decision of the compiler.
>>
>> At this point, your comparison with C macros has fundamentally broken
>> down: there is no guarantee whatsoever that any of the template
>> classes or functions, whose interfaces have been imported by the
>> translation unit via header files, would have actually created the
>> required type and its corresponding instance, and/or that the
>> compiler
>> has, in fact, generated the corresponding symbol(s) in the binary
>> object.
>>
>> The means by which the implementation achieves the asserted ABI
>> compatibility goal is private to the implementation itself. In this
>> particular case, under discussion, this compatibility is enforced by
>> function calls to private, internal implementations of the facilities
>> required by the Language Standard (hence the presence of the shared
>> library object).
>>
>> Attempting to invalidate the ABI compatibility assertion of the
>> implementation by drawing comparisons with C Language macros, or with
>> the C Programming Language in general, is based on incorrect
>> assumptions about the C++ Programming Language, and is bound to fail
>> scrutiny.
>>
>> I am hereby requesting that the PSARC member who has derailed this
>> case provides concrete proof of ABI breakage in the Apache Standard
>> C++ Library, to the PSARC Committee, for review. Concrete proof
>> means:
>> source code, accompanied by an explanation of the breakage.
>>
>> For The Record: KDE has no intention whatsoever to modify the
>> Standard
>> C++ Library in an incompatible way.
>>
>> Thank you.
>>
>> --Stefan
>>
>
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc@opensolaris.org

_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org

--Boundary_(ID_WKDLSg/lgPzhjN99UdzQMA)-- From gdamore@sun.com Sat Sep 6 06:33:45 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m86DXYZx018470 for ; Sat, 6 Sep 2008 06:33:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m86DXIBq024951 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 21:33:24 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6S004010BLD300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 06:33:21 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6S0009Q07W4M60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 06:33:21 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m86DV83J024059 for ; Sat, 06 Sep 2008 06:31:08 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6S00D0101Q2100@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 06:31:08 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6S007VY07VWGA0@fe-sfbay-10.sun.com>; Sat, 06 Sep 2008 06:31:08 -0700 (PDT) Date: Sat, 06 Sep 2008 06:30:16 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: Sender: Garrett.Damore@sun.com To: John Sonnenschein Cc: Stefan Teleman , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, John Plocher , PSARC-ext@sun.com, Bart.Smaalders@sun.com, Steve Clamage Message-id: <48C285E8.8090405@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 16094 John Sonnenschein wrote: > I may regret throwing my hat in to this ring in the future, but with > respect to the example about user downloading $APP and having it not > work because it uses $FOO ( linked to libCstd ) and $BAR ( linked to > stdcxx ), that would mean that the developer of $APP explicitly linked > to both, which is just silly, that $FOO or $BAR changed under it's > feet, which would be a different ARC case altogether, or that > $FOO/$BAR had the STL ripped out from under /it's/ feet, and removal > of old libraries would be yet another ARC case altogether. No, the problem is that because they were linked with different implementations of the C++ standard library, $FOO and $BAR cannot coexist in the same address space. -- Garrett > > Take care > -John > > On 5-Sep-08, at 4:46 PM, Garrett D'Amore wrote: > >> Thank you for your instructional description of the C++ language with >> respect to templates. >> >> There are a few significant points, that I think you keep missing, or >> are glossing over: >> >> When I said C++ doesn't separate *binary* interface from implementation, >> I was *not* talking about the nice separation done for the benefit of >> the programmer. I was talking about separation done across the boundary >> created by the linker ... AFAIK, C++ does not recognize that there is >> such an interface boundary. >> >> In C++, if an inline function is expanded by the compiler, but makes use >> of *private* members of the class, then the *binary implementation* of >> the resulting code is *tied* to the implementation, and if the >> implementation changes (e.g. by changing the dynamically linked library) >> then there can be unfortunate consequences. >> >> I'm not a template expert, so I'll demonstrate with a simple inline >> function using C++ circa 1990. >> >> class box { >> int width; >> int height; >> /* put more private details here... */ >> >> public: >> void draw(); // private implementation elsewhere >> >> public inline int getwidth() { return width; } >> }; >> >> If this is in header, then the implementation parts (the width, the >> height and their offsets within the class) wind up getting encoded into >> the binary that includes this header. If the width or the height ever >> move (e..g by moving another member in front of them in the class), then >> the binary is busted. Likewise, if the private members change type >> (e.g. from a uint16_t to a uint32_t), breakage ensues. >> >> It is possible to have implementations that don't suffer from this >> problem, but it requires that the implementation refrain from inline >> functions, and take care that the headers *only* expose portions of the >> classes that will never ever change (or change in a way that breaks the >> binary implementation of the class.) I won't endeavor to describe how >> this problem may or may not affect templates, as such is out of my area >> of expertise. >> >> I've not kept up with the C++ standards admittedly, but I believe that >> this aspect of binary compatibility is not one that has been addressed >> in the standards, and likely not in the specification of the libraries. >> It is possible that the Apache product has taken great care to avoid >> this kind of potential breakage, but my first reaction is doubt. >> >> Now, that's only *one* aspect of the "compatibility problem." >> >> There is a grave and other serious problem, which relates to the fact >> that this proposal effectively creates a new baseline (i.e. a new ABI) >> for C++ programs, where programs linked (directly or indirectly) against >> this library are incompatible with our one and only bless (at this time) >> ABI, based on the libC that ships with Solaris today. >> >> And, the project recognizes that future breakage is not just possible, >> but *likely*, when either the compiler team ships another project, or >> when the library needs an update due to changes in the standard. >> >> Imagine the plight of the poor user who downloads a program >> (WhizzyDownloadTracker) which uses two different class libraries. On >> the one hand, it uses the NiftyNetworking library for networking >> functionality, and it uses the KDE libraries for user interface work. >> Well, good thing, the IPS repo contains both NiftyNetworking and KDE. >> Download both, install, and then download, compile (via ./configure) and >> install the WhizzyDownloadTracker. All's good, right? >> >> Well, a few hours later, when the compile for WhizzyDownloadTracker >> finally completes, we find out life isn't so good. >> >> Because you see, the NiftyNetworking set was not built with the Apache >> libstdc++, but instead with the "default" libraries that we have been >> recommending people use for years. The user tries to run the program, >> and if he's lucky, gets a meaningful link error message. In reality, >> the error message, if any, that results is probably completely cryptic >> to the end user, who was just trying to install software. In a worse >> scenario, the program just dumps core mysteriously. >> >> The worst part of the above scenario, apart from the confusion that the >> poor non-C++-developing victim gets to experience, is that he's >> downloaded the foundation libraries from a single source (Sun's IPS >> repo), so they *should* work together, shouldn't they?!? >> >> Too bad. >> >> So now the user complains to the FOSS authors for WhizzyDownloadTracker, >> who are unfamiliar with Solaris (they did their development on Linux, >> see?), and don't know that Solaris has multiple incompatible C++ ABIs, >> nor how to tell which components were built against which ABI. >> >> So, the FOSS author probably gives up, and tells the poor user that he >> needs to recompile the base libraries (either KDE or NiftyNetworking), >> so that they are built with compatible libraries. >> >> At this point, the FOSS author is laughing at Sun and Solaris, and >> probably also cheerfully writes a blog somewhere admonishing folks >> against running Solaris. >> >> And, the original user? He's probably given up. Most likely he either >> he chooses not to use WhizzyDownloadTracker, or winds up giving up on >> Solaris and switches back to Linux or Windows. Either way he's probably >> pretty ticked that "Sun" is delivering crapware that just doesn't work >> together. >> >> I don't know if the above illustration clearly enough paints the picture >> of my features, but I think it certainly demonstrates that we cannot >> just blithely ignore the issue and pretend it won't affect anyone. >> >> -- Garrett >> >> Stefan Teleman wrote: >>> >>> >>> Garrett D'Amore wrote: >>>> John Plocher wrote: >>>>> Garrett D'Amore wrote: >>>>>> One of the implications of such a binding (Volatile), is that >>>>>> projects which build other C++ shared libraries upon this one >>>>>> cannot have a commitment level higher than Volatile either. >>>>> >>>>> Braap. Bad Architecture Alert. The whole reason we provide >>>>> abstractions >>>>> like consolidations and components is precisely so that we can >>>>> provide >>>>> "higher than Volatile" expectations for things that theselves may >>>>> exhibit >>>>> "less than Volatile" stability. >>>>> >>>>> There is no reason this couldn't be made a part of the KDE >>>>> consolidation, >>>>> and maintained by them as Committed interfaces for use by any KDE >>>>> consumers >>>>> who need it. Volatile means "can change", not "will change", and >>>>> both the >>>>> Apache C++ Lib and the KDE projects certainly seem to meet the basic >>>>> ARC >>>>> expectations of managing the compatible evolution of their component. >>>>> >>>>> If the C++ basis that KDE builds upon were to change incompatibly, >>>>> I'd >>>>> expect KDE to react by producing a major release - again, just >>>>> like the >>>>> ARC would expect. >>>>> >>>>> Nothing here requires KDE to be Volatile. >>>> >>>> We're not talking about something that is delivered with >>>> Consolidation Private binding... we're talking about (assuming >>>> Volatile binding) something that could change underneath KDE. Such a >>>> change would be devastating to binary compatibility for applications >>>> linking against KDE C++ libraries. >>>> >>>> If KDE has a way to shield applications underneath from such a binary >>>> breakage, then its a different story altogether. However, my >>>> understanding is that in this case (unlike more simple cases >>>> involving only C), there isn't a way for KDE to do that. >>> >>> This ARC Case is not about KDE, but about the Standard C++ Library. >>> What KDE may or may not expose in its header files, and how it handles >>> implementation delegation design patterns is for a different ARC Case. >>> >>>> I.e. with C++ code, if application #include's a KDE header, which >>>> itself #include's a libstdc++ header, the binary bits of the >>>> application *very* likely contain details of the underlying libstdc++ >>>> implementation encoded in them. >>> >>> It is the responsibility of the implementation to shield any private >>> and potentially incompatible implementation details from the publicly >>> exported interfaces. For the purposes of this statement, "interfaces" >>> refers to both source and binary. >>> >>> The principle of separating interface from implementation is one of >>> the Design Principles of the C++ Programming Language, and has been a >>> C++ software design principle ever since the creation of the Language. >>> It has been widely discussed and documented in relevant literature, >>> and it has also been put in practice by many C++ software systems, >>> including, but not limited to, the Apache Standard C++ Library, and/or >>> the existing libCstd.so.1. >>> >>>> C++ is reasonably good at providing good programmatic boundaries >>>> between interface and implementation at the *source* code level. >>>> However, it falls down completely at the *binary* level. (Which >>>> isn't to say that libraries simply *can't* prevent this sort of >>>> problem -- merely that the expectation should *not* be that they do, >>>> because it will probably require some rather grotesque contortions on >>>> the part of the library to do so.) >>> >>> The private implementation details of any particular C++ software >>> system are just that: private. The blanket statement that C++ falls >>> down completely at the binary compatibility level is false, and it is >>> invalidated by existing software practice. It is indeed possible to >>> maintain binary compatibility for a C++ software system, and no >>> grotesque contortions are required to achieve this goal. >>> >>>> Now, if the library (KDE) never #include's "standard" C++ headers >>>> (provided by this library) in its own headers (that it exports to >>>> applications), but only uses them in .cxx (or .cpp or .C or whatever) >>>> implementation files, then I agree that there is no problem. >>>> (Although the consuming application may itself still wind up needing >>>> to have its own dependency upon the libstdc++, but that issue is >>>> largely orthogonal as far as something like KDE is concerned.) >>> >>> The dependency constraint has already been clearly stated in the ARC >>> Case. >>> >>> Although it is generally considered a poor software implementation >>> choice to #include Standard C++ Library header files in application >>> header files exporting public interfaces, the implementation of the >>> Apache Standard C++ Library allows for this inclusion, without >>> breaking ABI [ pursuant to the compatibility constraints described in >>> the ARC Case Materials ]. However, the Language allows for the >>> implicit inclusion of interfaces from the Standard C++ Library [ or >>> for that matter, any other library ], in header files, without the >>> need for explicit #include directives. >>> >>> The Library incompatibility constraint is still in effect: the Apache >>> Standard C++ Library is not compatible with: >>> >>> - any implementation of the Apache Standard C++ Library, which is not >>> at Major Release 4 level >>> - any _other_ implementation of the Standard C++ Library, including, >>> but not limited to: libCstd.so, the GNU Standard C++ Library, STLport, >>> etc. >>> >>>> To put this in comparison, imagine if almost all of the standard C >>>> functions were simply *macros* rather than functions, and the macros >>>> made references to volatile innards of the C library. While the >>>> *API* might be "clean" and safe, the *ABI* would most certainly not >>>> be. This is the situation that we're in with C++, I think. >>> >>> Intentionally, and by Language Design, C++ inline functions, or >>> templates (which is what you are referring to) are *NOT* C macros. C++ >>> inline functions are functions. C++ templates are templates. Their >>> symbols are mangled, they obey all the language overloading rules, >>> they are assigned the implicit "this" pointer by the compiler (if they >>> are class members), and they behave exactly in the same way as any >>> other C++ function. They [ classes ] also implement a distinct type. >>> >>> The complexity of the implementation of C++ functions increases in the >>> case where the class, or function in question, is a template (which is >>> the case with the majority of the classes in the Standard C++ >>> Library). If the class is a template, the compiler instantiates a >>> distinct type, based on the type defined by the class template itself, >>> and on the underlying type upon which the template class is >>> instantiated. This instantiation mechanism alone is fundamentally >>> different than that of C macros. >>> >>> The type instantiation mechanism applies to non-template functions and >>> classes as well. >>> >>> The compiler may or may not decide to eliminate the function call >>> altogether, by inlining in the resulting object file, and this is a >>> private decision of the compiler. The compiler may or may not decide >>> to eliminate the instantiation of the template [ class or function ] >>> altogether, based on internal compiler heuristic rules, and/or based >>> on whether or not the actual template function or template class is >>> actually referenced in the translation unit [ the default compiler >>> decision can be overridden with specific compiler flags, but that >>> facility is besides the point for this discussion ]. This decision, >>> again, is a private decision of the compiler. >>> >>> At this point, your comparison with C macros has fundamentally broken >>> down: there is no guarantee whatsoever that any of the template >>> classes or functions, whose interfaces have been imported by the >>> translation unit via header files, would have actually created the >>> required type and its corresponding instance, and/or that the compiler >>> has, in fact, generated the corresponding symbol(s) in the binary >>> object. >>> >>> The means by which the implementation achieves the asserted ABI >>> compatibility goal is private to the implementation itself. In this >>> particular case, under discussion, this compatibility is enforced by >>> function calls to private, internal implementations of the facilities >>> required by the Language Standard (hence the presence of the shared >>> library object). >>> >>> Attempting to invalidate the ABI compatibility assertion of the >>> implementation by drawing comparisons with C Language macros, or with >>> the C Programming Language in general, is based on incorrect >>> assumptions about the C++ Programming Language, and is bound to fail >>> scrutiny. >>> >>> I am hereby requesting that the PSARC member who has derailed this >>> case provides concrete proof of ABI breakage in the Apache Standard >>> C++ Library, to the PSARC Committee, for review. Concrete proof means: >>> source code, accompanied by an explanation of the breakage. >>> >>> For The Record: KDE has no intention whatsoever to modify the Standard >>> C++ Library in an incompatible way. >>> >>> Thank you. >>> >>> --Stefan >>> >> >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org > From gdamore@sun.com Sat Sep 6 06:58:23 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m86DwNtr018839 for ; Sat, 6 Sep 2008 06:58:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m86DwMXG044885 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 07:58:22 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6S00I031HADK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 07:58:22 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6S00G3Y1H96W10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 07:58:22 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m86DwLN6015361 for ; Sat, 06 Sep 2008 06:58:21 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6S00G0118WKP00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 06:58:21 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6S006ZU1H8EO30@fe-sfbay-09.sun.com>; Sat, 06 Sep 2008 06:58:21 -0700 (PDT) Date: Sat, 06 Sep 2008 06:57:29 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C229B2.7080002@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, John Plocher , PSARC-ext@sun.com, Bart.Smaalders@sun.com, Steve Clamage Message-id: <48C28C49.2030902@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C229B2.7080002@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 9351 Stefan Teleman wrote: > > > Garrett D'Amore wrote: >> Reading the Apache C++ sources (which I didn't want to do, but here >> you go), I ran into the following example snippet in the include >> directory (the include file is ): >> >> template >> inline typename basic_streambuf<_CharT, _Traits>::int_type >> basic_streambuf<_CharT, _Traits>:: >> sputbackc (char_type __c) >> { >> _RWSTD_ASSERT (_C_is_valid ()); >> >> if (_C_putback_avail () && traits_type::eq (*(gptr () - 1), __c)) >> return traits_type::to_int_type (*--_C_gptr); >> >> return pbackfail (traits_type::to_int_type (__c)); >> } >> >> >> In the above example, the inline function has in it bits which appear >> to me to be implementation details (_C_putback_avail() is protected >> for example -- I'm not sure whether the *standard* specifies that it >> exist or not. _C_gptr is certainly a private member of the class, >> and I "presume" that the standard doesn't specify it, though I've not >> checked the standard since I don't have a copy of it handy.) >> >> The concern here is what happens if those portions of the >> implementation need to change? (What happens if _C_gptr moves in the >> class, or the implementation needs to change in a way that _C_gptr >> doesn't exist at all, or changes type? Bad things, I suspect.) > > These changes cannot be made. Not for the duration of Major Release 4. > > This is what the Standard says about this particular member function: > > 27.5.2.2.4 Putback > > int_type sputbackc(char_type c); > > 1 Returns: If the input sequence putback position is not available, > or if > traits::eq(c, gptr()[-1]) is false, returns > pbackfail(traits::to_int_type(c)). Otherwise, decrements the next > pointer for the input sequence and returns > traits::to_int_type (*gptr()). > > The function _C_putback_avail() is private to this implementation of > the Library (in the Apache Library's case all functions, or data > members whose names begin with "_C" are private to the > implementation). The pointer _C_gptr (or a functional equivalent > thereof) is mandated by the Standard. This naming convention is a > warning to the developer of the application consuming the interfaces > exposed by : Do Not Use These Functions Directly Under Any > Circumstances Whatsoever. Also, the fact that is is protected imposes > restrictions on access. > > The important aspect is that the gptr() (which Apache calls _C_gptr) > is explicitly mentioned in the Standard. But gptr() isn't what is being used ... what is being used is _C_gptr, which is a data member, not a function. The upshot of that is that the implementation of the class winds up being encoded in the consuming application's binary. > > > If you compare version 4.2.1 of this Standard header file with the > same header file from versions 4.2.0, or 4.1.3, you will see that the > changes made to this header file do not break binary compatibility. > >> Will the implementation take care to preserve the *existing* >> functions so that the above inline (which will now have been compiled >> into various applications) will continue to function, regardless of >> what other changes may be necessary for the class? > > The implementation *must* preserve those functions and data members > (or functional equivalents thereof) which are mandated by the > Standard. These cannot be changed in any way -- they are immutable. But we're not talking about things mandated by the standard. And the standard in no way dictates anything about how those functions and data members are encoded by the compiler. That is the problem we seem to be having here. You're mistaking an immutable *programming interface* for an immutable *binary interface*. > > New, non-virtual member functions could be added to this class > (non-virtual functions do not affect the size or the layout of the > object, or of the __vtbl), provided that their names begins with "_C", > and are therefore labeled as private to the implementation. Static > member functions could be safely added (they don't even have an > implicit "this" pointer at all, and they do not affect the size or the > layout of the object), subject to the same naming convention constraints. Yes, there are ways to add to the implementation safely without breaking the binary interface, I understand that. > > New virtual member functions, and/or new data members cannot be added, > under any circumstances whatsoever. But such additions should not be > even considered in the first place -- this version of the Standard is > frozen. Adding a virtual function to this class will first and > foremost violate the interfaces mandated by the Standard. No, it won't. Adding a new private data member does *not* violate the standard -- because the standard doesn't say anything about the internal implementation of the class. What it *will* do is break the things not spelled out by the standard -- such as the binary interface generated by the compiler and linker. > > What could change, with less restrictions, are the private > implementation details which can be found in the $(top_srcdir)/src > directory, and whose names begin with "__rw". But those changes would be equally toxic to any application which included those headers (directly, or indirectly such as via class inheritance or containment.) I've not reviewed the source code to look to see if this is handled properly, but at the moment (based on the other things I've seen in the code), I'd be surprised if this were done properly and safely. > >> I apologize for my apparently childish C++ example earlier -- as I >> said, I don't work in the language very often. But I *think* I've >> found a real example from Apache C++ that suffers the same problem. >> Do you disagree? > > I do not see this example as a reason for binary compatibility > breakage concern, provided that the rules for preserving binary > compatibility are observed (which I have no reason to believe that > they will not be). See, but I have no reason to believe that they will be. I searched on Apache's website, and I could find no statements indicating any kind of intent about binary compatibility. I suspect, like most of the rest of the C++ world, these folks are concerned primarily (perhaps only) with compatibility at the source code level. Now, if you're able to provide some concrete evidence as to why you believe the Apache C++ group will honor a binary stability level and not break classes in ways that break dynamically linked applications, then I'd be happy to set aside this *particular* portion of my argument. > Everything i've said here i can guarantee that is is also very well > known by the Apache/RogueWave developers as well -- most likely much > more. Maybe. But that doesn't mean they care. I believe Linus Torvalds "understands" how to binary compatible interfaces can be made -- but he has adamantly refused the notion that Linux needs binary stability. I don't know *what* the Apache's team stance is, since I can't find any documented statement one way or the other. > > No apologies necessary. There are design circumstances in which the > developer of the library interface simply knows that the class layout > cannot change, ever. For those circumstances, freezing the object > layout is appropriate. > > KDE, and QT, intentionally do not use this approach. For all the > library classes which expose public interfaces available to external > consumers, the private implementation details are hidden by means of > the Bridge or Facade Design Patterns (pImpl pattern). The actual > implementation of the header file only exposes member functions, and > the only data member is an opaque pointer to the private > implementation. The actual private implementation is done in the *.cpp > translation unit. Yes, this kind of approach could generate a binary safe API, provided that the header files involved in the APIs exposed expose only method prototypes and not method implementation. That might mean that KDE or Gnome could use *whatever* library they wished with little regard to the library underneath changing. *Except* that there is still a link time problem of mixing libraries built against different Standard C++ libraries. I notice you've studiously ignored this problem in your replies. At this point, I'm even more convinced now (both by reading the actual Apache C++ source code, and by Steve Clamage's comments substantiating my concerns) that I was correct and these problems need to be addressed, and the project is way out of bounds as a fast track (at least as specified.) The case remains derailed. I propose that further discussion be taken *off* PSARC-ext, until the project team is ready to present a full case. If the project team believes that my concerns are irrelevant and unfounded, then they can ask to be put on the schedule for Wednesday's meeting, where they can try to convince the other members and ask for a vote at the end of the meeting. Further argument about this case on the public lists at this point is probably fruitless. I'll be happy to respond to private e-mail if you wish to discuss it further. -- Garrett From John.Plocher@Sun.COM Sat Sep 6 08:09:55 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m86F9sI3019696 for ; Sat, 6 Sep 2008 08:09:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m86F9rYf024729 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 16:09:53 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6S00A034SH4C00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 08:09:53 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6S00HHL4SGOLC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 08:09:52 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m86F9qn1016532 for ; Sat, 06 Sep 2008 08:09:52 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6S00I014ORYA00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 08:09:52 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6S006Q84SFEOC0@fe-sfbay-09.sun.com>; Sat, 06 Sep 2008 08:09:52 -0700 (PDT) Date: Sat, 06 Sep 2008 08:09:51 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C201B1.4060803@sun.com> Sender: John.Plocher@Sun.COM To: "Garrett D'Amore" Cc: Stefan Teleman , John.Fischer@Sun.COM, PSARC-ext@Sun.COM, Steve Clamage Message-id: <48C29D3F.1000205@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 1439 Garrett D'Amore wrote: > Will the implementation take care to preserve the *existing* functions > so that the above inline (which will now have been compiled into various > applications) will continue to function, regardless of what other > changes may be necessary for the class? The materials Stefan has submitted state that the Apache C++StdLib project has made the commitment to not muck up these types of implementation details in any but one of their major releases. That is, even though the incompatibly evolving C++ language definitions and associated rickety scaffolding may allow one to shoot themselves in the foot, and their code could be evolved in ways that would expose such runtime binary incompatibilities, they explicitly promise not to do so within a certain set of release naming boundaries. What more can the ARC ask? This is exactly what we do with goode olde libc. The only difference is that the C++ world allows for (and oddly, seems rather comfortable with) incompatible future versions. At that point, the Apache Standard C++ Library would need to rev its HNAME and .so versioning info, but again, this is exactly what we did with libc. My only disconnect here was our left and right hands not talking to each other, and now that Stefan and Steve are exchanging email, I'm not even very worried about that - though I'm sure someone will let me know if/when I should start worrying again :-) -John From Stephen.Clamage@sun.com Sat Sep 6 08:18:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m86FI0R5019733 for ; Sat, 6 Sep 2008 08:18:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m86FHvAQ022183 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 23:17:59 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6S00A0955XIG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 08:17:57 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6S00HSO55SOLC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 08:17:56 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m86FHqjI016643 for ; Sat, 06 Sep 2008 08:17:52 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6S00K0150OG800@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 08:17:52 -0700 (PDT) Received: from [10.0.0.5] ([68.126.179.11]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6S006G855SEOD0@fe-sfbay-09.sun.com>; Sat, 06 Sep 2008 08:17:52 -0700 (PDT) Date: Sat, 06 Sep 2008 08:17:51 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C28C49.2030902@sun.com> Sender: Stephen.Clamage@sun.com To: "Garrett D'Amore" Cc: Stefan Teleman , John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, John Plocher , PSARC-ext@sun.com, Bart.Smaalders@sun.com Message-id: <48C29F1F.6010107@sun.com> Organization: Sun Microsystems, Inc MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C229B2.7080002@Sun.COM> <48C28C49.2030902@sun.com> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 2217 Regarding binary compatibility guarantees, I think the main point is being missed. Because of inline functions and other factors, many implementation details of the standard library get baked into client object code. Every supplier of a C++ Standard Library implementation is well aware of this fact. They know that to claim that two releases are binary compatible, many implementation details, like the layout or member types of a class, cannot change. I can make this statement because all the implementers are members of the C++ Committee, and compatibility is one of the topics that informs every decision about language and library changes. For libCstd, among other libraries that we ship, we are careful that bug fixes and enhancements do not affect binary compatibility. Because of this constraint, there are bugs in some libraries that we can't fix. The maintainers of libstdcxx are equally aware of these issues. If they claim binary compatibility, it is reasonably safe to believe them. But that's not the whole story. Some of the libraries that we ship originate with third parties. We generally don't download updates of those libraries because of binary compatibility concerns. If a bug is reported on the library we ship, we fix it in our sources, sometimes by editing in a fix from the current library sources if it doesn't break compatibility. We tell customers that the libraries we ship are upwardly binary compatible across releases (you can link a new library version into an old program), but we make no claims about versions of the library they acquire elsewhere. The reason is not only because a different version of the source code might not be binary compatible, but also because libraries have dozens of configuration parameters that affect binary compatibility. Even with identical source code, a customer-built version of the library could be incompatible if configuration parameters were set differently. Bottom line: If we ship this library, we can safely claim continued binary compatibility for what we ship, because we will make it so. We cannot promise compatibility with libraries built by someone else. --- Steve Clamage, stephen.clamage@sun.com From Stefan.Teleman@Sun.COM Sat Sep 6 11:46:24 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m86IkOAM023440 for ; Sat, 6 Sep 2008 11:46:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m86IkLg0000415; Sat, 6 Sep 2008 11:46:21 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6S00H05ET8XF00@brm-avmta-1.central.sun.com>; Sat, 06 Sep 2008 12:46:20 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6S00G13ET66PC0@brm-avmta-1.central.sun.com>; Sat, 06 Sep 2008 12:46:18 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m86IjHTN014904; Sat, 06 Sep 2008 11:45:23 -0700 (PDT) Date: Sat, 06 Sep 2008 14:45:14 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C28C49.2030902@sun.com> To: "Garrett D'Amore" Cc: John.Fischer@Sun.COM, Joep.Vesseur@Sun.COM, Gary Winiger , gww@eng.sun.com, John Plocher , PSARC-ext@Sun.COM, Bart.Smaalders@Sun.COM, Steve Clamage Reply-to: Stefan Teleman Message-id: <48C2CFBA.3010801@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C229B2.7080002@Sun.COM> <48C28C49.2030902@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1331 Garrett D'Amore wrote: > But we're not talking about things mandated by the standard. And the > standard in no way dictates anything about how those functions and data > members are encoded by the compiler. That is the problem we seem to be > having here. You are asserting that the compiler will encode the binary representation of std::streambuf differently, simply because the library version has revved up, but the class layout remains identical ? If this is what you are asserting [ and this is what I understand you are asserting ], please prove it. I cannot prove that the compiler isn't broken. You're also now raising the non-existent problem of the gptr() vs. _C_gptr. In other words, the sample implementations provided by the Standards, vs. the actual implementation of this particular Library. I do not see the point of discussing why the Apache Standard C++ Library chose to implement _C_gptr instead of gptr() [ not that the actual intent of the Standard is violated in any way ]. > You're mistaking an immutable *programming interface* for an immutable > *binary interface*. Please stop telling me what I do and do not understand. You still have not provided a single example of ABI breakage in the Apache Library. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Stefan.Teleman@sun.com Sat Sep 6 12:34:14 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m86JYDcY024022 for ; Sat, 6 Sep 2008 12:34:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m86JY6dd028184; Sat, 6 Sep 2008 20:34:11 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6S00003H0YEF00@nwk-avmta-2.sfbay.sun.com>; Sat, 06 Sep 2008 12:34:10 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6S00J33H0XB620@nwk-avmta-2.sfbay.sun.com>; Sat, 06 Sep 2008 12:34:09 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m86JXowb017202; Sat, 06 Sep 2008 12:33:57 -0700 (PDT) Date: Sat, 06 Sep 2008 15:33:50 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C29D3F.1000205@Sun.Com> To: John Plocher Cc: "Garrett D'Amore" , John.Fischer@sun.com, PSARC-ext@sun.com, Steve Clamage Reply-to: Stefan Teleman Message-id: <48C2DB1E.7080806@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2533 John Plocher wrote: > Garrett D'Amore wrote: >> Will the implementation take care to preserve the *existing* functions >> so that the above inline (which will now have been compiled into various >> applications) will continue to function, regardless of what other >> changes may be necessary for the class? > > The materials Stefan has submitted state that the Apache C++StdLib project > has made the commitment to not muck up these types of implementation details > in any but one of their major releases. For the record, we're not going to muck with anything. Also for the record, we have no plans of tracking every single micro release of stdcxx 4. Upgrading to micro releases is TBD, based on what the new rev actually introduces. The development cycle of stdcxx often uses micro releases to address bugs specific to a particular compiler/architecture combo. This isn't always relevant to Sun Studio/Solaris. If it isn't relevant, why fix it when it ain't broken ? > That is, even though the incompatibly evolving C++ language definitions and > associated rickety scaffolding may allow one to shoot themselves in the foot, > and their code could be evolved in ways that would expose such runtime > binary incompatibilities, they explicitly promise not to do so within a > certain set of release naming boundaries. > > What more can the ARC ask? This is exactly what we do with goode olde libc. > The only difference is that the C++ world allows for (and oddly, seems rather > comfortable with) incompatible future versions. > > At that point, the Apache Standard C++ Library would need to rev its HNAME > and .so versioning info, but again, this is exactly what we did with libc. > > My only disconnect here was our left and right hands not talking to each other, > and now that Stefan and Steve are exchanging email, I'm not even very worried > about that - though I'm sure someone will let me know if/when I should start > worrying again :-) Steve Clamage and myself had reached an agreement on this, a couple of days ago: 1. We [ SFW/KDE ] were going to introduce this library in Nevada/OpenSolaris -- it's the easiest integration, and it's the one we care most about, because it can be done *now*. 2. They [ DevPro/Tools ] were going to introduce this library with the compiler(s), for Solaris 9/10, at some point in the future. I cannot say when that will be. Is this agreement still valid ? Or has it been filibustered ? --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From John.Plocher@sun.com Sat Sep 6 14:30:31 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m86LUVN4027047 for ; Sat, 6 Sep 2008 14:30:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m86LUSb2022625 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Sep 2008 22:30:30 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6S00603METAQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 14:30:29 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6S00J4FMESB650@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 14:30:29 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m86LUSWd023333 for ; Sat, 06 Sep 2008 14:30:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6S00K01MCALP00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 06 Sep 2008 14:30:28 -0700 (PDT) Received: from [192.168.168.4] ([208.74.177.212]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6S005A1MESRR50@fe-sfbay-09.sun.com>; Sat, 06 Sep 2008 14:30:28 -0700 (PDT) Date: Sat, 06 Sep 2008 14:30:28 -0700 From: John Plocher Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C2DB1E.7080806@Sun.COM> Sender: John.Plocher@sun.com To: Stefan Teleman Cc: John.Fischer@sun.com, PSARC-ext@sun.com, "Garrett D'Amore" , Steve Clamage Message-id: <48C2F674.5090805@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 1157 Stefan Teleman wrote: > Steve Clamage and myself had reached an agreement on this, a couple of days ago: > > 1. We [ SFW/KDE ] were going to introduce this library in Nevada/OpenSolaris -- > it's the easiest integration, and it's the one we care most about, because it > can be done *now*. > 2. They [ DevPro/Tools ] were going to introduce this library with the > compiler(s), for Solaris 9/10, at some point in the future. I cannot say when > that will be. > > Is this agreement still valid ? I hope so. Even if this case is derailed, derailing does not invalidate anything. I would like to see in one place (i.e., NEED SPEC) the expected transition/migration path (including who does what, where it will live, and what names it will be known by) for the whole journey from today (Sun shipping old/other stuff) to tomorrow (what this case delivers) ending up at the day after (when the compiler team delivers it). This is so we can validate the deployed app experience - will things actually work while we do the transition? Most of this has been mentioned in this email thread, so I do not think I'm asking for anything difficult. -John From Stefan.Teleman@sun.com Sat Sep 6 14:39:39 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m86Ldcbd027081 for ; Sat, 6 Sep 2008 14:39:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m86LdYgf024434; Sat, 6 Sep 2008 22:39:36 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6S00F03MTYMP00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 06 Sep 2008 14:39:34 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6S003ICMTXQT40@nwk-avmta-1.sfbay.Sun.COM>; Sat, 06 Sep 2008 14:39:33 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m86LdWEP021015; Sat, 06 Sep 2008 14:39:33 -0700 (PDT) Date: Sat, 06 Sep 2008 17:39:32 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C2F674.5090805@Sun.Com> To: John Plocher Cc: John.Fischer@sun.com, PSARC-ext@sun.com, "Garrett D'Amore" , Steve Clamage Reply-to: Stefan Teleman Message-id: <48C2F894.9090909@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C2F674.5090805@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1486 John Plocher wrote: > Stefan Teleman wrote: >> Steve Clamage and myself had reached an agreement on this, a couple of days ago: >> >> 1. We [ SFW/KDE ] were going to introduce this library in Nevada/OpenSolaris -- >> it's the easiest integration, and it's the one we care most about, because it >> can be done *now*. >> 2. They [ DevPro/Tools ] were going to introduce this library with the >> compiler(s), for Solaris 9/10, at some point in the future. I cannot say when >> that will be. >> >> Is this agreement still valid ? > > I hope so. Even if this case is derailed, derailing does not > invalidate anything. > > I would like to see in one place (i.e., NEED SPEC) the expected > transition/migration path (including who does what, where it will > live, and what names it will be known by) for the whole journey > from today (Sun shipping old/other stuff) to tomorrow (what this > case delivers) ending up at the day after (when the compiler team > delivers it). > > This is so we can validate the deployed app experience - will > things actually work while we do the transition? > > Most of this has been mentioned in this email thread, so I > do not think I'm asking for anything difficult. This is absolutely fine, and to be expected. I propose to work with Steve Clamage and write up a document outlining in detail all the steps you indicated above. Steve, is this plan ok with you ? --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gdamore@sun.com Sun Sep 7 08:01:24 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m87F1NHv015525 for ; Sun, 7 Sep 2008 08:01:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m87F1MLp027604 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 7 Sep 2008 08:01:23 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6T00007Z299F00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sun, 07 Sep 2008 09:01:21 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6T00H2DZ28EV40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Sun, 07 Sep 2008 09:01:21 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m87F1KiW008117 for ; Sun, 07 Sep 2008 08:01:20 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6T00L01YWZGN00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sun, 07 Sep 2008 08:01:20 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6T00E1WZ27KXB0@fe-sfbay-10.sun.com>; Sun, 07 Sep 2008 08:01:20 -0700 (PDT) Date: Sun, 07 Sep 2008 08:00:22 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C2CFBA.3010801@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: John.Fischer@sun.com, Joep.Vesseur@sun.com, Gary Winiger , gww@eng.sun.com, John Plocher , PSARC-ext@sun.com, Bart.Smaalders@sun.com, Steve Clamage Message-id: <48C3EC86.7070603@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C229B2.7080002@Sun.COM> <48C28C49.2030902@sun.com> <48C2CFBA.3010801@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2215 Stefan Teleman wrote: > > > Garrett D'Amore wrote: > >> But we're not talking about things mandated by the standard. And the >> standard in no way dictates anything about how those functions and >> data members are encoded by the compiler. That is the problem we >> seem to be having here. > > You are asserting that the compiler will encode the binary > representation of std::streambuf differently, simply because the > library version has revved up, but the class layout remains identical ? That isn't what I'm asserting. I'm asserting that the architecture in the libraries *appears* (to me at least) be fragile where binary compatibility is concerned. > > If this is what you are asserting [ and this is what I understand you > are asserting ], please prove it. I cannot prove that the compiler > isn't broken. The compiler isn't broken. > > You're also now raising the non-existent problem of the gptr() vs. > _C_gptr. > In other words, the sample implementations provided by the Standards, > vs. the actual implementation of this particular Library. But _C_ptr (or rather its offset) gets encoded into binary applications. So, that member becomes locked in stone, or the member (both its type and offset) is not permitted to change without a break in the binary compatibility. > > I do not see the point of discussing why the Apache Standard C++ > Library chose to implement _C_gptr instead of gptr() [ not that the > actual intent of the Standard is violated in any way ]. You were looking for an *example* of the kinds of breakage that could occur in the Apache C++. I only picked on this one because it illustrated my point. > >> You're mistaking an immutable *programming interface* for an >> immutable *binary interface*. > > Please stop telling me what I do and do not understand. You still have > not provided a single example of ABI breakage in the Apache Library. I give up. If you have nothing else claim (and I can't seem to make my concerns understood by you, and possibly not even to other ARC members, I'm not sure), then just ask for a business vote on Wednesday. I'll write the minority opinion if your case is approved. -- Garrett > > --Stefan > From Stephen.Clamage@sun.com Sun Sep 7 08:12:55 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m87FCsjK015588 for ; Sun, 7 Sep 2008 08:12:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m87FCqPD004726 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 7 Sep 2008 16:12:53 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6T00D05ZLH5J00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 07 Sep 2008 08:12:53 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6T00B0VZLHDDD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 07 Sep 2008 08:12:53 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m87FCqvu006717 for ; Sun, 07 Sep 2008 08:12:52 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6T00101ZEY7J00@fe-sfbay-10.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 07 Sep 2008 08:12:52 -0700 (PDT) Received: from [10.0.0.5] ([68.126.182.43]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6T00EAQZLGKXC0@fe-sfbay-10.sun.com>; Sun, 07 Sep 2008 08:12:52 -0700 (PDT) Date: Sun, 07 Sep 2008 08:12:51 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C2DB1E.7080806@Sun.COM> Sender: Stephen.Clamage@sun.com To: Stefan Teleman Cc: John Plocher , "Garrett D'Amore" , John.Fischer@sun.com, PSARC-ext@sun.com Message-id: <48C3EF73.1090309@sun.com> Organization: Sun Microsystems, Inc MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 1029 On 9/6/2008 12:33 PM, Stefan Teleman wrote: > > Steve Clamage and myself had reached an agreement on this, a couple of > days ago: > > 1. We [ SFW/KDE ] were going to introduce this library in > Nevada/OpenSolaris -- it's the easiest integration, and it's the one we > care most about, because it can be done *now*. > 2. They [ DevPro/Tools ] were going to introduce this library with the > compiler(s), for Solaris 9/10, at some point in the future. I cannot say > when that will be. > > Is this agreement still valid ? Or has it been filibustered ? I don't remember agreeing to SFW/KDE introducing the library into SNV/OpenSolaris, at least not in the form of the original proposal. My team and I are looking into the technical issues involved in delivering the library seamlessly integrated into the compiler. (For example, whether we must deliver separate libraries for MT and non-MT programs.) We also need to get management buy-in for the increased scope of work. --- Steve Clamage, stephen.clamage@sun.com From gdamore@sun.com Sun Sep 7 08:20:58 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m87FKv3k015602 for ; Sun, 7 Sep 2008 08:20:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m87FKtaW006699 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 7 Sep 2008 16:20:56 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6T00505ZYWOP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 07 Sep 2008 08:20:56 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6T00ATRZYWSO50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 07 Sep 2008 08:20:56 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m87FKuju008450 for ; Sun, 07 Sep 2008 08:20:56 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6T00401ZXZ5U00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 07 Sep 2008 08:20:56 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6T00E4GZYVKXD0@fe-sfbay-10.sun.com>; Sun, 07 Sep 2008 08:20:55 -0700 (PDT) Date: Sun, 07 Sep 2008 08:19:58 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C2F674.5090805@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Stefan Teleman , John.Fischer@sun.com, PSARC-ext@sun.com, Steve Clamage Message-id: <48C3F11E.6050503@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C2F674.5090805@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2766 John Plocher wrote: > Stefan Teleman wrote: >> Steve Clamage and myself had reached an agreement on this, a couple >> of days ago: >> >> 1. We [ SFW/KDE ] were going to introduce this library in >> Nevada/OpenSolaris -- it's the easiest integration, and it's the one >> we care most about, because it can be done *now*. >> 2. They [ DevPro/Tools ] were going to introduce this library with >> the compiler(s), for Solaris 9/10, at some point in the future. I >> cannot say when that will be. >> >> Is this agreement still valid ? > > I hope so. Even if this case is derailed, derailing does not > invalidate anything. > > I would like to see in one place (i.e., NEED SPEC) the expected > transition/migration path (including who does what, where it will > live, and what names it will be known by) for the whole journey > from today (Sun shipping old/other stuff) to tomorrow (what this > case delivers) ending up at the day after (when the compiler team > delivers it). > > This is so we can validate the deployed app experience - will > things actually work while we do the transition? > > Most of this has been mentioned in this email thread, so I > do not think I'm asking for anything difficult. What *I* would like to see are two more things: 1) A simple assertion that programs built on the first day that the library is delivered will continue to work without a recompile after the transition is complete. (That will reduce all of my arguments about implementation to below the scope of architectural review, and allow any such breakages if they were to occur to be dealt with as P1 or P2 bugs.) 2) Some kind of plan outlining how we are going to wind up with a single Standard C++ library, and eliminate or reduce incompatibility of the kinds I mentioned (between libraries). This ultimately means that the Committee needs to bless this library as being the preferred base for building other C++ libraries (and as a corollary, it would probably preclude granting of any such blessing to any competing implementation.) One of the things I would expect to be dealt with here is a statement that if future evolution of the Standards (or other base technology) require a new version of the library, then there will be a necessary commitment to retain *two* implementations of the library, and all future middleware projects will need to deliver *two* libraries, so that we don't wind up with the situation with WhizzyDownloadTracker that I described earlier. It would not be unreasonable for this project to simply point out that the problem exists, and will need to be solved by whatever future case introduces a new Standard C++ library. If the above 2 items are resolved then I would likely vote to Approve. -- Garrett From Stefan.Teleman@sun.com Sun Sep 7 08:44:30 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m87FiTPM015759 for ; Sun, 7 Sep 2008 08:44:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m87FiPhK009365; Sun, 7 Sep 2008 23:44:27 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6U008031215Y00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 07 Sep 2008 08:44:25 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6U00AWO121SU60@nwk-avmta-1.sfbay.Sun.COM>; Sun, 07 Sep 2008 08:44:25 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m87FiOdI000633; Sun, 07 Sep 2008 08:44:24 -0700 (PDT) Date: Sun, 07 Sep 2008 11:44:21 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C3EF73.1090309@sun.com> To: Steve Clamage Cc: John.Fischer@sun.com, John Plocher , "Garrett D'Amore" , PSARC-ext@sun.com Reply-to: Stefan Teleman Message-id: <48C3F6D5.8050609@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 4846 Steve Clamage wrote: > On 9/6/2008 12:33 PM, Stefan Teleman wrote: >> Steve Clamage and myself had reached an agreement on this, a couple of >> days ago: >> >> 1. We [ SFW/KDE ] were going to introduce this library in >> Nevada/OpenSolaris -- it's the easiest integration, and it's the one we >> care most about, because it can be done *now*. >> 2. They [ DevPro/Tools ] were going to introduce this library with the >> compiler(s), for Solaris 9/10, at some point in the future. I cannot say >> when that will be. >> >> Is this agreement still valid ? Or has it been filibustered ? > > I don't remember agreeing to SFW/KDE introducing the library into > SNV/OpenSolaris, at least not in the form of the original proposal. Return-Path: Received: from dm-eng-01.sfbay.sun.com (dm-eng-01.SFBay.Sun.COM [129.145.155.198]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m84G6JtH022178 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 4 Sep 2008 09:06:19 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m84G6Jot001323 for ; Thu, 4 Sep 2008 09:06:19 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m84G6ED3008515 for ; Thu, 4 Sep 2008 09:06:14 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6O00C01HM0JY00@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for steleman@jurassic-x4600.eng.sun.com (ORCPT Stefan.Teleman@Sun.COM); Thu, 04 Sep 2008 09:06:14 -0700 (PDT) Received: from [129.146.86.208] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6O000HMI2905F0@fe-sfbay-09.sun.com> for steleman@jurassic-x4600.eng.sun.com (ORCPT Stefan.Teleman@Sun.COM); Thu, 04 Sep 2008 09:06:09 -0700 (PDT) Date: Thu, 04 Sep 2008 09:06:09 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C002D6.8070607@Sun.COM> Sender: Stephen.Clamage@Sun.COM To: Stefan Teleman Cc: John.Fischer@Sun.COM, Garrett.Damore@Sun.COM, Mukesh Kapoor Message-id: <48C00771.3020108@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1219697434.9503.162.camel@sr1-umpk-16> <48B32BE5.7030506@sun.com> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> <48B48963.30600@Sun.COM> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> <48B4E6DB.1040207@Sun.Com> <48BED9A9.4030306@Sun.Com> <48BEDE7B.3070606@sun.com> <48BEE796.2050402@Sun.COM> <48BEEDBF.7090201@sun.com> <48BF1A80.6080700@sun.com> <48BF2650.2060200@Sun.COM> <48BFFAC7.9060204@sun.com> <1220542021.19370.12.camel@sr1-umpk-16> <48C002D6.8070607@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) [ ... ] > Now I understand how you got to where you are with this ARC case, and I > think we may at last be on the same page. > > John Fischer suggested that the project could deliver libstdcxx.so into > /usr/lib, until the compiler team is able to do it. > > How about this: a separate package SUNWstdcxx (are 10 letters allowed in > a package name?) consisting of just the appropriate versions of > libstdcxx.so. Your project delivers the package until the compiler team > is ready, then responsibility for the package transfers to the compiler > team. That way we don't have issues with the contents of package X > transferred to package Y. I understood the last paragraph to mean what i had stated in my earlier email. --Stefan ----- On 09/04/08 08:46, Stefan Teleman wrote: > > My team and I are looking into the technical issues involved in > delivering the library seamlessly integrated into the compiler. (For > example, whether we must deliver separate libraries for MT and non-MT > programs.) We also need to get management buy-in for the increased scope > of work. > > --- > Steve Clamage, stephen.clamage@sun.com > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Stephen.Clamage@sun.com Sun Sep 7 08:49:45 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m87Fni4C015773 for ; Sun, 7 Sep 2008 08:49:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m87FneJV013773 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sun, 7 Sep 2008 16:49:43 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6U008031ATSJ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 07 Sep 2008 08:49:41 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6U00A4H1ATSU70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 07 Sep 2008 08:49:41 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m87FnfRb008719 for ; Sun, 07 Sep 2008 08:49:41 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6U0020118AOU00@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sun, 07 Sep 2008 08:49:41 -0700 (PDT) Received: from [10.0.0.5] ([68.126.182.43]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6U00DVU1ASWDC0@fe-sfbay-09.sun.com>; Sun, 07 Sep 2008 08:49:41 -0700 (PDT) Date: Sun, 07 Sep 2008 08:49:39 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C3F6D5.8050609@Sun.COM> Sender: Stephen.Clamage@sun.com To: Stefan Teleman Cc: John.Fischer@sun.com, John Plocher , "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <48C3F813.2030006@sun.com> Organization: Sun Microsystems, Inc MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 5190 Other issues have come to light since I wrote that email. What about the the headers for the Apache library? What about Solaris 10? --- Steve Clamage, stephen.clamage@sun.com On 9/7/2008 8:44 AM, Stefan Teleman wrote: > > > Steve Clamage wrote: >> On 9/6/2008 12:33 PM, Stefan Teleman wrote: >>> Steve Clamage and myself had reached an agreement on this, a couple >>> of days ago: >>> >>> 1. We [ SFW/KDE ] were going to introduce this library in >>> Nevada/OpenSolaris -- it's the easiest integration, and it's the one >>> we care most about, because it can be done *now*. >>> 2. They [ DevPro/Tools ] were going to introduce this library with >>> the compiler(s), for Solaris 9/10, at some point in the future. I >>> cannot say when that will be. >>> >>> Is this agreement still valid ? Or has it been filibustered ? >> >> I don't remember agreeing to SFW/KDE introducing the library into >> SNV/OpenSolaris, at least not in the form of the original proposal. > > > Return-Path: > Received: from dm-eng-01.sfbay.sun.com (dm-eng-01.SFBay.Sun.COM > [129.145.155.198]) > by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP > id m84G6JtH022178 > (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 > verify=NO) > for ; Thu, 4 Sep 2008 > 09:06:19 -0700 (PDT) > Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM > [192.18.43.133]) > by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with > ESMTP id m84G6Jot001323 > for ; Thu, 4 Sep 2008 > 09:06:19 -0700 (PDT) > Received: from fe-sfbay-09.sun.com ([192.18.43.129]) > by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id > m84G6ED3008515 > for ; Thu, 4 Sep 2008 > 09:06:14 -0700 (PDT) > Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com > (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) > id <0K6O00C01HM0JY00@fe-sfbay-09.sun.com> > (original mail from Stephen.Clamage@Sun.COM) > for steleman@jurassic-x4600.eng.sun.com (ORCPT Stefan.Teleman@Sun.COM); > Thu, > 04 Sep 2008 09:06:14 -0700 (PDT) > Received: from [129.146.86.208] by fe-sfbay-09.sun.com > (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) > with ESMTPSA id <0K6O000HMI2905F0@fe-sfbay-09.sun.com> for > steleman@jurassic-x4600.eng.sun.com (ORCPT Stefan.Teleman@Sun.COM); Thu, > 04 Sep 2008 09:06:09 -0700 (PDT) > Date: Thu, 04 Sep 2008 09:06:09 -0700 > From: Steve Clamage > Subject: Re: PSARC/2008/549 - Apache Standard C++ Library > In-reply-to: <48C002D6.8070607@Sun.COM> > Sender: Stephen.Clamage@Sun.COM > To: Stefan Teleman > Cc: John.Fischer@Sun.COM, Garrett.Damore@Sun.COM, > Mukesh Kapoor > Message-id: <48C00771.3020108@sun.com> > Organization: Sun Microsystems, Inc. > MIME-version: 1.0 > Content-type: text/plain; format=flowed; charset=ISO-8859-1 > Content-transfer-encoding: 7BIT > References: <1219697434.9503.162.camel@sr1-umpk-16> > <48B32BE5.7030506@sun.com> > <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> > <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> > <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> > <48B48963.30600@Sun.COM> > <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> > <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> > <48B4E6DB.1040207@Sun.Com> <48BED9A9.4030306@Sun.Com> > <48BEDE7B.3070606@sun.com> <48BEE796.2050402@Sun.COM> > <48BEEDBF.7090201@sun.com> <48BF1A80.6080700@sun.com> > <48BF2650.2060200@Sun.COM> <48BFFAC7.9060204@sun.com> > <1220542021.19370.12.camel@sr1-umpk-16> <48C002D6.8070607@Sun.COM> > User-Agent: Thunderbird 2.0.0.16 (X11/20080807) > > > [ ... ] > > > Now I understand how you got to where you are with this ARC case, and I > > think we may at last be on the same page. > > > > John Fischer suggested that the project could deliver libstdcxx.so into > > /usr/lib, until the compiler team is able to do it. > > > > How about this: a separate package SUNWstdcxx (are 10 letters allowed in > > a package name?) consisting of just the appropriate versions of > > libstdcxx.so. Your project delivers the package until the compiler team > > is ready, then responsibility for the package transfers to the compiler > > team. That way we don't have issues with the contents of package X > > transferred to package Y. > > I understood the last paragraph to mean what i had stated in my earlier > email. > > --Stefan > > ----- > > On 09/04/08 08:46, Stefan Teleman wrote: > > >> >> My team and I are looking into the technical issues involved in >> delivering the library seamlessly integrated into the compiler. (For >> example, whether we must deliver separate libraries for MT and non-MT >> programs.) We also need to get management buy-in for the increased >> scope of work. >> >> --- >> Steve Clamage, stephen.clamage@sun.com >> _______________________________________________ >> opensolaris-arc mailing list >> opensolaris-arc@opensolaris.org > From Stefan.Teleman@sun.com Sun Sep 7 08:56:23 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m87FuMm6016062 for ; Sun, 7 Sep 2008 08:56:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m87FuIHF015669; Sun, 7 Sep 2008 16:56:20 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6U004031LUBG00@brm-avmta-1.central.sun.com>; Sun, 07 Sep 2008 09:56:18 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6U00HX01LUEV70@brm-avmta-1.central.sun.com>; Sun, 07 Sep 2008 09:56:18 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m87FuH6a001612; Sun, 07 Sep 2008 08:56:17 -0700 (PDT) Date: Sun, 07 Sep 2008 11:56:16 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C3F813.2030006@sun.com> To: Steve Clamage Cc: John.Fischer@sun.com, John Plocher , "Garrett D'Amore" , PSARC-ext@sun.com Reply-to: Stefan Teleman Message-id: <48C3F9A0.7020808@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 5892 Steve Clamage wrote: > Other issues have come to light since I wrote that email. > > What about the the headers for the Apache library? What about Solaris 10? The headers must be included with the library. Otherwise the integration is completely useless. It is up to the Compiler Team whether or not this should be integrated in Solaris 10 as well. If you would like us to do it, under the exact same terms (i.e. transition to the compiler team when you are ready to provide it with the Studio compilers), we will gladly do so. --Stefan ----- > > --- > Steve Clamage, stephen.clamage@sun.com > > On 9/7/2008 8:44 AM, Stefan Teleman wrote: >> >> Steve Clamage wrote: >>> On 9/6/2008 12:33 PM, Stefan Teleman wrote: >>>> Steve Clamage and myself had reached an agreement on this, a couple >>>> of days ago: >>>> >>>> 1. We [ SFW/KDE ] were going to introduce this library in >>>> Nevada/OpenSolaris -- it's the easiest integration, and it's the one >>>> we care most about, because it can be done *now*. >>>> 2. They [ DevPro/Tools ] were going to introduce this library with >>>> the compiler(s), for Solaris 9/10, at some point in the future. I >>>> cannot say when that will be. >>>> >>>> Is this agreement still valid ? Or has it been filibustered ? >>> I don't remember agreeing to SFW/KDE introducing the library into >>> SNV/OpenSolaris, at least not in the form of the original proposal. >> >> Return-Path: >> Received: from dm-eng-01.sfbay.sun.com (dm-eng-01.SFBay.Sun.COM >> [129.145.155.198]) >> by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP >> id m84G6JtH022178 >> (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 >> verify=NO) >> for ; Thu, 4 Sep 2008 >> 09:06:19 -0700 (PDT) >> Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM >> [192.18.43.133]) >> by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with >> ESMTP id m84G6Jot001323 >> for ; Thu, 4 Sep 2008 >> 09:06:19 -0700 (PDT) >> Received: from fe-sfbay-09.sun.com ([192.18.43.129]) >> by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id >> m84G6ED3008515 >> for ; Thu, 4 Sep 2008 >> 09:06:14 -0700 (PDT) >> Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com >> (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) >> id <0K6O00C01HM0JY00@fe-sfbay-09.sun.com> >> (original mail from Stephen.Clamage@Sun.COM) >> for steleman@jurassic-x4600.eng.sun.com (ORCPT Stefan.Teleman@Sun.COM); >> Thu, >> 04 Sep 2008 09:06:14 -0700 (PDT) >> Received: from [129.146.86.208] by fe-sfbay-09.sun.com >> (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) >> with ESMTPSA id <0K6O000HMI2905F0@fe-sfbay-09.sun.com> for >> steleman@jurassic-x4600.eng.sun.com (ORCPT Stefan.Teleman@Sun.COM); Thu, >> 04 Sep 2008 09:06:09 -0700 (PDT) >> Date: Thu, 04 Sep 2008 09:06:09 -0700 >> From: Steve Clamage >> Subject: Re: PSARC/2008/549 - Apache Standard C++ Library >> In-reply-to: <48C002D6.8070607@Sun.COM> >> Sender: Stephen.Clamage@Sun.COM >> To: Stefan Teleman >> Cc: John.Fischer@Sun.COM, Garrett.Damore@Sun.COM, >> Mukesh Kapoor >> Message-id: <48C00771.3020108@sun.com> >> Organization: Sun Microsystems, Inc. >> MIME-version: 1.0 >> Content-type: text/plain; format=flowed; charset=ISO-8859-1 >> Content-transfer-encoding: 7BIT >> References: <1219697434.9503.162.camel@sr1-umpk-16> >> <48B32BE5.7030506@sun.com> >> <48B33D48.5090202@Sun.COM> <48B4362C.7070604@sun.com> >> <48B458DA.5050700@Sun.COM> <48B47579.4070609@sun.com> >> <48B479EC.8070204@Sun.COM> <48B48070.2000407@Sun.Com> >> <48B48963.30600@Sun.COM> >> <48B48E59.2000807@sun.com> <48B4C3F7.5030003@Sun.COM> >> <48B4CCCA.7030002@Sun.Com> <48B4DE3B.8040608@sun.com> >> <48B4E6DB.1040207@Sun.Com> <48BED9A9.4030306@Sun.Com> >> <48BEDE7B.3070606@sun.com> <48BEE796.2050402@Sun.COM> >> <48BEEDBF.7090201@sun.com> <48BF1A80.6080700@sun.com> >> <48BF2650.2060200@Sun.COM> <48BFFAC7.9060204@sun.com> >> <1220542021.19370.12.camel@sr1-umpk-16> <48C002D6.8070607@Sun.COM> >> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) >> >> >> [ ... ] >> >> > Now I understand how you got to where you are with this ARC case, and I >> > think we may at last be on the same page. >> > >> > John Fischer suggested that the project could deliver libstdcxx.so into >> > /usr/lib, until the compiler team is able to do it. >> > >> > How about this: a separate package SUNWstdcxx (are 10 letters allowed in >> > a package name?) consisting of just the appropriate versions of >> > libstdcxx.so. Your project delivers the package until the compiler team >> > is ready, then responsibility for the package transfers to the compiler >> > team. That way we don't have issues with the contents of package X >> > transferred to package Y. >> >> I understood the last paragraph to mean what i had stated in my earlier >> email. >> >> --Stefan >> >> ----- >> >> On 09/04/08 08:46, Stefan Teleman wrote: >> >> >>> My team and I are looking into the technical issues involved in >>> delivering the library seamlessly integrated into the compiler. (For >>> example, whether we must deliver separate libraries for MT and non-MT >>> programs.) We also need to get management buy-in for the increased >>> scope of work. >>> >>> --- >>> Steve Clamage, stephen.clamage@sun.com >>> _______________________________________________ >>> opensolaris-arc mailing list >>> opensolaris-arc@opensolaris.org > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Stephen.Clamage@Sun.COM Mon Sep 8 14:20:55 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m88LKtUE003763 for ; Mon, 8 Sep 2008 14:20:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m88LKsbw002643 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 8 Sep 2008 14:20:54 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6W00503BATEZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 08 Sep 2008 14:20:53 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6W0042CBATU010@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 08 Sep 2008 14:20:53 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m88LKqra024511 for ; Mon, 08 Sep 2008 14:20:52 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6W00D01B5OWI00@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 08 Sep 2008 14:20:52 -0700 (PDT) Received: from [129.150.17.59] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6W00BVMBAPBHF0@fe-sfbay-09.sun.com>; Mon, 08 Sep 2008 14:20:49 -0700 (PDT) Date: Mon, 08 Sep 2008 14:20:48 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C3F9A0.7020808@Sun.COM> Sender: Stephen.Clamage@Sun.COM To: Stefan Teleman Cc: John.Fischer@Sun.COM, John Plocher , "Garrett D'Amore" , PSARC-ext@Sun.COM Message-id: <48C59730.7050809@sun.com> Organization: Sun Microsystems, Inc MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 2434 I've been going over with my team the various implications of supporting a Solaris version of Apache libcstdcxx, whether it is delivered by a Solaris consolidation or by the compiler group. Let's suppose we go the route suggested by Stefan, where he delivers the headers into /usr/include/... and the runtime libraries into /usr/lib. The feature would not be available on Solaris 9 or earlier. We have precedent for such a limitation: full C99 conformance is similarly not available. But I don't think restricting the availability to SNV/OpenSolaris is acceptable. Currently, full Sun support (e.g. for enterprise customers) is available only for Solaris 10. A plan to provide support for OpenSolaris is being discussed, but nobody yet knows what form that will take. Will you undertake to deliver Apache libstdcxx into a Solaris 10 patch and update? It might be possible to deliver a single version of the runtime library (per platform) compiled with -mt to be used by both MT and non-MT programs, but it would have performance implications for single-threaded programs. We think a better solution would be to have two libraries, to ensure no conflict between MT and non-MT code, and to eliminate gratuitous performance loss in single-threaded code. (In MT code, the library must lock critical regions of an object during manipulation by library functions.) Will you undertake to deliver both single- and multi-threaded library versions? As discussed earlier, for SPARC, only v8plus (sparcvis) or better will be supported, so we eliminate the need to provide different versions for v8. The compiler team would like to consult with you on the best way (compiler options, etc) to build the libraries, and on the library configuration parameters. Subject to agreement on these points, I have no objections to a Solaris consolidation taking responsibility for delivery and maintenance of libcstdcxx as a Solaris component. The compiler group will add an option to CC, presumably -library=stdcxx that will take care of disabling use of the default libCstd, and adding -I, -L, and -l options to pick up the appropriate version of libstdcxx. We have already discussed maintaining binary compatibility, which will be done via the usual mechanism of external and internal library versioning. There are probably few minor technical details to be ironed out. --- Steve Clamage, stephen.clamage@sun.com From Stefan.Teleman@sun.com Mon Sep 8 14:32:51 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m88LWpub004192 for ; Mon, 8 Sep 2008 14:32:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m88LWno1005996; Mon, 8 Sep 2008 14:32:50 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6W00M01BUQ8300@brm-avmta-1.central.sun.com>; Mon, 08 Sep 2008 15:32:50 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6W0031DBUPJRE0@brm-avmta-1.central.sun.com>; Mon, 08 Sep 2008 15:32:49 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m88LWUn9014680; Mon, 08 Sep 2008 14:32:36 -0700 (PDT) Date: Mon, 08 Sep 2008 17:32:30 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C59730.7050809@sun.com> To: Steve Clamage Cc: John.Fischer@sun.com, John Plocher , "Garrett D'Amore" , PSARC-ext@sun.com Reply-to: Stefan Teleman Message-id: <48C599EE.9010304@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200809041740.m84HevPa017899@sac.sfbay.sun.com> <20080904180133.GX1524@Sun.COM> <48C02885.30709@sun.com> <48C02DAF.1090302@sun.com> <20080904185648.GE1524@Sun.COM> <48C031FE.2000508@Sun.Com> <48C032A3.3070509@sun.com> <48C03393.5040203@Sun.COM> <48C03AFF.7060103@sun.com> <48C0447B.2050002@Sun.Com> <48C04F52.9050005@sun.com> <48C05424.9000205@Sun.COM> <48C05FC2.7040303@sun.com> <48C075FF.6060608@Sun.COM> <48C0B9E4.8070803@sun.com> <48C0BF33.2080407@Sun.COM> <48C1704B.7000709@sun.com> <48C17298.3020706@sun.com> <48C17578.4040704@Sun.Com> <48C18114.9020604@sun.com> <48C1B458.2020301@Sun.COM> <48C1C4E0.7090300@sun.com> <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 3576 Hi. My answers here: 1. Yes, if the Compiler Team is ok with it, we can deliver the Apache Library in both Nevada/OpenSolaris, and in a S10 proper Update. The likely candidate for S10, right now, looks like S10U7. 2. If it is a must-have (determined by performance tests of single-threaded programs compiled and linked against the multi-threaded Apache Library), then yes, we can deliver both single threaded and multi-threaded library. 3. Building for v8plus on SPARC is great. 4. Yes, consultation and consensus with the Compiler Team is, in my mind, a requirement for this project. 5. Any other minor details we can work out through emails and/or con-calls. 6. Further updates to the library (depending on the Apache core developers' release schedule, and on features introduced in future releases), should also only be made in consultation with the Compiler Team. Please let me know if i missed something. --Stefan ----- Steve Clamage wrote: > I've been going over with my team the various implications of supporting > a Solaris version of Apache libcstdcxx, whether it is delivered by a > Solaris consolidation or by the compiler group. > > Let's suppose we go the route suggested by Stefan, where he delivers the > headers into /usr/include/... and the runtime libraries into /usr/lib. > > The feature would not be available on Solaris 9 or earlier. We have > precedent for such a limitation: full C99 conformance is similarly not > available. But I don't think restricting the availability to > SNV/OpenSolaris is acceptable. Currently, full Sun support (e.g. for > enterprise customers) is available only for Solaris 10. A plan to > provide support for OpenSolaris is being discussed, but nobody yet knows > what form that will take. > > Will you undertake to deliver Apache libstdcxx into a Solaris 10 patch > and update? > > It might be possible to deliver a single version of the runtime library > (per platform) compiled with -mt to be used by both MT and non-MT > programs, but it would have performance implications for single-threaded > programs. We think a better solution would be to have two libraries, to > ensure no conflict between MT and non-MT code, and to eliminate > gratuitous performance loss in single-threaded code. (In MT code, the > library must lock critical regions of an object during manipulation by > library functions.) > > Will you undertake to deliver both single- and multi-threaded library > versions? > > As discussed earlier, for SPARC, only v8plus (sparcvis) or better will > be supported, so we eliminate the need to provide different versions for > v8. > > The compiler team would like to consult with you on the best way > (compiler options, etc) to build the libraries, and on the library > configuration parameters. > > Subject to agreement on these points, I have no objections to a Solaris > consolidation taking responsibility for delivery and maintenance of > libcstdcxx as a Solaris component. > > The compiler group will add an option to CC, presumably > -library=stdcxx > that will take care of disabling use of the default libCstd, and adding > -I, -L, and -l options to pick up the appropriate version of libstdcxx. > > We have already discussed maintaining binary compatibility, which will > be done via the usual mechanism of external and internal library > versioning. > > There are probably few minor technical details to be ironed out. > > --- > Steve Clamage, stephen.clamage@sun.com -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Nicolas.Williams@Sun.COM Mon Sep 8 14:36:06 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m88La64H004383 for ; Mon, 8 Sep 2008 14:36:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m88LZu2t028683; Mon, 8 Sep 2008 14:36:06 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6W00M25C05JN00@brm-avmta-1.central.sun.com>; Mon, 08 Sep 2008 15:36:05 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6W003A7C04JXD0@brm-avmta-1.central.sun.com>; Mon, 08 Sep 2008 15:36:04 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m88La4Xf005359; Mon, 08 Sep 2008 16:36:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m88La4Q8005358; Mon, 08 Sep 2008 16:36:04 -0500 (CDT) Date: Mon, 08 Sep 2008 16:36:04 -0500 From: Nicolas Williams Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C59730.7050809@sun.com> To: Steve Clamage Cc: Stefan Teleman , John.Fischer@Sun.COM, John Plocher , "Garrett D'Amore" , PSARC-ext@Sun.COM Message-id: <20080908213603.GF1524@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1178 On Mon, Sep 08, 2008 at 02:20:48PM -0700, Steve Clamage wrote: > The feature would not be available on Solaris 9 or earlier. We have > precedent for such a limitation: full C99 conformance is similarly not > available. But I don't think restricting the availability to > SNV/OpenSolaris is acceptable. Currently, full Sun support (e.g. for Why not? Plenty of things are in Solaris Nevada / OpenSolaris that will not be backported to Solaris 10. Whether to backport is a business issue, not an ARC issue. > [...] > > It might be possible to deliver a single version of the runtime library > (per platform) compiled with -mt to be used by both MT and non-MT > programs, but it would have performance implications for single-threaded > programs. We think a better solution would be to have two libraries, to > ensure no conflict between MT and non-MT code, and to eliminate > gratuitous performance loss in single-threaded code. (In MT code, the > library must lock critical regions of an object during manipulation by > library functions.) Solaris 10 and up have a unified process model. Why should C++ on Solaris not have a unified process model too? Nico -- From Stephen.Clamage@Sun.COM Mon Sep 8 15:05:27 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m88M5Qc7005453 for ; Mon, 8 Sep 2008 15:05:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m88M5QbC005416 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 8 Sep 2008 16:05:26 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6W0071VDD1AS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 08 Sep 2008 15:05:25 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6W004PVDD0U440@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 08 Sep 2008 15:05:24 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m88M5Oh5010822 for ; Mon, 08 Sep 2008 15:05:24 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6W00A01D5Y7V00@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 08 Sep 2008 15:05:24 -0700 (PDT) Received: from [129.150.17.59] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6W00960DCZ3E20@fe-sfbay-09.sun.com>; Mon, 08 Sep 2008 15:05:23 -0700 (PDT) Date: Mon, 08 Sep 2008 15:05:22 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <20080908213603.GF1524@Sun.COM> Sender: Stephen.Clamage@Sun.COM To: Nicolas Williams Cc: Stefan Teleman , John.Fischer@Sun.COM, John Plocher , "Garrett D'Amore" , PSARC-ext@Sun.COM Message-id: <48C5A1A2.5010403@sun.com> Organization: Sun Microsystems, Inc MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C1D070.7090609@Sun.COM> <48C1FC5E.5050205@sun.com> <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 2281 On 9/8/2008 2:36 PM, Nicolas Williams wrote: > On Mon, Sep 08, 2008 at 02:20:48PM -0700, Steve Clamage wrote: >> The feature would not be available on Solaris 9 or earlier. We have >> precedent for such a limitation: full C99 conformance is similarly not >> available. But I don't think restricting the availability to >> SNV/OpenSolaris is acceptable. Currently, full Sun support (e.g. for > > Why not? Plenty of things are in Solaris Nevada / OpenSolaris that will > not be backported to Solaris 10. Whether to backport is a business > issue, not an ARC issue. Yes, it's a business issue. But much of the discussion has been about whether a Solaris consolidation or the compiler team should be responsible for delivering what are, after all, components that can be used only with the Sun C++ compiler. I want to be sure the needs of the the software tools organization are met. > >> [...] >> >> It might be possible to deliver a single version of the runtime library >> (per platform) compiled with -mt to be used by both MT and non-MT >> programs, but it would have performance implications for single-threaded >> programs. We think a better solution would be to have two libraries, to >> ensure no conflict between MT and non-MT code, and to eliminate >> gratuitous performance loss in single-threaded code. (In MT code, the >> library must lock critical regions of an object during manipulation by >> library functions.) > > Solaris 10 and up have a unified process model. Why should C++ on > Solaris not have a unified process model too? As I noted in the part that you quote, library data structures have critical regions that must be locked if manipulating functions are called by multiple threads. The other two libraries that we ship have the locking calls controlled by macros in the headers visible to user code. When compiled without -mt (-D_REENTRANT), these macros turn into no-ops. The design of libstdcxx buries these locks in the internals of the functions inside the library. If you have only an MT library, single-threaded programs pay the cost of these unneeded locks. I agree with Stefan that we need to do some measurements to see whether the performance difference is important. --- Steve Clamage, stephen.clamage@sun.com From Nicolas.Williams@sun.com Mon Sep 8 15:31:09 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m88MV8gI006579 for ; Mon, 8 Sep 2008 15:31:08 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m88MUxZG012874; Tue, 9 Sep 2008 06:31:03 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6W00307EJPEX00@brm-avmta-1.central.sun.com>; Mon, 08 Sep 2008 16:31:01 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6W0012GEJOL610@brm-avmta-1.central.sun.com>; Mon, 08 Sep 2008 16:31:00 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m88MV0pV005464; Mon, 08 Sep 2008 17:31:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m88MV0aj005463; Mon, 08 Sep 2008 17:31:00 -0500 (CDT) Date: Mon, 08 Sep 2008 17:31:00 -0500 From: Nicolas Williams Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C5A1A2.5010403@sun.com> To: Steve Clamage Cc: Stefan Teleman , John.Fischer@sun.com, John Plocher , "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <20080908223059.GH1524@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1962 On Mon, Sep 08, 2008 at 03:05:22PM -0700, Steve Clamage wrote: > On 9/8/2008 2:36 PM, Nicolas Williams wrote: > >Why not? Plenty of things are in Solaris Nevada / OpenSolaris that will > >not be backported to Solaris 10. Whether to backport is a business > >issue, not an ARC issue. > > Yes, it's a business issue. But much of the discussion has been about > whether a Solaris consolidation or the compiler team should be > responsible for delivering what are, after all, components that can be > used only with the Sun C++ compiler. I want to be sure the needs of the > the software tools organization are met. I thought that getting the Sun Studio team involved was all about making sure that you had no architectural objections, and that whatever such bjections you had were ironed out. > >Solaris 10 and up have a unified process model. Why should C++ on > >Solaris not have a unified process model too? > > As I noted in the part that you quote, library data structures have > critical regions that must be locked if manipulating functions are > called by multiple threads. I understood that. The same is true of many C libraries in Solaris. > The other two libraries that we ship have the locking calls controlled > by macros in the headers visible to user code. When compiled without -mt > (-D_REENTRANT), these macros turn into no-ops. > > The design of libstdcxx buries these locks in the internals of the > functions inside the library. If you have only an MT library, > single-threaded programs pay the cost of these unneeded locks. > > I agree with Stefan that we need to do some measurements to see whether > the performance difference is important. But it's also important to consider whether the common uses are in MT or single-threaded programs. Why even bother measuring the cost for single-threaded programs if they are not the target, or if no consequential single-threaded programs exist that might use this library? From Stephen.Clamage@sun.com Mon Sep 8 15:42:15 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m88MgE6p007743 for ; Mon, 8 Sep 2008 15:42:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m88Mfwnw019162 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 8 Sep 2008 23:42:13 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6W00403F2C8400@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 08 Sep 2008 16:42:12 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6W00174F2BL510@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 08 Sep 2008 16:42:11 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m88MgBNp015183 for ; Mon, 08 Sep 2008 15:42:11 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6W00701EMQ2G00@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 08 Sep 2008 15:42:11 -0700 (PDT) Received: from [129.150.17.59] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6W00HXVF28HZ00@fe-sfbay-09.sun.com>; Mon, 08 Sep 2008 15:42:09 -0700 (PDT) Date: Mon, 08 Sep 2008 15:42:07 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <20080908223059.GH1524@Sun.COM> Sender: Stephen.Clamage@sun.com To: Nicolas Williams Cc: Stefan Teleman , John.Fischer@sun.com, John Plocher , "Garrett D'Amore" , psarc-ext@sun.com Message-id: <48C5AA3F.1010501@sun.com> Organization: Sun Microsystems, Inc MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) Status: RO Content-Length: 2106 On 9/8/2008 3:31 PM, Nicolas Williams wrote: > On Mon, Sep 08, 2008 at 03:05:22PM -0700, Steve Clamage wrote: >> On 9/8/2008 2:36 PM, Nicolas Williams wrote: >>> Why not? Plenty of things are in Solaris Nevada / OpenSolaris that will >>> not be backported to Solaris 10. Whether to backport is a business >>> issue, not an ARC issue. >> Yes, it's a business issue. But much of the discussion has been about >> whether a Solaris consolidation or the compiler team should be >> responsible for delivering what are, after all, components that can be >> used only with the Sun C++ compiler. I want to be sure the needs of the >> the software tools organization are met. > > I thought that getting the Sun Studio team involved was all about making > sure that you had no architectural objections, and that whatever such > bjections you had were ironed out. > >>> Solaris 10 and up have a unified process model. Why should C++ on >>> Solaris not have a unified process model too? >> As I noted in the part that you quote, library data structures have >> critical regions that must be locked if manipulating functions are >> called by multiple threads. > > I understood that. The same is true of many C libraries in Solaris. > >> The other two libraries that we ship have the locking calls controlled >> by macros in the headers visible to user code. When compiled without -mt >> (-D_REENTRANT), these macros turn into no-ops. >> >> The design of libstdcxx buries these locks in the internals of the >> functions inside the library. If you have only an MT library, >> single-threaded programs pay the cost of these unneeded locks. >> >> I agree with Stefan that we need to do some measurements to see whether >> the performance difference is important. > > But it's also important to consider whether the common uses are in MT or > single-threaded programs. Why even bother measuring the cost for > single-threaded programs if they are not the target, or if no > consequential single-threaded programs exist that might use this > library? SPEC. --- Steve Clamage, stephen.clamage@sun.com From Darren.Moffat@sun.com Tue Sep 9 02:35:09 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m899Z9Z7026457 for ; Tue, 9 Sep 2008 02:35:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m899Z8K1006713 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 9 Sep 2008 02:35:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6X00I0N9AJWQ00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 02:35:07 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6X0040T9AJGPC0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 02:35:07 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m899Z63U013776 for ; Tue, 09 Sep 2008 09:35:06 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6X0000186ZSZ00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 10:35:06 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6X00KYX9AE2K50@fe-emea-09.sun.com>; Tue, 09 Sep 2008 10:35:03 +0100 (BST) Date: Tue, 09 Sep 2008 10:35:02 +0100 From: Darren J Moffat Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <20080908223059.GH1524@Sun.COM> Sender: Darren.Moffat@sun.com To: Nicolas Williams Cc: Steve Clamage , John.Fischer@sun.com, John Plocher , "Garrett D'Amore" , Stefan Teleman , psarc-ext@sun.com Message-id: <48C64346.6080408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080811) Status: RO Content-Length: 1076 Nicolas Williams wrote: > But it's also important to consider whether the common uses are in MT or > single-threaded programs. Why even bother measuring the cost for > single-threaded programs if they are not the target, or if no > consequential single-threaded programs exist that might use this > library? There is not such thing as a non MT program post Solaris 10. All processes potentially have more than one thread. Please do not attempt to regress the huge amount of work that went into unifying the process model for Solaris 10 by providing confusing by shipping multiple libraries. This is not about measurements it is about the architecture of reference and for Solaris 10 onwards it is an always MT world and as a resut of that libraries are now free to create threads as part of their implementation even if those threads aren't exposed to the original application. For this to be possible there can be only one acceptable version of a library and that is the MT one - even for an application that thinks it is single threaded. -- Darren J Moffat From Darren.Moffat@sun.com Tue Sep 9 02:36:02 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m899a2jE026469 for ; Tue, 9 Sep 2008 02:36:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m899a1Zf045881 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 9 Sep 2008 03:36:02 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6X0090J9BZGN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 09 Sep 2008 03:35:59 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6X00E6K9BW9RD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 09 Sep 2008 03:35:57 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m899ZuQC029217 for ; Tue, 09 Sep 2008 09:35:56 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6X0000186ZSZ00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 09 Sep 2008 10:35:56 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6X00K0F9BM2K60@fe-emea-09.sun.com>; Tue, 09 Sep 2008 10:35:47 +0100 (BST) Date: Tue, 09 Sep 2008 10:35:46 +0100 From: Darren J Moffat Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C5AA3F.1010501@sun.com> Sender: Darren.Moffat@sun.com To: Steve Clamage Cc: Nicolas Williams , John.Fischer@sun.com, John Plocher , "Garrett D'Amore" , Stefan Teleman , psarc-ext@sun.com Message-id: <48C64372.2020109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> <48C5AA3F.1010501@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080811) Status: RO Content-Length: 488 Steve Clamage wrote: >>> I agree with Stefan that we need to do some measurements to see whether >>> the performance difference is important. >> But it's also important to consider whether the common uses are in MT or >> single-threaded programs. Why even bother measuring the cost for >> single-threaded programs if they are not the target, or if no >> consequential single-threaded programs exist that might use this >> library? > > SPEC. What does that mean ? -- Darren J Moffat From Stephen.Clamage@sun.com Tue Sep 9 08:00:45 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m89F0jX6004351 for ; Tue, 9 Sep 2008 08:00:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m89F0huu008216 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 9 Sep 2008 08:00:44 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6X00115OD82L00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 08:00:44 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6X000NWOD7NF00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 08:00:43 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m89F0hZf026429 for ; Tue, 09 Sep 2008 08:00:43 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6X00101KKK2N00@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 08:00:43 -0700 (PDT) Received: from [129.146.86.208] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6X00LYSOD1EPE0@fe-sfbay-09.sun.com>; Tue, 09 Sep 2008 08:00:38 -0700 (PDT) Date: Tue, 09 Sep 2008 08:00:37 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C64372.2020109@Sun.COM> Sender: Stephen.Clamage@sun.com To: Darren J Moffat Cc: Nicolas Williams , John.Fischer@sun.com, John Plocher , "Garrett D'Amore" , Stefan Teleman , psarc-ext@sun.com Message-id: <48C68F95.5000701@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> <48C5AA3F.1010501@sun.com> <48C64372.2020109@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 801 On 09/09/08 02:35, Darren J Moffat wrote: > Steve Clamage wrote: >>>> I agree with Stefan that we need to do some measurements to see >>>> whether the performance difference is important. >>> But it's also important to consider whether the common uses are in MT or >>> single-threaded programs. Why even bother measuring the cost for >>> single-threaded programs if they are not the target, or if no >>> consequential single-threaded programs exist that might use this >>> library? >> >> SPEC. > > What does that mean ? Standard Performance Evaluation Corporation http://www.spec.org/ Sun, especially the software division, lives and dies by SPEC performance measurements. Artificially reducing performance has consequences for the entire company. --- Steve Clamage, stephen.clamage@sun.com From gdamore@sun.com Tue Sep 9 08:13:42 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m89FDg3w005153 for ; Tue, 9 Sep 2008 08:13:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m89FDZtw023126 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 9 Sep 2008 09:13:42 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6X00209OYTA700@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 08:13:41 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6X000ZQOYTND20@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 08:13:41 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m89FDf2J009348 for ; Tue, 09 Sep 2008 08:13:41 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6X00201OF29V00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 08:13:41 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6X007FCOYR6340@fe-sfbay-09.sun.com>; Tue, 09 Sep 2008 08:13:40 -0700 (PDT) Date: Tue, 09 Sep 2008 08:12:34 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C68F95.5000701@sun.com> Sender: Garrett.Damore@sun.com To: Steve Clamage Cc: Darren J Moffat , Nicolas Williams , John.Fischer@sun.com, John Plocher , Stefan Teleman , psarc-ext@sun.com Message-id: <48C69262.50103@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> <48C5AA3F.1010501@sun.com> <48C64372.2020109@Sun.COM> <48C68F95.5000701@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1423 Steve Clamage wrote: > > > On 09/09/08 02:35, Darren J Moffat wrote: >> Steve Clamage wrote: >>>>> I agree with Stefan that we need to do some measurements to see >>>>> whether the performance difference is important. >>>> But it's also important to consider whether the common uses are in >>>> MT or >>>> single-threaded programs. Why even bother measuring the cost for >>>> single-threaded programs if they are not the target, or if no >>>> consequential single-threaded programs exist that might use this >>>> library? >>> >>> SPEC. >> >> What does that mean ? > > > Standard Performance Evaluation Corporation > http://www.spec.org/ > Sun, especially the software division, lives and dies by SPEC > performance measurements. Artificially reducing performance has > consequences for the entire company. That said, Darren's other comments seem particularly apropos -- if libraries are permitted to create threads at any time, then it becomes impossible for developers to predict whether their program (for non-trivial programs at least) will be MT or not, and therefore all libraries must be thread-safe. The libc should have an optimization that on single CPU systems the mutexes involved are noops. That doesn't help single threaded applications on SMP systems, but it does help single CPU systems at least. :-) Besides which, I thought uncontended mutexes were supposed to be *cheap*. -- Garrett From Nicolas.Williams@Sun.COM Tue Sep 9 09:16:05 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m89GG5AS009166 for ; Tue, 9 Sep 2008 09:16:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m89GG0eB026909; Tue, 9 Sep 2008 09:16:03 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6X00E0PRUQ6V00@brm-avmta-1.central.sun.com>; Tue, 09 Sep 2008 10:16:02 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6X0083ORUQWN70@brm-avmta-1.central.sun.com>; Tue, 09 Sep 2008 10:16:02 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m89GG2Hw005696; Tue, 09 Sep 2008 11:16:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m89GG2VC005695; Tue, 09 Sep 2008 11:16:02 -0500 (CDT) Date: Tue, 09 Sep 2008 11:16:01 -0500 From: Nicolas Williams Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C64346.6080408@Sun.COM> To: Darren J Moffat Cc: Steve Clamage , John.Fischer@Sun.COM, John Plocher , "Garrett D'Amore" , Stefan Teleman , psarc-ext@Sun.COM Message-id: <20080909161601.GN1524@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> <48C64346.6080408@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 915 On Tue, Sep 09, 2008 at 10:35:02AM +0100, Darren J Moffat wrote: > Nicolas Williams wrote: > >But it's also important to consider whether the common uses are in MT or > >single-threaded programs. Why even bother measuring the cost for > >single-threaded programs if they are not the target, or if no > >consequential single-threaded programs exist that might use this > >library? > > There is not such thing as a non MT program post Solaris 10. All > processes potentially have more than one thread. I've been pointing this out. Perhaps the compiler team wishes to argue that a unified C process model need not imply a unified C++ process model (I strongly suspect that that's just not really workable, but the compiler team should know better). My comment above was about the undesirability of having two process models for C++ even if that could be made to work with the unified C process model. Nico -- From Stephen.Clamage@Sun.COM Tue Sep 9 09:22:00 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m89GM01D009262 for ; Tue, 9 Sep 2008 09:22:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m89GLuBZ018219 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 9 Sep 2008 17:21:59 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6X0080BS4KQI00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 09:21:56 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6X000GPS4KN9D0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 09:21:56 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m89GLuGu007185 for ; Tue, 09 Sep 2008 09:21:56 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6X00G01RTYY900@fe-sfbay-10.sun.com> (original mail from Stephen.Clamage@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 09:21:56 -0700 (PDT) Received: from [129.146.86.208] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6X00EG0S4FZGB0@fe-sfbay-10.sun.com>; Tue, 09 Sep 2008 09:21:51 -0700 (PDT) Date: Tue, 09 Sep 2008 09:21:50 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C69262.50103@sun.com> Sender: Stephen.Clamage@Sun.COM To: "Garrett D'Amore" Cc: Darren J Moffat , Nicolas Williams , John.Fischer@Sun.COM, John Plocher , Stefan Teleman , psarc-ext@Sun.COM Message-id: <48C6A29E.4030704@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> <48C5AA3F.1010501@sun.com> <48C64372.2020109@Sun.COM> <48C68F95.5000701@sun.com> <48C69262.50103@sun.com> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 3514 On 09/09/08 08:12, Garrett D'Amore wrote: > Steve Clamage wrote: >> >> >> On 09/09/08 02:35, Darren J Moffat wrote: >>> Steve Clamage wrote: >>>>>> I agree with Stefan that we need to do some measurements to see >>>>>> whether the performance difference is important. >>>>> But it's also important to consider whether the common uses are in >>>>> MT or >>>>> single-threaded programs. Why even bother measuring the cost for >>>>> single-threaded programs if they are not the target, or if no >>>>> consequential single-threaded programs exist that might use this >>>>> library? >>>> >>>> SPEC. >>> >>> What does that mean ? >> >> >> Standard Performance Evaluation Corporation >> http://www.spec.org/ >> Sun, especially the software division, lives and dies by SPEC >> performance measurements. Artificially reducing performance has >> consequences for the entire company. > > That said, Darren's other comments seem particularly apropos -- if > libraries are permitted to create threads at any time, then it becomes > impossible for developers to predict whether their program (for > non-trivial programs at least) will be MT or not, and therefore all > libraries must be thread-safe. > > The libc should have an optimization that on single CPU systems the > mutexes involved are noops. That doesn't help single threaded > applications on SMP systems, but it does help single CPU systems at > least. :-) > > Besides which, I thought uncontended mutexes were supposed to be *cheap*. Each compiler release supports a range of Solaris versions. The currently-shipping compilers support Solaris versions as early as Solaris 8. We don't want to have different sets of instructions for using the compiler on different Solaris versions. In line with the Solaris Guarantee, we promise that binaries created on an older Solaris version can be linked into a program created on a later Solaris version. The compiler default is to generate single-threaded programs. The -DRE_ENTRANT macro is not set, and libthread is not linked. To compile an MT program, we recommend using the -mt option, which takes care of defining RE_ENTRANT and linking the thread library in the right order. The entire program must use -mt consistently: it must appear on every command line, or not appear on any command line. (I'm ignoring the case where the linker is invoked directly instead of via cc or CC.) The libraries we currently ship adjust automatically for single- or multi-threaded use. The locking code is #ifdef'd away or becomes a no-op for a single-threaded compilation. Apache libstdcxx is different -- it must be built for single-threaded or MT use. Let's take the case where we provide only an MT version of the runtime library. I'm not clear on the consequences of linking code compiled without -DRE_ENTRANT with MT code. Is that always safe? If so, maybe the only issue would be performance. (We don't yet know whether performance is an issue.) If mixing MT and non-MT code is problematic, we must tell users to add -mt when using libstdcxx. When we add support for libstdcxx to CC, it can add -mt implicitly to every command line. But that still leaves this case for Sun Studio 12, which supports Solaris 9, 10, and SNV: % cc -c f1.c # on Solaris 9, single threaded % CC -c -library=stdcxx f2.cc # on S10, implicit -mt % CC -o myprog -library=stdcxx f1.o f2.o # implicit -mt Will this program always work? --- Steve Clamage, stephen.clamage@sun.com From Stefan.Teleman@sun.com Tue Sep 9 09:35:24 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m89GZOKl010406 for ; Tue, 9 Sep 2008 09:35:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m89GZLtO063759; Tue, 9 Sep 2008 10:35:22 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6X00A11SQW1000@nwk-avmta-1.sfbay.Sun.COM>; Tue, 09 Sep 2008 09:35:20 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6X009WGSQVPG20@nwk-avmta-1.sfbay.Sun.COM>; Tue, 09 Sep 2008 09:35:19 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m89GZ2OQ004050; Tue, 09 Sep 2008 09:35:07 -0700 (PDT) Date: Tue, 09 Sep 2008 12:35:01 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C6A29E.4030704@sun.com> To: Steve Clamage Cc: "Garrett D'Amore" , John.Fischer@sun.com, Nicolas Williams , Darren J Moffat , John Plocher , psarc-ext@sun.com Reply-to: Stefan Teleman Message-id: <48C6A5B5.6010000@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> <48C5AA3F.1010501@sun.com> <48C64372.2020109@Sun.COM> <48C68F95.5000701@sun.com> <48C69262.50103@sun.com> <48C6A29E.4030704@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 774 Steve Clamage wrote: > Apache libstdcxx is different -- it must be built for single-threaded or > MT use. > > Let's take the case where we provide only an MT version of the runtime > library. > > I'm not clear on the consequences of linking code compiled without > -DRE_ENTRANT with MT code. Is that always safe? If so, maybe the only > issue would be performance. (We don't yet know whether performance is an > issue.) We can force stdcxx into thinking it's always MT, even for those cases where the user application hasn't passed -mt -D_REENTRANT to the compiler (by secretly raising _RWSTD_REENTRANT in the internal config.h file). In my view the only issues here is performance. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Stephen.Clamage@sun.com Tue Sep 9 10:08:49 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m89H8nrx013570 for ; Tue, 9 Sep 2008 10:08:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m89H8jam005903 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 9 Sep 2008 10:08:49 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6X00H31UAOW500@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 11:08:48 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6X0088TUAMWPA0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 11:08:46 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m89H8kZU014285 for ; Tue, 09 Sep 2008 10:08:46 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6X00F01THAU600@fe-sfbay-09.sun.com> (original mail from Stephen.Clamage@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 10:08:46 -0700 (PDT) Received: from [129.146.86.208] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6X004OMUAL32D0@fe-sfbay-09.sun.com>; Tue, 09 Sep 2008 10:08:45 -0700 (PDT) Date: Tue, 09 Sep 2008 10:08:45 -0700 From: Steve Clamage Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C6A5B5.6010000@Sun.COM> Sender: Stephen.Clamage@sun.com To: Stefan Teleman Cc: "Garrett D'Amore" , John.Fischer@sun.com, Nicolas Williams , Darren J Moffat , John Plocher , psarc-ext@sun.com Message-id: <48C6AD9D.20106@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> <48C5AA3F.1010501@sun.com> <48C64372.2020109@Sun.COM> <48C68F95.5000701@sun.com> <48C69262.50103@sun.com> <48C6A29E.4030704@sun.com> <48C6A5B5.6010000@Sun.COM> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 1009 On 09/09/08 09:35, Stefan Teleman wrote: > > > Steve Clamage wrote: > >> Apache libstdcxx is different -- it must be built for single-threaded >> or MT use. >> >> Let's take the case where we provide only an MT version of the runtime >> library. >> >> I'm not clear on the consequences of linking code compiled without >> -DRE_ENTRANT with MT code. Is that always safe? If so, maybe the only >> issue would be performance. (We don't yet know whether performance is >> an issue.) > > We can force stdcxx into thinking it's always MT, even for those cases > where the user application hasn't passed -mt -D_REENTRANT to the > compiler (by secretly raising _RWSTD_REENTRANT in the internal config.h > file). That won't help the case of modules that don't include headers from libstdcxx, or that include system headers before including libstdcxx headers. My original question remains: Is it safe to mix .o files compiled with and without -D_REENTRANT ? --- Steve Clamage, stephen.clamage@sun.com From gdamore@sun.com Tue Sep 9 10:15:53 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m89HFrFg013939 for ; Tue, 9 Sep 2008 10:15:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m89HFllY016478 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 9 Sep 2008 11:15:52 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6X00D1HUMGG200@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 10:15:52 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6X009AGUMDPU80@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 10:15:49 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m89HFnnH025355 for ; Tue, 09 Sep 2008 10:15:49 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6X00401QVR3E00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 10:15:49 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6X00BEGUM8I670@fe-sfbay-10.sun.com>; Tue, 09 Sep 2008 10:15:45 -0700 (PDT) Date: Tue, 09 Sep 2008 10:14:40 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C6A5B5.6010000@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: Steve Clamage , John.Fischer@sun.com, Nicolas Williams , Darren J Moffat , John Plocher , psarc-ext@sun.com Message-id: <48C6AF00.8020107@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> <48C5AA3F.1010501@sun.com> <48C64372.2020109@Sun.COM> <48C68F95.5000701@sun.com> <48C69262.50103@sun.com> <48C6A29E.4030704@sun.com> <48C6A5B5.6010000@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 896 Stefan Teleman wrote: > > > Steve Clamage wrote: > >> Apache libstdcxx is different -- it must be built for single-threaded >> or MT use. >> >> Let's take the case where we provide only an MT version of the >> runtime library. >> >> I'm not clear on the consequences of linking code compiled without >> -DRE_ENTRANT with MT code. Is that always safe? If so, maybe the only >> issue would be performance. (We don't yet know whether performance is >> an issue.) > > We can force stdcxx into thinking it's always MT, even for those cases > where the user application hasn't passed -mt -D_REENTRANT to the > compiler (by secretly raising _RWSTD_REENTRANT in the internal > config.h file). > > In my view the only issues here is performance. I concur. As far as releases prior to S10, I would vote that we don't bother to retrofit this further back than S10. -- Garrett > > --Stefan > From gdamore@sun.com Tue Sep 9 10:22:46 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m89HMk0s014169 for ; Tue, 9 Sep 2008 10:22:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m89HMiJj010760 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 9 Sep 2008 10:22:46 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6X00I07UXXVR00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 11:22:45 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6X0080XUXVWIB0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 11:22:44 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m89HMhb2026334 for ; Tue, 09 Sep 2008 10:22:43 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6X00G01UOWLF00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 09 Sep 2008 10:22:43 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6X00FF7UXMAA40@fe-sfbay-09.sun.com>; Tue, 09 Sep 2008 10:22:35 -0700 (PDT) Date: Tue, 09 Sep 2008 10:21:29 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C6AD9D.20106@sun.com> Sender: Garrett.Damore@sun.com To: Steve Clamage Cc: Stefan Teleman , John.Fischer@sun.com, Nicolas Williams , Darren J Moffat , John Plocher , psarc-ext@sun.com Message-id: <48C6B099.7020802@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> <48C5AA3F.1010501@sun.com> <48C64372.2020109@Sun.COM> <48C68F95.5000701@sun.com> <48C69262.50103@sun.com> <48C6A29E.4030704@sun.com> <48C6A5B5.6010000@Sun.COM> <48C6AD9D.20106@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1337 Steve Clamage wrote: > On 09/09/08 09:35, Stefan Teleman wrote: >> >> >> Steve Clamage wrote: >> >>> Apache libstdcxx is different -- it must be built for >>> single-threaded or MT use. >>> >>> Let's take the case where we provide only an MT version of the >>> runtime library. >>> >>> I'm not clear on the consequences of linking code compiled without >>> -DRE_ENTRANT with MT code. Is that always safe? If so, maybe the >>> only issue would be performance. (We don't yet know whether >>> performance is an issue.) >> >> We can force stdcxx into thinking it's always MT, even for those >> cases where the user application hasn't passed -mt -D_REENTRANT to >> the compiler (by secretly raising _RWSTD_REENTRANT in the internal >> config.h file). > > That won't help the case of modules that don't include headers from > libstdcxx, or that include system headers before including libstdcxx > headers. > > My original question remains: Is it safe to mix .o files compiled with > and without -D_REENTRANT ? I believe so, at least in Solaris 10 and later. As far as I can tell, the only thing that -D_REENTRANT does is make some additional prototypes visible, required for POSIX conformance. I don't think it changes anything in the actual resulting binary. -- Garrett > > --- > Steve Clamage, stephen.clamage@sun.com From Stefan.Teleman@sun.com Tue Sep 9 10:23:01 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m89HN0wX014181 for ; Tue, 9 Sep 2008 10:23:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m89HMr7H016370; Tue, 9 Sep 2008 18:22:56 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6X00I1RUY7W100@brm-avmta-1.central.sun.com>; Tue, 09 Sep 2008 11:22:55 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6X008U4UY6WAA0@brm-avmta-1.central.sun.com>; Tue, 09 Sep 2008 11:22:54 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m89HMq16015619; Tue, 09 Sep 2008 10:22:53 -0700 (PDT) Date: Tue, 09 Sep 2008 13:22:52 -0400 From: Stefan Teleman Subject: Re: PSARC/2008/549 - Apache Standard C++ Library In-reply-to: <48C6AF00.8020107@sun.com> To: "Garrett D'Amore" Cc: Steve Clamage , John.Fischer@sun.com, Nicolas Williams , Darren J Moffat , John Plocher , psarc-ext@sun.com Reply-to: Stefan Teleman Message-id: <48C6B0EC.7060608@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48C201B1.4060803@sun.com> <48C29D3F.1000205@Sun.Com> <48C2DB1E.7080806@Sun.COM> <48C3EF73.1090309@sun.com> <48C3F6D5.8050609@Sun.COM> <48C3F813.2030006@sun.com> <48C3F9A0.7020808@Sun.COM> <48C59730.7050809@sun.com> <20080908213603.GF1524@Sun.COM> <48C5A1A2.5010403@sun.com> <20080908223059.GH1524@Sun.COM> <48C5AA3F.1010501@sun.com> <48C64372.2020109@Sun.COM> <48C68F95.5000701@sun.com> <48C69262.50103@sun.com> <48C6A29E.4030704@sun.com> <48C6A5B5.6010000@Sun.COM> <48C6AF00.8020107@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1007 Garrett D'Amore wrote: > Stefan Teleman wrote: >> >> >> Steve Clamage wrote: >> >>> Apache libstdcxx is different -- it must be built for single-threaded >>> or MT use. >>> >>> Let's take the case where we provide only an MT version of the >>> runtime library. >>> >>> I'm not clear on the consequences of linking code compiled without >>> -DRE_ENTRANT with MT code. Is that always safe? If so, maybe the only >>> issue would be performance. (We don't yet know whether performance is >>> an issue.) >> >> We can force stdcxx into thinking it's always MT, even for those cases >> where the user application hasn't passed -mt -D_REENTRANT to the >> compiler (by secretly raising _RWSTD_REENTRANT in the internal >> config.h file). >> >> In my view the only issues here is performance. > I concur. > > As far as releases prior to S10, I would vote that we don't bother to > retrofit this further back than S10. I agree. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From sacadmin Tue Sep 23 20:07:27 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8O37QNU025808 for ; Tue, 23 Sep 2008 20:07:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8O37Leu029980; Wed, 24 Sep 2008 11:07:23 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7O00619JC9XW00@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Sep 2008 20:07:21 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7O00BA3JC9OOE0@nwk-avmta-2.sfbay.sun.com>; Tue, 23 Sep 2008 20:07:21 -0700 (PDT) Received: from Macintosh-124.local (vpn-sfbay-net-19.SFBay.Sun.COM [129.150.19.0]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8O373uH876473; Tue, 23 Sep 2008 20:07:09 -0700 (PDT) Date: Tue, 23 Sep 2008 20:07:01 -0700 From: Tim Marsland Subject: Re: PSARC 2008/549 Apache Standard C++ Library In-reply-to: <48BEC2C7.9060000@sun.com> To: psarc-members@Sun.COM Cc: Tim Marsland Message-id: <48D9AED5.6070007@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48BEC2C7.9060000@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 2304 I'm really confused about the state of this case. There's been a lot of back and forth between several different parties, and various statements of "derail". The case is now in "waiting need spec" and I think we could use some clarity around how to proceed to closure. I think Garrett was the first to derail the case on the grounds of "non-obviousness", which is ok as long as he gets to take on the role of case owner as a result. Otherwise, as someone on sabbatical he doesn't get to derail, and someone else can do it instead. Perhaps after all the discussion he changed his take on "non-obviousness", because if I look in the case directory, John Fischer is still listed as the owner, and the status is still "waiting fast-track 09/01/2008". Since I won't be at tomorrows meeting to work through it, I'd appreciate it if you could take a close look at this case and see what we can do to get it moving forward again. What I'm expecting is: - if a new spec is needed before any further decision, then please make that request specific and explicitly to the case owner (Fischer) - saying exactly what the spec needs to contain so that the specification can be considered complete. Then wait for the spec to be submitted and go back into fast-track timeout mode. in my reading of events, i think all that's actually missing from the case is a summary of the agreement about the future delivery status of this library, and an attempt to capture some of the expectations around compatibility and evolution that this presents. the latter part feels like architecture, the former feels more like communication. if i'm wrong, please make it whatever you think it should contain - within reason! - if garrett wants to derail anyway - because there's an *architectural* point he feels strongly about, then garrett must become case owner (opinion author) or persuade another member to say "derail" instead and they can be case owner. Since I won't be at tomorrows meeting to work through this, I'd appreciate it if you'd try and get to resolution so that the current case owner and project team actually know what they have to do next. And PLEASE, speak with one voice i.e. agree on what you want (no more, no less) before you ask for it. tim From sacadmin Tue Sep 23 21:08:54 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m8O48rSY027180 for ; Tue, 23 Sep 2008 21:08:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m8O48lr1018661 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Wed, 24 Sep 2008 12:08:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K7O00C03M6RYJ00@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Tue, 23 Sep 2008 21:08:51 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7O008I5M6RHF20@nwk-avmta-1.sfbay.Sun.COM> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Tue, 23 Sep 2008 21:08:51 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8O48p84005780 for ; Tue, 23 Sep 2008 21:08:51 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7O00301M60VD00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-members@sun.com (ORCPT psarc-members@sun.com); Tue, 23 Sep 2008 21:08:51 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7O00G5SM6QH5C0@fe-sfbay-09.sun.com>; Tue, 23 Sep 2008 21:08:51 -0700 (PDT) Date: Tue, 23 Sep 2008 21:06:42 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/549 Apache Standard C++ Library In-reply-to: <48D9AED5.6070007@sun.com> Sender: Garrett.Damore@sun.com To: Tim Marsland Cc: psarc-members@sun.com Message-id: <48D9BCD2.9010602@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48BEC2C7.9060000@sun.com> <48D9AED5.6070007@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3392 I'll be at tomorrow's meeting. I still feel that this case fails on some key obviousness points, and while I'm willing to own the case if necessary, I'm also feeling a bit worn down. As far as what is needed to get out of needs-spec, I think you've hit the nail on the head: I want to see clarification about what the agreements with the compiler team are (with both the compiler team and the project team in agreement), and clarification about what the compatibility story here is. (So far, it sounds like the project team's take is that there *isn't* a compatibility story, but I take offense with the idea that the library can be Committed or Standard without some long term binary compatibility guarantees.) I guess that means, if the project team is still going to pursue Committed or Standard, without both agreement from the compiler team and without any compatibility story to go with it, then I'll wind up derailing it and owning the case. -- Garrett Tim Marsland wrote: > I'm really confused about the state of this case. > > There's been a lot of back and forth between several different > parties, and various statements of "derail". > > The case is now in "waiting need spec" and I think we could > use some clarity around how to proceed to closure. > > I think Garrett was the first to derail the case on the > grounds of "non-obviousness", which is ok as long as he gets > to take on the role of case owner as a result. Otherwise, as > someone on sabbatical he doesn't get to derail, and someone > else can do it instead. > > Perhaps after all the discussion he changed his take > on "non-obviousness", because if I look in the case directory, > John Fischer is still listed as the owner, and > the status is still "waiting fast-track 09/01/2008". > > Since I won't be at tomorrows meeting to work through it, > I'd appreciate it if you could take a close look at this > case and see what we can do to get it moving forward again. > > What I'm expecting is: > > - if a new spec is needed before any further decision, then > please make that request specific and explicitly to the > case owner (Fischer) - saying exactly what the spec needs > to contain so that the specification can be considered > complete. Then wait for the spec to be submitted and > go back into fast-track timeout mode. > > in my reading of events, i think all that's actually > missing from the case is a summary of the agreement about > the future delivery status of this library, and an attempt > to capture some of the expectations around compatibility > and evolution that this presents. the latter part feels > like architecture, the former feels more like communication. > > if i'm wrong, please make it whatever you think it should > contain - within reason! > > - if garrett wants to derail anyway - because there's > an *architectural* point he feels strongly about, then > garrett must become case owner (opinion author) or persuade > another member to say "derail" instead and they can be case > owner. > > Since I won't be at tomorrows meeting to work through this, > I'd appreciate it if you'd try and get to resolution so > that the current case owner and project team actually > know what they have to do next. > > And PLEASE, speak with one voice i.e. agree on what you > want (no more, no less) before you ask for it. > > tim From sacadmin Tue Sep 30 17:46:03 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m910k2oN006901 for ; Tue, 30 Sep 2008 17:46:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m910k1G4048128; Tue, 30 Sep 2008 18:46:01 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8100301BGPEA00@nwk-avmta-2.sfbay.sun.com>; Tue, 30 Sep 2008 17:46:01 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8100MABBGPLV70@nwk-avmta-2.sfbay.sun.com>; Tue, 30 Sep 2008 17:46:01 -0700 (PDT) Received: from Macintosh-124.local (vpn-129-150-18-23.SFBay.Sun.COM [129.150.18.23]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m910jg1E841132; Tue, 30 Sep 2008 17:45:48 -0700 (PDT) Date: Tue, 30 Sep 2008 17:45:41 -0700 From: Tim Marsland Subject: Re: PSARC 2008/549 Apache Standard C++ Library In-reply-to: <48D9BCD2.9010602@sun.com> To: "Garrett D'Amore" Cc: psarc-members@Sun.COM, Aarti Pai Message-id: <48E2C835.4060104@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48BEC2C7.9060000@sun.com> <48D9AED5.6070007@sun.com> <48D9BCD2.9010602@sun.com> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 3877 Ok, so it's derailed and Garrett you are now case owner. Aarti - can you adjust the IAM file appropriately? I'll ask the project team - in particular John Fischer - to drop an updated proposal into the case directory, then schedule a meeting slot to have a live discussion with all interested parties. (I don't really want another email-a-thon, please.) tim Garrett D'Amore wrote: > I'll be at tomorrow's meeting. I still feel that this case fails on > some key obviousness points, and while I'm willing to own the case if > necessary, I'm also feeling a bit worn down. > > As far as what is needed to get out of needs-spec, I think you've hit > the nail on the head: I want to see clarification about what the > agreements with the compiler team are (with both the compiler team and > the project team in agreement), and clarification about what the > compatibility story here is. (So far, it sounds like the project team's > take is that there *isn't* a compatibility story, but I take offense > with the idea that the library can be Committed or Standard without some > long term binary compatibility guarantees.) > > I guess that means, if the project team is still going to pursue > Committed or Standard, without both agreement from the compiler team and > without any compatibility story to go with it, then I'll wind up > derailing it and owning the case. > > -- Garrett > > Tim Marsland wrote: >> I'm really confused about the state of this case. >> >> There's been a lot of back and forth between several different >> parties, and various statements of "derail". >> >> The case is now in "waiting need spec" and I think we could >> use some clarity around how to proceed to closure. >> >> I think Garrett was the first to derail the case on the >> grounds of "non-obviousness", which is ok as long as he gets >> to take on the role of case owner as a result. Otherwise, as >> someone on sabbatical he doesn't get to derail, and someone >> else can do it instead. >> >> Perhaps after all the discussion he changed his take >> on "non-obviousness", because if I look in the case directory, >> John Fischer is still listed as the owner, and >> the status is still "waiting fast-track 09/01/2008". >> >> Since I won't be at tomorrows meeting to work through it, >> I'd appreciate it if you could take a close look at this >> case and see what we can do to get it moving forward again. >> >> What I'm expecting is: >> >> - if a new spec is needed before any further decision, then >> please make that request specific and explicitly to the >> case owner (Fischer) - saying exactly what the spec needs >> to contain so that the specification can be considered >> complete. Then wait for the spec to be submitted and >> go back into fast-track timeout mode. >> >> in my reading of events, i think all that's actually >> missing from the case is a summary of the agreement about >> the future delivery status of this library, and an attempt >> to capture some of the expectations around compatibility >> and evolution that this presents. the latter part feels >> like architecture, the former feels more like communication. >> >> if i'm wrong, please make it whatever you think it should >> contain - within reason! >> >> - if garrett wants to derail anyway - because there's >> an *architectural* point he feels strongly about, then >> garrett must become case owner (opinion author) or persuade >> another member to say "derail" instead and they can be case >> owner. >> >> Since I won't be at tomorrows meeting to work through this, >> I'd appreciate it if you'd try and get to resolution so >> that the current case owner and project team actually >> know what they have to do next. >> >> And PLEASE, speak with one voice i.e. agree on what you >> want (no more, no less) before you ask for it. >> >> tim > From gdamore@sun.com Wed Oct 1 23:20:17 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m926KFZh027108 for ; Wed, 1 Oct 2008 23:20:16 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m926KACx015535 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 14:20:15 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8300J01LLQG500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Oct 2008 23:20:14 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K83005JALLQF560@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Oct 2008 23:20:14 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m926KEGm010647 for ; Wed, 01 Oct 2008 23:20:14 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8300501LJ8GC00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Oct 2008 23:20:14 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8300BDRLLPNR50@fe-sfbay-10.sun.com>; Wed, 01 Oct 2008 23:20:13 -0700 (PDT) Date: Wed, 01 Oct 2008 23:17:27 -0700 From: "Garrett D'Amore" Subject: PSARC 2008/549 Re: Apache Standard C++ Library ARC Case In-reply-to: <48E458C9.8020403@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: Tim Marsland , Fred Thornborrow , John.Fischer@sun.com, Aarti Pai , Steve Clamage , PSARC-ext Message-id: <48E46777.4070804@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DC09E9.2050900@Sun.COM> <48DCFDD1.2030202@sun.com> <48E2B028.9030300@sun.com> <48E2C8C8.3060006@sun.com> <48E2F65C.4020709@sun.com> <48E2FD1F.8090906@Sun.COM> <48E317FE.4070002@sun.com> <48E325B6.6040300@Sun.COM> <48E37729.3030008@sun.com> <48E3A48B.7060803@Sun.COM> <48E3BB2C.8030908@sun.com> <48E458C9.8020403@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 10330 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 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/ From John.Fischer@Sun.COM Thu Oct 2 09:57:37 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92Gvbr6017316 for ; Thu, 2 Oct 2008 09:57:37 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m92GvReu020832 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 17:57:36 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400G53F3ZS400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 09:57:35 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8400C3JF3V8KB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 09:57:32 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m92GvVWn026066 for ; Thu, 02 Oct 2008 16:57:31 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400F01DDCKY00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 10:57:31 -0600 (MDT) Received: from 129.145.154.66 ([129.145.154.66]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K84001KRF3F2I00@mail-amer.sun.com>; Thu, 02 Oct 2008 10:57:19 -0600 (MDT) Date: Thu, 02 Oct 2008 09:57:15 -0700 From: John Fischer Subject: Re: PSARC 2008/549 Re: Apache Standard C++ Library ARC Case In-reply-to: <48E46777.4070804@sun.com> Sender: John.Fischer@Sun.COM To: "Garrett D'Amore" Cc: John Fischer , Stefan Teleman , Tim Marsland , Fred Thornborrow , Aarti Pai , Steve Clamage , PSARC-ext Reply-to: John.Fischer@Sun.COM Message-id: <1222966634.50059.2972.camel@sr1-umpk-16> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: text/plain; charset=ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DC09E9.2050900@Sun.COM> <48DCFDD1.2030202@sun.com> <48E2B028.9030300@sun.com> <48E2C8C8.3060006@sun.com> <48E2F65C.4020709@sun.com> <48E2FD1F.8090906@Sun.COM> <48E317FE.4070002@sun.com> <48E325B6.6040300@Sun.COM> <48E37729.3030008@sun.com> <48E3A48B.7060803@Sun.COM> <48E3BB2C.8030908@sun.com> <48E458C9.8020403@Sun.COM> <48E46777.4070804@sun.com> Status: RO Content-Length: 11002 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 > 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/ > > From John.Plocher@sun.com Thu Oct 2 10:33:09 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92HX9ZS018461 for ; Thu, 2 Oct 2008 10:33:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m92HX04I001633 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 10:33:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400H07GR7Z400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 10:33:07 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8400C8RGR78GD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 10:33:07 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m92HX7Ym025170 for ; Thu, 02 Oct 2008 10:33:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400D01G13RT00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 10:33:07 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8400BPVGR1DV20@fe-sfbay-09.sun.com>; Thu, 02 Oct 2008 10:33:01 -0700 (PDT) Date: Thu, 02 Oct 2008 10:32:59 -0700 From: John Plocher Subject: Re: PSARC 2008/549 Re: Apache Standard C++ Library ARC Case In-reply-to: <1222966634.50059.2972.camel@sr1-umpk-16> Sender: John.Plocher@sun.com To: John.Fischer@sun.com Cc: "Garrett D'Amore" , Steve Clamage , Aarti Pai , Fred Thornborrow , PSARC-ext , Stefan Teleman , Tim Marsland Message-id: <48E505CB.8020406@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DC09E9.2050900@Sun.COM> <48DCFDD1.2030202@sun.com> <48E2B028.9030300@sun.com> <48E2C8C8.3060006@sun.com> <48E2F65C.4020709@sun.com> <48E2FD1F.8090906@Sun.COM> <48E317FE.4070002@sun.com> <48E325B6.6040300@Sun.COM> <48E37729.3030008@sun.com> <48E3A48B.7060803@Sun.COM> <48E3BB2C.8030908@sun.com> <48E458C9.8020403@Sun.COM> <48E46777.4070804@sun.com> <1222966634.50059.2972.camel@sr1-umpk-16> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 1951 Looks like mucho lotso progress has been made. It looks pretty good, but I still have a couple of questions: o This case obsoletes STLport4 (section 4.1). How will existing users of STLPort4 find out that we did this? ("#warnings in headers...?) o This case starts libC on its own path towards Obsolescence (4.3, 4.4) Same comments apply as above, but not as urgently. o What are the actual dependencies between this project and the studio12 compilers? o Who is signed up to track the Apache stdcxx project and update the bits in SFW over time, and how do you expect those bits to evolve? (picky interface taxonomy details needed, along with a bigger picture of who gets a chair when the music stops - erm, I mean, what happens when Apache comes out with incompatible change or does a Major Version 5 or 6 ...) and clarifications: >> Stefan Teleman wrote: >> 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:... >> 3.3. The SFW Consolidation will provide a default UNIX man >> page... will detail the mechanics of ... >> 3.4. The DevPro/Tools Group will provide integrated command-line >> support... >> 3.5. ... This document does not attempt to address the interfaces >> to be provided... How can you create ".pc" files that encode the correct flags without first knowing what the flags (interfaces) are? See my dependency question above... >> 4. Future Directions, and Recommendations for Solaris Developers ... >> 4.5. The contents of this document do not establish ARC Precedent. This conflicts with the statements in 4.1 thru 4.4 - of you expect any of them to be followed, you *need* a precedent. This is where I would like to see buy-in from the compiler team. -John From gdamore@sun.com Thu Oct 2 10:56:42 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92Hug2H019036 for ; Thu, 2 Oct 2008 10:56:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m92HufuB022841 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 11:56:41 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400009HUHCQ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 10:56:41 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K84007L9HUG17C0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 10:56:40 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m92HueCa016274 for ; Thu, 02 Oct 2008 10:56:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400L01H7T9R00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 10:56:40 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8400771HUFUV40@fe-sfbay-10.sun.com>; Thu, 02 Oct 2008 10:56:40 -0700 (PDT) Date: Thu, 02 Oct 2008 10:53:50 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/549 Re: Apache Standard C++ Library ARC Case In-reply-to: <48E505CB.8020406@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: John.Fischer@sun.com, Steve Clamage , Aarti Pai , Fred Thornborrow , PSARC-ext , Stefan Teleman , Tim Marsland Message-id: <48E50AAE.4020008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DC09E9.2050900@Sun.COM> <48DCFDD1.2030202@sun.com> <48E2B028.9030300@sun.com> <48E2C8C8.3060006@sun.com> <48E2F65C.4020709@sun.com> <48E2FD1F.8090906@Sun.COM> <48E317FE.4070002@sun.com> <48E325B6.6040300@Sun.COM> <48E37729.3030008@sun.com> <48E3A48B.7060803@Sun.COM> <48E3BB2C.8030908@sun.com> <48E458C9.8020403@Sun.COM> <48E46777.4070804@sun.com> <1222966634.50059.2972.camel@sr1-umpk-16> <48E505CB.8020406@Sun.Com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 1788 John Plocher wrote: > Looks like mucho lotso progress has been made. It looks pretty good, > but I still have a couple of questions: > > o This case obsoletes STLport4 (section 4.1). How will existing > users of STLPort4 find out that we did this? ("#warnings in > headers...?) > > o This case starts libC on its own path towards Obsolescence (4.3, 4.4) > Same comments apply as above, but not as urgently. > > o What are the actual dependencies between this project and the > studio12 > compilers? > > o Who is signed up to track the Apache stdcxx project and update the > bits in SFW over time, and how do you expect those bits to evolve? > (picky interface taxonomy details needed, along with a bigger picture > of who gets a chair when the music stops - erm, I mean, what happens > when Apache comes out with incompatible change or does a Major > Version 5 or 6 ...) I think the DevPro folks are signing up here (waiting for final word on it.) Incompatible changes are verboten (at least not without a separate formal case to approve such changes.) That is part and parcel of the proposed Committed binding. All of the above questions are really appropriate for the DevPro folks to answer. > > and clarifications: > > ... >>> 4.5. The contents of this document do not establish ARC >>> Precedent. > > This conflicts with the statements in 4.1 thru 4.4 - of you expect any > of them > to be followed, you *need* a precedent. I think 4.5 can be reworded to indicate that precedent set here is limited to the Apache C++ v4.x line (based on C++ 2003) and that a separate case, with lots of detail, would be required for any future v5.x library (i.e. C++ 2010) which may need to break compatibility. -- Garrett From Stefan.Teleman@sun.com Thu Oct 2 11:06:37 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92I6bhN019480 for ; Thu, 2 Oct 2008 11:06:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m92I6YDP027896; Thu, 2 Oct 2008 12:06:36 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400C0RIB0U200@brm-avmta-1.central.sun.com>; Thu, 02 Oct 2008 12:06:36 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K840079YIAZ2ZA0@brm-avmta-1.central.sun.com>; Thu, 02 Oct 2008 12:06:35 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m92I6FjF294442; Thu, 02 Oct 2008 11:06:21 -0700 (PDT) Date: Thu, 02 Oct 2008 14:06:12 -0400 From: Stefan Teleman Subject: Re: PSARC 2008/549 Re: Apache Standard C++ Library ARC Case In-reply-to: <48E505CB.8020406@Sun.Com> To: John Plocher Cc: John.Fischer@sun.com, Steve Clamage , Aarti Pai , "Garrett D'Amore" , PSARC-ext , Fred Thornborrow , Tim Marsland , Stefan Teleman Reply-to: Stefan Teleman Message-id: <48E50D94.1010303@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DC09E9.2050900@Sun.COM> <48DCFDD1.2030202@sun.com> <48E2B028.9030300@sun.com> <48E2C8C8.3060006@sun.com> <48E2F65C.4020709@sun.com> <48E2FD1F.8090906@Sun.COM> <48E317FE.4070002@sun.com> <48E325B6.6040300@Sun.COM> <48E37729.3030008@sun.com> <48E3A48B.7060803@Sun.COM> <48E3BB2C.8030908@sun.com> <48E458C9.8020403@Sun.COM> <48E46777.4070804@sun.com> <1222966634.50059.2972.camel@sr1-umpk-16> <48E505CB.8020406@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 3689 Hi. My answers inline: John Plocher wrote: > Looks like mucho lotso progress has been made. It looks pretty good, > but I still have a couple of questions: > > o This case obsoletes STLport4 (section 4.1). How will existing > users of STLPort4 find out that we did this? ("#warnings in > headers...?) Proposal: - Compiler Error when passed -library=stlport4 switch, regardless of whether or not the header files are still present on the system - Standard Sun EOF/EOL Process - Notices on the front Sun Studio / Developer Tools page at Sun - Message sent to tools-discuss, desktop-discuss, sfwnv-discuss @os.o > o This case starts libC on its own path towards Obsolescence (4.3, 4.4) > Same comments apply as above, but not as urgently. > > o What are the actual dependencies between this project and the studio12 > compilers? libCrun.so.1, which is needed by the Apache Library. > o Who is signed up to track the Apache stdcxx project and update the > bits in SFW over time, and how do you expect those bits to evolve? > (picky interface taxonomy details needed, along with a bigger picture > of who gets a chair when the music stops - erm, I mean, what happens > when Apache comes out with incompatible change or does a Major > Version 5 or 6 ...) That would be me. > and clarifications: > >>> Stefan Teleman wrote: >>> 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:... > >>> 3.3. The SFW Consolidation will provide a default UNIX man >>> page... will detail the mechanics of ... >>> 3.4. The DevPro/Tools Group will provide integrated command-line >>> support... >>> 3.5. ... This document does not attempt to address the interfaces >>> to be provided... > > How can you create ".pc" files that encode the correct flags without > first knowing what the flags (interfaces) are? See my dependency > question above... There are two phases to this: 1. Phase I: before Sun Studio provides command-line switch support for the Apache Library, pkg-config will print: pgk-config --cxxflags stdcxx: -library=no%Cstd \ -Qoption ccfe ++boolflag:sunwcch=false \ -Qoption ccfe -features=gcc \ -I/usr/include/stdcxx/ansi \ -I/usr/include/stdcxx \ -features=anachronisms,except,rtti,\ export,extensions,nestedaccess,tmplife,\ tmplrefstatic \ -instances=global \ -template=geninlinefuncs \ -xlang=c99 \ -D_XOPEN_SOURCE=500 \ -D_XPG5 pkg-config --ldflags stdcxx: -library=no%Cstd -lstdcxx 2 Phase II: after implementation of Sun Studio support for the Apache Library command-line switch [ updated *.pc files delivered in a patch ]: pkg-config --cxxflags stdcxx: [ specific Sun Studio stdcxx compiler flag ] [ example: -library=stdcxx ] pkg-config --ldflags stdcxx: [ specific Sun Studio stdcxx compiler flag ] [ example: -library=stdcxx ] The latter are pure examples -- the actual flags are left entirely at the discretion of the DevPro/Tools Group. Not to be construed as an imposition on the Tools Group. >>> 4. Future Directions, and Recommendations for Solaris Developers > ... >>> 4.5. The contents of this document do not establish ARC Precedent. > > This conflicts with the statements in 4.1 thru 4.4 - of you expect any of them > to be followed, you *need* a precedent. Then i need help with clarifying this. I was under the impression that Garrett explicitly asked for this Case not to set a precedent. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From Stephen.Clamage@Sun.COM Thu Oct 2 11:16:30 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92IGU6C019769 for ; Thu, 2 Oct 2008 11:16:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m92IGSl3006294 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 11:16:30 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K840020XIRHAX00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 11:16:29 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K84001LYIRG2720@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 11:16:28 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m92IGSj8018997 for ; Thu, 02 Oct 2008 11:16:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400B01IPW8N00@fe-sfbay-10.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 11:16:28 -0700 (PDT) Received: from [129.150.18.15] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K840072UIRAUVE0@fe-sfbay-10.sun.com>; Thu, 02 Oct 2008 11:16:23 -0700 (PDT) Date: Thu, 02 Oct 2008 11:16:22 -0700 From: Steve Clamage Subject: Re: PSARC 2008/549 Re: Apache Standard C++ Library ARC Case In-reply-to: <48E505CB.8020406@Sun.Com> Sender: Stephen.Clamage@Sun.COM To: John Plocher Cc: John.Fischer@Sun.COM, "Garrett D'Amore" , Aarti Pai , Fred Thornborrow , PSARC-ext , Stefan Teleman , Tim Marsland Message-id: <48E50FF6.5010203@sun.com> Organization: Sun Microsystems, Inc MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DC09E9.2050900@Sun.COM> <48DCFDD1.2030202@sun.com> <48E2B028.9030300@sun.com> <48E2C8C8.3060006@sun.com> <48E2F65C.4020709@sun.com> <48E2FD1F.8090906@Sun.COM> <48E317FE.4070002@sun.com> <48E325B6.6040300@Sun.COM> <48E37729.3030008@sun.com> <48E3A48B.7060803@Sun.COM> <48E3BB2C.8030908@sun.com> <48E458C9.8020403@Sun.COM> <48E46777.4070804@sun.com> <1222966634.50059.2972.camel@sr1-umpk-16> <48E505CB.8020406@Sun.Com> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 3210 I'll repeat what I said in an earlier email (not sure who-all got copies). DevPro does not support declaring STLport or libCstd obsolete or deprecated. We support older compiler releases and older Solaris versions for which there is no other option. If Solaris wants to specify that only libstdcxx can be used for C++ code that is part of Nevada/OpenSolaris, that's another story, and has no negative impact on Sun Studio users. We will undertake to add a command-line option to Studio 12 C++ and the C++ release under development to use the libstdcxx installed in Solaris. For example, the option -library=stdcxx would cause the Apache library to be used in compiling and linking; neither libCstd nor STLport would be referenced. The option would have to be used on every CC command line in the project. With the approval of my management (which I expect not to be an issue), we will take over maintenance of Apache libstdcxx, and provide fully compatible updates as needed. (We already do this for C++ runtime libraries, and math headers and libraries.) --- Steve Clamage, stephen.clamage@sun.com On 10/2/2008 10:32 AM, John Plocher wrote: > Looks like mucho lotso progress has been made. It looks pretty good, > but I still have a couple of questions: > > o This case obsoletes STLport4 (section 4.1). How will existing > users of STLPort4 find out that we did this? ("#warnings in > headers...?) > > o This case starts libC on its own path towards Obsolescence (4.3, 4.4) > Same comments apply as above, but not as urgently. > > o What are the actual dependencies between this project and the studio12 > compilers? > > o Who is signed up to track the Apache stdcxx project and update the > bits in SFW over time, and how do you expect those bits to evolve? > (picky interface taxonomy details needed, along with a bigger picture > of who gets a chair when the music stops - erm, I mean, what happens > when Apache comes out with incompatible change or does a Major > Version 5 or 6 ...) > > and clarifications: > >>> Stefan Teleman wrote: >>> 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:... > >>> 3.3. The SFW Consolidation will provide a default UNIX man >>> page... will detail the mechanics of ... >>> 3.4. The DevPro/Tools Group will provide integrated >>> command-line >>> support... >>> 3.5. ... This document does not attempt to address the >>> interfaces >>> to be provided... > > How can you create ".pc" files that encode the correct flags without > first knowing what the flags (interfaces) are? See my dependency > question above... > >>> 4. Future Directions, and Recommendations for Solaris Developers > ... >>> 4.5. The contents of this document do not establish ARC >>> Precedent. > > This conflicts with the statements in 4.1 thru 4.4 - of you expect any > of them > to be followed, you *need* a precedent. > > This is where I would like to see buy-in from the compiler team. > > -John From gdamore@sun.com Thu Oct 2 11:26:55 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92IQsrk020591 for ; Thu, 2 Oct 2008 11:26:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m92IQpfT001312 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 19:26:53 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400J03J8RW300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 11:26:51 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8400J4FJ8R3H20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 11:26:51 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m92IQohD003149 for ; Thu, 02 Oct 2008 11:26:51 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400B01IPW8Q00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 11:26:50 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K84003B9J8J2L10@fe-sfbay-10.sun.com>; Thu, 02 Oct 2008 11:26:44 -0700 (PDT) Date: Thu, 02 Oct 2008 11:23:54 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/549 Re: Apache Standard C++ Library ARC Case In-reply-to: <48E50FF6.5010203@sun.com> Sender: Garrett.Damore@sun.com To: Steve Clamage Cc: John Plocher , John.Fischer@sun.com, Aarti Pai , Fred Thornborrow , PSARC-ext , Stefan Teleman , Tim Marsland Message-id: <48E511BA.1010200@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DC09E9.2050900@Sun.COM> <48DCFDD1.2030202@sun.com> <48E2B028.9030300@sun.com> <48E2C8C8.3060006@sun.com> <48E2F65C.4020709@sun.com> <48E2FD1F.8090906@Sun.COM> <48E317FE.4070002@sun.com> <48E325B6.6040300@Sun.COM> <48E37729.3030008@sun.com> <48E3A48B.7060803@Sun.COM> <48E3BB2C.8030908@sun.com> <48E458C9.8020403@Sun.COM> <48E46777.4070804@sun.com> <1222966634.50059.2972.camel@sr1-umpk-16> <48E505CB.8020406@Sun.Com> <48E50FF6.5010203@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 4692 Steve Clamage wrote: > I'll repeat what I said in an earlier email (not sure who-all got > copies). > > DevPro does not support declaring STLport or libCstd obsolete or > deprecated. We support older compiler releases and older Solaris > versions for which there is no other option. We need to have some assertion, then, for folks who want to build on OpenSolaris. We are going to start shipping middleware that can't be used with STLport or libCstd. So marking those libraries *obsolete* (which is *not* the same as removing them) - ONLY ON OPENSOLARIS - is probably worthwhile. This is really just a word-smithing and documentation update. Of course folks that want to build software that runs on Solaris 9 will need to use those libraries. But they won't be able to use any of that other middleware anyway. I think the problem here is that there is an assumption that obsolete marking is for the entire compiler deliverable across multiple OS', which is not what I'm suggesting. I'm suggesting just for OpenSolaris (and possibly Solaris 10, but that's an open question IMO) that it should be Obsolete (but still present). The problem is that without doing this, how do we direct users *away* from using the libraries which will be incompatible with all the other middleware on the system? > > If Solaris wants to specify that only libstdcxx can be used for C++ > code that is part of Nevada/OpenSolaris, that's another story, and has > no negative impact on Sun Studio users. Certainly that's what is being talked about. But it does have negative impact for those users *if* they want to make use of that middleware (e.g. KDE libraries, etc.) on OpenSolaris. (They won't be able to.) > > We will undertake to add a command-line option to Studio 12 C++ and > the C++ release under development to use the libstdcxx installed in > Solaris. For example, the option -library=stdcxx would cause the > Apache library to be used in compiling and linking; neither libCstd > nor STLport would be referenced. The option would have to be used on > every CC command line in the project. Cool. That will work fine. > > With the approval of my management (which I expect not to be an > issue), we will take over maintenance of Apache libstdcxx, and provide > fully compatible updates as needed. (We already do this for C++ > runtime libraries, and math headers and libraries.) Okay, we'll just need the final commitment confirmation then. -- Garrett > > --- > Steve Clamage, stephen.clamage@sun.com > > On 10/2/2008 10:32 AM, John Plocher wrote: >> Looks like mucho lotso progress has been made. It looks pretty good, >> but I still have a couple of questions: >> >> o This case obsoletes STLport4 (section 4.1). How will existing >> users of STLPort4 find out that we did this? ("#warnings in >> headers...?) >> >> o This case starts libC on its own path towards Obsolescence (4.3, >> 4.4) >> Same comments apply as above, but not as urgently. >> >> o What are the actual dependencies between this project and the >> studio12 >> compilers? >> >> o Who is signed up to track the Apache stdcxx project and update the >> bits in SFW over time, and how do you expect those bits to evolve? >> (picky interface taxonomy details needed, along with a bigger >> picture >> of who gets a chair when the music stops - erm, I mean, what happens >> when Apache comes out with incompatible change or does a >> Major Version 5 or 6 ...) >> >> and clarifications: >> >>>> Stefan Teleman wrote: >>>> 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:... >> >>>> 3.3. The SFW Consolidation will provide a default UNIX man >>>> page... will detail the mechanics of ... >>>> 3.4. The DevPro/Tools Group will provide integrated >>>> command-line >>>> support... >>>> 3.5. ... This document does not attempt to address the >>>> interfaces >>>> to be provided... >> >> How can you create ".pc" files that encode the correct flags without >> first knowing what the flags (interfaces) are? See my dependency >> question above... >> >>>> 4. Future Directions, and Recommendations for Solaris Developers >> ... >>>> 4.5. The contents of this document do not establish ARC >>>> Precedent. >> >> This conflicts with the statements in 4.1 thru 4.4 - of you expect >> any of them >> to be followed, you *need* a precedent. >> >> This is where I would like to see buy-in from the compiler team. >> >> -John From Stephen.Clamage@sun.com Thu Oct 2 11:47:01 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92Il1W4021016 for ; Thu, 2 Oct 2008 11:47:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m92IkxjU014777 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 11:47:00 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400F0XK6COW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 12:47:00 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K840071TK6B2RE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 12:46:59 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m92Ikx8b023040 for ; Thu, 02 Oct 2008 11:46:59 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400A01JZ6HE00@fe-sfbay-10.sun.com> (original mail from Stephen.Clamage@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 11:46:59 -0700 (PDT) Received: from [129.150.18.15] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K84003IWK6A2LA0@fe-sfbay-10.sun.com>; Thu, 02 Oct 2008 11:46:59 -0700 (PDT) Date: Thu, 02 Oct 2008 11:46:58 -0700 From: Steve Clamage Subject: Re: PSARC 2008/549 Re: Apache Standard C++ Library ARC Case In-reply-to: <48E511BA.1010200@sun.com> Sender: Stephen.Clamage@sun.com To: "Garrett D'Amore" Cc: John Plocher , John.Fischer@sun.com, Aarti Pai , Fred Thornborrow , PSARC-ext , Stefan Teleman , Tim Marsland Message-id: <48E51722.8000206@sun.com> Organization: Sun Microsystems, Inc MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DC09E9.2050900@Sun.COM> <48DCFDD1.2030202@sun.com> <48E2B028.9030300@sun.com> <48E2C8C8.3060006@sun.com> <48E2F65C.4020709@sun.com> <48E2FD1F.8090906@Sun.COM> <48E317FE.4070002@sun.com> <48E325B6.6040300@Sun.COM> <48E37729.3030008@sun.com> <48E3A48B.7060803@Sun.COM> <48E3BB2C.8030908@sun.com> <48E458C9.8020403@Sun.COM> <48E46777.4070804@sun.com> <1222966634.50059.2972.camel@sr1-umpk-16> <48E505CB.8020406@Sun.Com> <48E50FF6.5010203@sun.com> <48E511BA.1010200@sun.com> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 6175 On 10/2/2008 11:23 AM, Garrett D'Amore wrote: > Steve Clamage wrote: >> I'll repeat what I said in an earlier email (not sure who-all got >> copies). >> >> DevPro does not support declaring STLport or libCstd obsolete or >> deprecated. We support older compiler releases and older Solaris >> versions for which there is no other option. > > We need to have some assertion, then, for folks who want to build on > OpenSolaris. We are going to start shipping middleware that can't be > used with STLport or libCstd. You must have documentation that explains how to develop code for Open Solaris. Document the compiler options that are required and those that will not work. Existing makefiles would add the appropriate options to CCFLAGS. > > So marking those libraries *obsolete* (which is *not* the same as > removing them) - ONLY ON OPENSOLARIS - is probably worthwhile. This is > really just a word-smithing and documentation update. Fine. Put it in the Solaris documentation. > > Of course folks that want to build software that runs on Solaris 9 will > need to use those libraries. But they won't be able to use any of that > other middleware anyway. Programmers can do all kinds of things that result in a program that won't work. I don't see a role for the compiler here. Consider the developer who writes his own end-user application and wants to use STLport because libraries his application links to uses STLport, and he doesn't link to Solaris libraries that were written in C++. Do we tell him, sorry, you can't use STLport on Open Solaris? Or should the compiler emit a warning on every CC command saying STLport is obsolete? If I were that developer, I would just stop using Solaris and Sun Studio, and go somewhere where developers are free to use their own judgment. > > I think the problem here is that there is an assumption that obsolete > marking is for the entire compiler deliverable across multiple OS', > which is not what I'm suggesting. I'm suggesting just for OpenSolaris > (and possibly Solaris 10, but that's an open question IMO) that it > should be Obsolete (but still present). Do it in the Solaris documentation. > > The problem is that without doing this, how do we direct users *away* > from using the libraries which will be incompatible with all the other > middleware on the system? > >> >> If Solaris wants to specify that only libstdcxx can be used for C++ >> code that is part of Nevada/OpenSolaris, that's another story, and has >> no negative impact on Sun Studio users. > > Certainly that's what is being talked about. But it does have negative > impact for those users *if* they want to make use of that middleware > (e.g. KDE libraries, etc.) on OpenSolaris. (They won't be able to.) So document that fact. The man page for each middleware component would say that you have to use libstdcxx with Sun Studio. Consider: they would run into the same or worse problems if they tried to use g++, which is completely incompatible with Sun C++. How do they know not to use g++? --- Steve Clamage, stephen.clamage@sun.com >> We will undertake to add a command-line option to Studio 12 C++ and >> the C++ release under development to use the libstdcxx installed in >> Solaris. For example, the option -library=stdcxx would cause the >> Apache library to be used in compiling and linking; neither libCstd >> nor STLport would be referenced. The option would have to be used on >> every CC command line in the project. > > Cool. That will work fine. > >> >> With the approval of my management (which I expect not to be an >> issue), we will take over maintenance of Apache libstdcxx, and provide >> fully compatible updates as needed. (We already do this for C++ >> runtime libraries, and math headers and libraries.) > > Okay, we'll just need the final commitment confirmation then. > > -- Garrett >> >> --- >> Steve Clamage, stephen.clamage@sun.com >> >> On 10/2/2008 10:32 AM, John Plocher wrote: >>> Looks like mucho lotso progress has been made. It looks pretty good, >>> but I still have a couple of questions: >>> >>> o This case obsoletes STLport4 (section 4.1). How will existing >>> users of STLPort4 find out that we did this? ("#warnings in >>> headers...?) >>> >>> o This case starts libC on its own path towards Obsolescence (4.3, >>> 4.4) >>> Same comments apply as above, but not as urgently. >>> >>> o What are the actual dependencies between this project and the >>> studio12 >>> compilers? >>> >>> o Who is signed up to track the Apache stdcxx project and update the >>> bits in SFW over time, and how do you expect those bits to evolve? >>> (picky interface taxonomy details needed, along with a bigger >>> picture >>> of who gets a chair when the music stops - erm, I mean, what happens >>> when Apache comes out with incompatible change or does a >>> Major Version 5 or 6 ...) >>> >>> and clarifications: >>> >>>>> Stefan Teleman wrote: >>>>> 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:... >>> >>>>> 3.3. The SFW Consolidation will provide a default UNIX man >>>>> page... will detail the mechanics of ... >>>>> 3.4. The DevPro/Tools Group will provide integrated >>>>> command-line >>>>> support... >>>>> 3.5. ... This document does not attempt to address the >>>>> interfaces >>>>> to be provided... >>> >>> How can you create ".pc" files that encode the correct flags without >>> first knowing what the flags (interfaces) are? See my dependency >>> question above... >>> >>>>> 4. Future Directions, and Recommendations for Solaris Developers >>> ... >>>>> 4.5. The contents of this document do not establish ARC >>>>> Precedent. >>> >>> This conflicts with the statements in 4.1 thru 4.4 - of you expect >>> any of them >>> to be followed, you *need* a precedent. >>> >>> This is where I would like to see buy-in from the compiler team. >>> >>> -John > From carlsonj@phorcys.east.sun.com Thu Oct 2 12:05:46 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92J5jsl021707 for ; Thu, 2 Oct 2008 12:05:46 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m92J5cCg017894; Thu, 2 Oct 2008 20:05:42 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400707L1FDD00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 02 Oct 2008 12:05:39 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K84001TBL1F2480@nwk-avmta-1.sfbay.Sun.COM>; Thu, 02 Oct 2008 12:05:39 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m92J5Zlc016758; Thu, 02 Oct 2008 15:05:35 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m92J5Z1j016755; Thu, 02 Oct 2008 15:05:35 -0400 (EDT) Date: Thu, 02 Oct 2008 15:05:35 -0400 From: James Carlson Subject: Re: PSARC 2008/549 Re: Apache Standard C++ Library ARC Case In-reply-to: <48E51722.8000206@sun.com> To: Steve Clamage Cc: "Garrett D'Amore" , John Plocher , John.Fischer@sun.com, Aarti Pai , Fred Thornborrow , PSARC-ext , Stefan Teleman , Tim Marsland Message-id: <18661.7039.405283.175250@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48DC09E9.2050900@Sun.COM> <48DCFDD1.2030202@sun.com> <48E2B028.9030300@sun.com> <48E2C8C8.3060006@sun.com> <48E2F65C.4020709@sun.com> <48E2FD1F.8090906@Sun.COM> <48E317FE.4070002@sun.com> <48E325B6.6040300@Sun.COM> <48E37729.3030008@sun.com> <48E3A48B.7060803@Sun.COM> <48E3BB2C.8030908@sun.com> <48E458C9.8020403@Sun.COM> <48E46777.4070804@sun.com> <1222966634.50059.2972.camel@sr1-umpk-16> <48E505CB.8020406@Sun.Com> <48E50FF6.5010203@sun.com> <48E511BA.1010200@sun.com> <48E51722.8000206@sun.com> Status: RO Content-Length: 1251 Steve Clamage writes: > and he doesn't link to Solaris libraries that were written in C++. Do we > tell him, sorry, you can't use STLport on Open Solaris? No, that'd be "removal." All that was asked for was "obsolescence." > Or should the > compiler emit a warning on every CC command saying STLport is obsolete? If it's not the right way to inform the user, then, no that's not what should be done. ARC requests always come with an implicit "don't just do whatever someone suggests; please use your head." The user should be informed in the most appropriate way possible that (a) the feature is obsolete [possibly going away in some unknown future release] and (b) there's a better replacement. > Do it in the Solaris documentation. I don't think the ARC has (or should have) much of a position on this part. The issue is delivering the appropriate documentation. How that's done is the project team's responsibility. Quibbling over compiler versus OS documentation on this list seems really out of scope to me. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Aarti.Pai@sun.com Thu Oct 2 15:01:06 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m92M16Hs000162 for ; Thu, 2 Oct 2008 15:01:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m92M16dS010155 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 2 Oct 2008 15:01:06 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8400501T5UR800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 15:01:06 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K840041WT5SF820@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 15:01:04 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m92M14pT009510 for ; Thu, 02 Oct 2008 22:01:04 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8400B01RGYS600@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 02 Oct 2008 16:01:04 -0600 (MDT) Received: from [129.145.154.52] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K84003T8T5JV400@mail-amer.sun.com>; Thu, 02 Oct 2008 16:00:59 -0600 (MDT) Date: Thu, 02 Oct 2008 15:00:55 -0700 From: Aarti Pai Subject: Re: PSARC 2008/549 Re: Apache Standard C++ Library ARC Case In-reply-to: <1222966634.50059.2972.camel@sr1-umpk-16> Sender: Aarti.Pai@sun.com To: John.Fischer@sun.com Cc: "Garrett D'Amore" , Stefan Teleman , Tim Marsland , Fred Thornborrow , Steve Clamage , PSARC-ext Reply-to: Aarti.Pai@sun.com Message-id: <48E54497.7080808@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_dDyd86rBb3v6x2lmqWRI8w)" X-PMX-Version: 5.4.1.325704 References: <48DC09E9.2050900@Sun.COM> <48DCFDD1.2030202@sun.com> <48E2B028.9030300@sun.com> <48E2C8C8.3060006@sun.com> <48E2F65C.4020709@sun.com> <48E2FD1F.8090906@Sun.COM> <48E317FE.4070002@sun.com> <48E325B6.6040300@Sun.COM> <48E37729.3030008@sun.com> <48E3A48B.7060803@Sun.COM> <48E3BB2C.8030908@sun.com> <48E458C9.8020403@Sun.COM> <48E46777.4070804@sun.com> <1222966634.50059.2972.camel@sr1-umpk-16> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 24226 This is a multi-part message in MIME format. --Boundary_(ID_dDyd86rBb3v6x2lmqWRI8w) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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 >> 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/ >> >> >> > > --Boundary_(ID_dDyd86rBb3v6x2lmqWRI8w) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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@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/

--Boundary_(ID_dDyd86rBb3v6x2lmqWRI8w)-- From garrett@damore.org Wed Oct 8 10:34:13 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m98HYDAU020122 for ; Wed, 8 Oct 2008 10:34:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m98HYA2x013044 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Oct 2008 10:34:13 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8F00707KT1AU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Oct 2008 11:34:13 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8F00K91KSZ0JC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Oct 2008 11:34:12 -0600 (MDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m98HSnuY018191 for ; Wed, 08 Oct 2008 17:34:11 +0000 (GMT) Received: from mms24es.mms.us.syntegra.com ([150.143.232.70] [150.143.232.70]) by relay22i.sun.com with ESMTP id BT-MMP-5159059 for PSARC-ext@sun.com; Wed, 08 Oct 2008 17:34:11 +0000 (Z) Received: from relay21.sun.com (relay21.sun.com [192.12.251.24]) by mms24es.mms.us.syntegra.com with ESMTP id BT-MMP-163812900 for PSARC-ext@sun.com; Wed, 08 Oct 2008 17:34:11 +0000 (Z) Received: from outbound-mail-156.bluehost.com ([67.222.39.36] [67.222.39.36]) by relay21i.sun.com id BT-MMP-1850487 for PSARC-ext@sun.com; Wed, 08 Oct 2008 17:34:11 +0000 (Z) Received: (qmail 22011 invoked by uid 0); Wed, 08 Oct 2008 17:34:08 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by outboundproxy5.bluehost.com with SMTP; Wed, 08 Oct 2008 17:34:08 +0000 Received: from sca-ea-fw-1.sun.com ([192.18.43.225] helo=[10.7.251.172]) by box374.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KncvI-0007cC-FL for PSARC-ext@sun.com; Wed, 08 Oct 2008 11:34:08 -0600 Date: Wed, 08 Oct 2008 10:30:54 -0700 From: "Garrett D'Amore" Subject: PSARC 2008/549 Apache Standard C++ Library To: PSARC-ext Message-id: <48ECEE4E.7090008@damore.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=JNNGJvt7DWakvWN7Ht1mDex/r51iTwWAGfXRmDf2GPusNlg29ln5aH5K3+IZH4f2rkiF00T1SMdlmqALkRWVI51qBU6zTQkoej2e0zLAMWlBHsi+UeyBFEPgB+j4v+Si; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 192.18.43.225 authed with garrett+damore.org} X-Antispam: No, score=0.0/5.0, scanned in 0.045sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 367 This case was approved at today's meeting, with a single TCR to provide details in man pages about compatibility concerns and obsolesence information. An AI was also added to have bugs filed against existing C++ components that should be using this library instead of STLport or libCstd. A draft opinion will be circulated for ARC review soon. -- Garrett From gdamore@sun.com Thu Oct 9 10:23:45 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m99HNiGe013287 for ; Thu, 9 Oct 2008 10:23:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m99HNfld001758 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Oct 2008 18:23:43 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8H00405EZH0A00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 10:23:41 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8H00CHTEZG0CB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 10:23:40 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m99HNeHo007321 for ; Thu, 09 Oct 2008 10:23:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8H00E01DX78L00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 10:23:40 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8H00G9GEZ9RRB0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 10:23:33 -0700 (PDT) Date: Thu, 09 Oct 2008 10:20:13 -0700 From: "Garrett D'Amore" Subject: PSARC 2008/549 Apache Standard C++ Library (draft opinion) Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <48EE3D4D.7000504@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 160 Attached is a draft opinion for review for this case. Please let me know of any changes required. Timeout for this is Wed. Oct 22. Thanks. -- Garrett From gdamore@sun.com Thu Oct 9 10:26:57 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m99HQpWM013574 for ; Thu, 9 Oct 2008 10:26:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m99HQmxY014748 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 10 Oct 2008 01:26:50 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8H0040PF4ODL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 10:26:48 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8H00C2AF4O0LD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 10:26:48 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m99HQm6r007809 for ; Thu, 09 Oct 2008 10:26:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8H00E01DX78L00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 10:26:48 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8H00GUDF4JRRC0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 10:26:44 -0700 (PDT) Date: Thu, 09 Oct 2008 10:23:23 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/549 Apache Standard C++ Library (draft opinion) In-reply-to: <48EE3D4D.7000504@sun.com> Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <48EE3E0B.3040407@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_fyXjnePkoOTLwlfx16OELg)" X-PMX-Version: 5.4.1.325704 References: <48EE3D4D.7000504@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 8913 This is a multi-part message in MIME format. --Boundary_(ID_fyXjnePkoOTLwlfx16OELg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Garrett D'Amore wrote: > Attached is a draft opinion for review for this case. Please let me > know of any changes required. Timeout for this is Wed. Oct 22. > > Thanks. > > -- Garrett > > Whoops, I clicked send too quickly! Here's the attachment (sorry 'bout that). (And for the record, PDF and PS as well as ASCII versions are in the case directory as opinion-draft.{pdf,ps,txt}. -- Garrett --Boundary_(ID_fyXjnePkoOTLwlfx16OELg) Content-type: text/plain; name=opinion-draft.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion-draft.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Apache Standard C++ Library Submitted by: Stefan Teleman File: PSARC/2008/549/opinion.ms Date: October 8th, 2008 Committee: Garrett D'Amore, Kais Belgaied, Mark Carlson, John Fischer, Tim Marsland, Rick Matthews, Glenn Skinner. Product Approval Committee: solaris-pac@sun.com 1. Summary This project seeks to integrate the Apache Standard C++ library version 4.x. This library is conforming implementa- tion of the C++ Standard Library. The project desires that this library is to be the foundation for all future Solaris projects which require a C++ standard library, and super- cedes and obsoletes the libCstd and STLport implementations shipped by DevPro for use in Solaris. Notably, this is only applicable to the Sun DevPro compilers, as GNU C++ ships with its own C++ libraries. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical change listed in Appendix A below. The project may be delivered in a patch release of the SFW consolidation. 3. Interfaces The project exports the following interfaces. ________________________________________________________________ | Interfaces Exported | |____________________________|______________________|__________| |Interface | Classification | Comments| |____________________________|______________________|__________| |/usr/include/stdcxx | Committed | (1) | |/usr/lib/libstdcxx.so.4 | Committed | (2)(3) | |/usr/lib/libstdcxx.so | Committed | (2)(3) | |____________________________|______________________|__________| PSARC/2008/549 Copyright 2008 Sun Microsystems - 2 - ________________________________________________________________ | Interfaces Exported | |____________________________|______________________|__________| |Interface | Classification | Comments| |____________________________|______________________|__________| |/usr/lib/pkgconfig/stdcxx.pc| Committed | (4) | |/usr/share/doc/html/stdcxx | Committed | | |libCstd | Obsolete Committed | (5) | |STLport4 | Obsolete Uncommitted| (5) | |____________________________|______________________|__________| (1) The include directory includes a number of header files which are required by the Standard. The entire set of header files listed in reference [2] are included by reference herein, with a Committed classification. (2) These libraries are symbolic links to a more specific version of the library, depending on the specific version of Apache C++ used. The actual version (beyond Apache Standard C++ 4.x) is not specified here. (3) In addition, 64-bit versions of these are delivered in the appropriate location (e.g. /usr/lib/amd64 or /usr/lib/sparcv9) also with Com- mitted classification. (4) This is the pkg-config configuration file contain- ing the actual compiler flags that should be used with this library. A 64-bit version of the confi- guration file is located in /usr/lib/${MACH64}/pkgconfig as well. (5) These libraries are marked Obsolete for use in building Solaris components. The DevPro group will continue to deliver them. They remain suit- able for use when building programs which need to run on earlier versions of Solaris. The project imports the following interfaces. ____________________________________________ | Interfaces Imported | |_________|________________|_______________| |Interface| Classification| Comments | |_________|________________|_______________| |libCrun | Committed | C++ runtime. | |libc | Committed | C runtime. | |libm | Committed | Math library.| |_________|________________|_______________| PSARC/2008/549 Copyright 2008 Sun Microsystems - 3 - 4. Opinion 4.1. Base C++ Standard Library This case sets a precedent that allows for projects which desire to deliver components built upon the Standard C++ library can do so, but that they are required to use this library. No other Standard C++ library may be used in the construction of shared objects delivered, as alternate implementations are generally toxic to one another in the same address space. 4.2. Future Incompatible Versions One concern raised is that new versions of the Apache Stan- dard C++ library may become available which are not binary compatible with the version this project proposes to deliver. Generally, this happens on major version boun- daries within the Apache Standard C++ project, and can be expected to support upcoming C++ standards. Such incompati- ble deliveries are required to obtain ARC approval as per normal interface classification rules. 4.3. Obsolete Legacy Libraries As the library delivered by this project is incompatible with alternate implementations, the project team and the DevPro team have agreed that alternate implementations shall be considered Obsolete when used on Solaris versions where this library is delivered. 4.4. New Compiler Flags A member expressed concern over the addition of new flags to the compiler. Specifically, the final disposition of the flags is unknown. The compiler project to add new flags to enable easy use of this library will be handled separately as an LSARC case. 4.5. Existing C++ Components A member raised a concern regarding the status of existing Solaris libraries which are built upon alternate implementa- tions. The project team agreed to take an action item to file bugs against those components to get them converted to use this library after this library integrates. 4.6. Documentation Given the not insignificant caveats about mixing implementa- tions of the Standard C++ library, and the new stability classification for legacy libraries, some members were con- cerned that this information might not be obvious to PSARC/2008/549 Copyright 2008 Sun Microsystems - 4 - developers working with these libraries. The project team agreed to document this in manual pages as specified by the technical chagne required in Appendix A. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The project shall provide documentation in man(1) page form detailing the compatibility concerns for this library. Specifically, the documentation shall explain the incompatibility of mixing alter- nate implementations in the same address space, and shall note that other implementations are Obsolete and should not be used. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2008/549. 1. Project proposal (v2) File: proposal_v2.txt 2. Header files File: materials/stdcxx-Appendix-1.txt 3. Localization files File: materials/stdcxx-Appendix-2.txt 4. Apache Standard C++ Library web site http://stdcxx.apache.org/ 5. C++ Standard http://www.open-std.org/jtc1/sc22/wg21/ PSARC/2008/549 Copyright 2008 Sun Microsystems --Boundary_(ID_fyXjnePkoOTLwlfx16OELg)-- From Stefan.Teleman@sun.com Thu Oct 9 10:53:16 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m99HrGLE014972 for ; Thu, 9 Oct 2008 10:53:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m99HrBdY021606; Thu, 9 Oct 2008 10:53:15 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8H00205GCR7V00@brm-avmta-1.central.sun.com>; Thu, 09 Oct 2008 11:53:15 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8H00M62GCR9L30@brm-avmta-1.central.sun.com>; Thu, 09 Oct 2008 11:53:15 -0600 (MDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m99HrElR819455; Thu, 09 Oct 2008 10:53:14 -0700 (PDT) Date: Thu, 09 Oct 2008 13:53:13 -0400 From: Stefan Teleman Subject: Re: PSARC 2008/549 Apache Standard C++ Library [ updated addendum 1 ] In-reply-to: <48EE3E0B.3040407@sun.com> To: PSARC-ext Cc: Stefan Teleman Reply-to: Stefan Teleman Message-id: <48EE4509.1070404@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_wptdDqnIG6Ptxp7wxcOYtA)" X-PMX-Version: 5.4.1.325704 References: <48EE3D4D.7000504@sun.com> <48EE3E0B.3040407@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 10479 This is a multi-part message in MIME format. --Boundary_(ID_wptdDqnIG6Ptxp7wxcOYtA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Attached is an updated Addendum 1 for the Apache Standard C++ Library ARC Case. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM --Boundary_(ID_wptdDqnIG6Ptxp7wxcOYtA) Content-type: text/plain; name=stdcxx_proposal_v3.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=stdcxx_proposal_v3.txt Including The Apache Standard C++ Library with Solaris Stefan Teleman October 9, 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. 1.6. Future Apache Standard C++ Library Upgrade Paths and installation directory layout conventions. 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 -lstdcxx4 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 libstdcxx4 pkg-config --ldflags libstdcxx4 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 -lstdcxx4 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 fatal 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. For the purposes of creating a maintainable and free of conflicts upgrade path for future Major Versions of the Apache Standard C++ Library, the following changes are hereby made to the installation paths for the current Integration: /usr/include/stdcxx4/ /usr/share/doc/html/stdcxx4/ /usr/lib/libstdcxx.so.4.2.1 /usr/lib/libstdcxx.so.4 -> libstdcxx.so.4.2.1 /usr/lib/libstdcxx.so -> libstdcxx.so.4.2.1 /usr/lib/pkgconfig/libstdcxx4.pc /usr/lib/${MACH64}/libstdcxx.so.4.2.1 /usr/lib/${MACH64}/libstdcxx.so.4 -> libstdcxx.so.4.2.1 /usr/lib/${MACH64}/libstdcxx.so -> libstdcxx.so.4.2.1 /usr/lib/${MACH64}/pkgconfig/libstdcxx4.pc 4.6. The contents of this document 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/ --Boundary_(ID_wptdDqnIG6Ptxp7wxcOYtA)-- From gdamore@sun.com Thu Oct 9 11:06:09 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m99I69lD015776 for ; Thu, 9 Oct 2008 11:06:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m99I67wL027043 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Oct 2008 11:06:09 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8H0031LGY83L00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 12:06:08 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8H00MWBGY79O40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 12:06:07 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m99I67NU022072 for ; Thu, 09 Oct 2008 11:06:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8H00801GSVVZ00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 11:06:07 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8H002ESGY6L0G0@fe-sfbay-09.sun.com>; Thu, 09 Oct 2008 11:06:06 -0700 (PDT) Date: Thu, 09 Oct 2008 11:02:43 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/549 Apache Standard C++ Library [ updated addendum 1 ] In-reply-to: <48EE4509.1070404@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: PSARC-ext Message-id: <48EE4743.2080402@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48EE3D4D.7000504@sun.com> <48EE3E0B.3040407@sun.com> <48EE4509.1070404@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 621 Stefan Teleman wrote: > Attached is an updated Addendum 1 for the Apache Standard C++ Library > ARC Case. > > --Stefan > Since the vote was already taken, can you please summarize, for the readers, what has changed? I believe the change is minor enough that I can just update the opinion appropriately, but I think it is fair to give those who've voted a chance to review the minor update so that they have the opportunity to reaffirm or withdraw their votes. (I doubt rather strongly anyone will change their vote -- I know what the minor change is, but I'd like you to explain it.) Thank you. -- Garrett From Stefan.Teleman@sun.com Thu Oct 9 11:17:20 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m99IHE3g016034 for ; Thu, 9 Oct 2008 11:17:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m99IHBeE002495; Fri, 10 Oct 2008 02:17:12 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8H00909HGNU700@nwk-avmta-1.sfbay.Sun.COM>; Thu, 09 Oct 2008 11:17:11 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8H007CKHGNA750@nwk-avmta-1.sfbay.Sun.COM>; Thu, 09 Oct 2008 11:17:11 -0700 (PDT) Received: from [10.7.251.110] (punchin-client-10-7-251-110.SFBay.Sun.COM [10.7.251.110]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m99IHAWJ825728; Thu, 09 Oct 2008 11:17:10 -0700 (PDT) Date: Thu, 09 Oct 2008 14:17:10 -0400 From: Stefan Teleman Subject: Re: PSARC 2008/549 Apache Standard C++ Library [ updated addendum 1 ] In-reply-to: <48EE4743.2080402@sun.com> To: "Garrett D'Amore" , PSARC-ext Reply-to: Stefan Teleman Message-id: <48EE4AA6.2040103@Sun.COM> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48EE3D4D.7000504@sun.com> <48EE3E0B.3040407@sun.com> <48EE4509.1070404@Sun.COM> <48EE4743.2080402@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1686 Garrett D'Amore wrote: > Stefan Teleman wrote: >> Attached is an updated Addendum 1 for the Apache Standard C++ Library >> ARC Case. >> >> --Stefan >> > Since the vote was already taken, can you please summarize, for the > readers, what has changed? I believe the change is minor enough that I > can just update the opinion appropriately, but I think it is fair to > give those who've voted a chance to review the minor update so that they > have the opportunity to reaffirm or withdraw their votes. (I doubt > rather strongly anyone will change their vote -- I know what the minor > change is, but I'd like you to explain it.) Yes, the summary of changes are as follows: 1. Explicitly add a '4' suffix to the relevant installation paths: /usr/include/stdcxx4/ /usr/share/doc/html/stdcxx4/ 2. Explicitly add a '4' suffix to the shared library name: /usr/lib/libstdcxx4.so.4.2.1 and the pkg-config file: /usr/lib/pkgconfig/libstdcxx4.pc and its corresponding SONAME: libstdcxx4.so.4 This will allow for free-of-conflicts upgrade paths in the future: /usr/include/stdcxx5/ /usr/share/doc/html/stdcxx5/ /usr/lib/libstdcxx5.so.x.x SONAME: libstdcxx5.so.5 [ continue in the future, as needed, with ++suffix ]. [4.5] 3. Combining more than one implementation of the Standard C++ Library in the same executable address space is now a "*fatal* software construction error", and not just a "software construction error". [4.4] 4. This ARC Case establishes ARC Precedent. [4.6] Thank you to Garrett D'Amore and Steve Clamage for the very constructive and useful offline emails. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman@Sun.COM From gdamore@sun.com Thu Oct 9 11:26:22 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m99IQLBl016200 for ; Thu, 9 Oct 2008 11:26:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m99IQBBM005590 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 10 Oct 2008 02:26:20 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8H00507HVU8A00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 11:26:18 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8H0049FHVU5B80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 11:26:18 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m99IQHei024878 for ; Thu, 09 Oct 2008 11:26:17 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8H00K01HNRDJ00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 11:26:17 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8H001V7HVTFG70@fe-sfbay-09.sun.com>; Thu, 09 Oct 2008 11:26:17 -0700 (PDT) Date: Thu, 09 Oct 2008 11:22:55 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2008/549 Apache Standard C++ Library [ updated addendum 1 ] In-reply-to: <48EE4AA6.2040103@Sun.COM> Sender: Garrett.Damore@sun.com To: Stefan Teleman Cc: PSARC-ext Message-id: <48EE4BFF.1000302@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48EE3D4D.7000504@sun.com> <48EE3E0B.3040407@sun.com> <48EE4509.1070404@Sun.COM> <48EE4743.2080402@sun.com> <48EE4AA6.2040103@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 2261 So, I'm not sure what the precedent here is. I believe that since nothing has been delivered, and the change is not necessarily substantial, that if this were filed as a follow-on case it would qualify for self-review. As an addendum to this case, do I need to explicitly ask the members that voted to reaffirm their votes before I update the opinion? - Garrett PS: As an aside, I think the revised section 4.6 offers no meaningful value to the case, and I probably would have just nuked it. Stefan Teleman wrote: > > > Garrett D'Amore wrote: >> Stefan Teleman wrote: >>> Attached is an updated Addendum 1 for the Apache Standard C++ >>> Library ARC Case. >>> >>> --Stefan >>> >> Since the vote was already taken, can you please summarize, for the >> readers, what has changed? I believe the change is minor enough that >> I can just update the opinion appropriately, but I think it is fair >> to give those who've voted a chance to review the minor update so >> that they have the opportunity to reaffirm or withdraw their votes. >> (I doubt rather strongly anyone will change their vote -- I know what >> the minor change is, but I'd like you to explain it.) > > Yes, the summary of changes are as follows: > > 1. Explicitly add a '4' suffix to the relevant installation paths: > > /usr/include/stdcxx4/ > /usr/share/doc/html/stdcxx4/ > > 2. Explicitly add a '4' suffix to the shared library name: > > /usr/lib/libstdcxx4.so.4.2.1 > > and the pkg-config file: > > /usr/lib/pkgconfig/libstdcxx4.pc > > and its corresponding SONAME: > > libstdcxx4.so.4 > > This will allow for free-of-conflicts upgrade paths in the future: > > /usr/include/stdcxx5/ > /usr/share/doc/html/stdcxx5/ > > /usr/lib/libstdcxx5.so.x.x > > SONAME: > > libstdcxx5.so.5 > > [ continue in the future, as needed, with ++suffix ]. [4.5] > > 3. Combining more than one implementation of the Standard C++ Library > in the same executable address space is now a "*fatal* software > construction error", and not just a "software construction error". [4.4] > > 4. This ARC Case establishes ARC Precedent. [4.6] > > Thank you to Garrett D'Amore and Steve Clamage for the very > constructive and useful offline emails. > > --Stefan > From John.Plocher@sun.com Thu Oct 9 11:39:30 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m99IdUAm016824 for ; Thu, 9 Oct 2008 11:39:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m99IdQ7p017853 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Oct 2008 11:39:30 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K8H00507IHUC500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 12:39:30 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K8H00MLQIHT9Q60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 12:39:29 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m99IdTOa026608 for ; Thu, 09 Oct 2008 11:39:29 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K8H00001F8PAT00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Oct 2008 11:39:29 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K8H00AZ4IHMJPC0@fe-sfbay-10.sun.com>; Thu, 09 Oct 2008 11:39:23 -0700 (PDT) Date: Thu, 09 Oct 2008 11:39:22 -0700 From: John Plocher Subject: Re: PSARC 2008/549 Apache Standard C++ Library [ updated addendum 1 ] In-reply-to: <48EE4BFF.1000302@sun.com> Sender: John.Plocher@sun.com To: "Garrett D'Amore" Cc: Stefan Teleman , PSARC-ext Message-id: <48EE4FDA.3010703@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <48EE3D4D.7000504@sun.com> <48EE3E0B.3040407@sun.com> <48EE4509.1070404@Sun.COM> <48EE4743.2080402@sun.com> <48EE4AA6.2040103@Sun.COM> <48EE4BFF.1000302@sun.com> User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) Status: RO Content-Length: 245 Garrett D'Amore wrote: > PS: As an aside, I think the revised section 4.6 offers no meaningful > value to the case, and I probably would have just nuked it. I see 4.6 as saying that 4.1-4.5 are now official ARC statements of intent. -John From sac-owner Wed Nov 19 09:30:04 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAJHU4qv000008 for ; Wed, 19 Nov 2008 09:30:04 -0800 (PST) Received: from sunmail3mpk.sfbay.sun.com (localhost [127.0.0.1]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mAJHU4pE021077 for ; Wed, 19 Nov 2008 09:30:04 -0800 (PST) Received: (from noaccess@localhost) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/Submit) id mAJHU4pm021073 for sac-opinion-not-2b-used-directly; Wed, 19 Nov 2008 09:30:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mAJHU13w020979; Wed, 19 Nov 2008 09:30:03 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KAL00M1DCM2IL00@nwk-avmta-2.sfbay.sun.com>; Wed, 19 Nov 2008 09:30:02 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KAL00JOQCM1X3E0@nwk-avmta-2.sfbay.sun.com>; Wed, 19 Nov 2008 09:30:01 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAJHU1aF009490; Wed, 19 Nov 2008 09:30:01 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAL00I01C0TUZ00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Wed, 19 Nov 2008 09:30:01 -0800 (PST) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAL00GMZCLUSR60@fe-sfbay-10.sun.com>; Wed, 19 Nov 2008 09:29:55 -0800 (PST) Date: Wed, 19 Nov 2008 09:24:01 -0800 From: "Garrett D'Amore" Subject: PSARC/2008/549 Apache Standard C++ Library Sender: Garrett.Damore@sun.com To: sac-opinion@sun.com, solaris-pac-opinion@sun.com Message-id: <49244BB1.9060601@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 8107 sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Apache Standard C++ Library Submitted by: Stefan Teleman File: PSARC/2008/549/opinion.ms Date: October 8th, 2008 Committee: Garrett D'Amore, Kais Belgaied, Mark Carlson, John Fischer, Tim Marsland, Rick Matthews, Glenn Skinner. Product Approval Committee: solaris-pac@sun.com 1. Summary This project seeks to integrate the Apache Standard C++ library version 4.x. This library is conforming implementa- tion of the C++ Standard Library. The project desires that this library is to be the foundation for all future Solaris projects which require a C++ standard library, and super- cedes and obsoletes the libCstd and STLport implementations shipped by DevPro for use in Solaris. Notably, this is only applicable to the Sun DevPro compilers, as GNU C++ ships with its own C++ libraries. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical change listed in Appendix A below. The project may be delivered in a patch release of the SFW consolidation. 3. Interfaces The project exports the following interfaces. ________________________________________________________________ | Interfaces Exported | |____________________________|______________________|__________| |Interface | Classification | Comments| |____________________________|______________________|__________| |/usr/include/stdcxx4 | Committed | (1) | |/usr/lib/libstdcxx4.so.4 | Committed | (2)(3) | |/usr/lib/libstdcxx4.so | Committed | (2)(3) | |____________________________|______________________|__________| PSARC/2008/549 Copyright 2008 Sun Microsystems - 2 - ________________________________________________________________ | Interfaces Exported | |____________________________|______________________|__________| |Interface | Classification | Comments| |____________________________|______________________|__________| |/usr/lib/pkgconfig/stdcxx.pc| Committed | (4) | |/usr/share/doc/html/stdcxx4 | Committed | | |libCstd | Obsolete Committed | (5) | |STLport4 | Obsolete Uncommitted| (5) | |____________________________|______________________|__________| (1) The include directory includes a number of header files which are required by the Standard. The entire set of header files listed in reference [2] are included by reference herein, with a Committed classification. (2) These libraries are symbolic links to a more specific version of the library, depending on the specific version of Apache C++ used. The actual version (beyond Apache Standard C++ 4.x) is not specified here. (3) In addition, 64-bit versions of these are delivered in the appropriate location (e.g. /usr/lib/amd64 or /usr/lib/sparcv9) also with Com- mitted classification. (4) This is the pkg-config configuration file contain- ing the actual compiler flags that should be used with this library. A 64-bit version of the confi- guration file is located in /usr/lib/${MACH64}/pkgconfig as well. (5) These libraries are marked Obsolete for use in building Solaris components. The DevPro group will continue to deliver them. They remain suit- able for use when building programs which need to run on earlier versions of Solaris. The project imports the following interfaces. ____________________________________________ | Interfaces Imported | |_________|________________|_______________| |Interface| Classification| Comments | |_________|________________|_______________| |libCrun | Committed | C++ runtime. | |libc | Committed | C runtime. | |libm | Committed | Math library.| |_________|________________|_______________| PSARC/2008/549 Copyright 2008 Sun Microsystems - 3 - 4. Opinion 4.1. Base C++ Standard Library This case sets a precedent that allows for projects which desire to deliver components built upon the Standard C++ library can do so, but that they are required to use this library. No other Standard C++ library may be used in the construction of shared objects delivered, as alternate implementations are generally toxic to one another in the same address space. 4.2. Future Incompatible Versions One concern raised is that new versions of the Apache Stan- dard C++ library may become available which are not binary compatible with the version this project proposes to deliver. Generally, this happens on major version boun- daries within the Apache Standard C++ project, and can be expected to support upcoming C++ standards. Such incompati- ble deliveries are required to obtain ARC approval as per normal interface classification rules. 4.3. Obsolete Legacy Libraries As the library delivered by this project is incompatible with alternate implementations, the project team and the DevPro team have agreed that alternate implementations shall be considered Obsolete when used on Solaris versions where this library is delivered. 4.4. New Compiler Flags A member expressed concern over the addition of new flags to the compiler. Specifically, the final disposition of the flags is unknown. The compiler project to add new flags to enable easy use of this library will be handled separately as an LSARC case. 4.5. Existing C++ Components A member raised a concern regarding the status of existing Solaris libraries which are built upon alternate implementa- tions. The project team agreed to take an action item to file bugs against those components to get them converted to use this library after this library integrates. 4.6. Documentation Given the not insignificant caveats about mixing implementa- tions of the Standard C++ library, and the new stability classification for legacy libraries, some members were con- cerned that this information might not be obvious to PSARC/2008/549 Copyright 2008 Sun Microsystems - 4 - developers working with these libraries. The project team agreed to document this in manual pages as specified by the technical chagne required in Appendix A. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The project shall provide documentation in man(1) page form detailing the compatibility concerns for this library. Specifically, the documentation shall explain the incompatibility of mixing alter- nate implementations in the same address space, and shall note that other implementations are Obsolete and should not be used. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2008/549. 1. Project proposal (v2) File: proposal_v2.txt 2. Header files File: materials/stdcxx-Appendix-1.txt 3. Localization files File: materials/stdcxx-Appendix-2.txt 4. Apache Standard C++ Library web site http://stdcxx.apache.org/ 5. C++ Standard http://www.open-std.org/jtc1/sc22/wg21/ PSARC/2008/549 Copyright 2008 Sun Microsystems