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 at 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
