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