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 at sun.com -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
