RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio
volker.simonis at gmail.com
Thu Jun 1 07:05:32 UTC 2017
On Thu, Jun 1, 2017 at 7:51 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On May 31, 2017, at 9:22 PM, David Holmes <david.holmes at oracle.com> wrote:
>> Hi Erik,
>> A small change with big questions :)
>> On 31/05/2017 11:45 PM, Erik Österlund wrote:
>>> It would be desirable to be able to use harmless C++ standard library headers like <limits> in the code as long as it does not add any link-time dependencies to the standard library.
>> What does a 'harmless' C++ standard library header look like?
> Header-only (doesn't require linking), doesn't run afoul of our
> [vm]assert macro, and provides functionality we presently lack (or
> only handle poorly) and would not be easy to reproduce.
> The instigator for this is Erik and I are working on a project that
> needs information that is present in std::numeric_limits<> (provided
> by the <limits> header). Reproducing that functionality ourselves
> would require platform-specific code (with all the complexity that can
> imply). We'd really rather not re-discover and maintain information
> that is trivially accessible in every standard library.
Hi Kim, Erik,
can you please explain why you only need this information on Solaris?
I'm just a little concerned that if you start this for "Solaris only"
it will be sooner or later be needed on other platforms as well.
As David already asked, how do you ensure to only use functionality
from the C++ standard library header which doesn't require link
>>> This is possible on all supported platforms except the ones using the solaris studio compiler where we enforce -library=%none in both CFLAGS and LDFLAGS.
>>> I propose to remove the restriction from CFLAGS but keep it on LDFLAGS.
>>> I have consulted with the studio folks, and they think this is absolutely fine and thought that the choice of -library=stlport4 should be fine for our CFLAGS and is indeed what is already used in the gtest launcher.
>> So what exactly does this mean? IIUC this allows you to use headers for, and compile against "STLport’s Standard Library implementation version 4.5.3 instead of the default libCstd". But how do you then not need to link against libstlport.so ??
>> "STLport is binary incompatible with the default libCstd. If you use the STLport implementation of the standard library, then you must compile and link all files, including third-party libraries, with the option -library=stlport4”
> It means we can only use header-only parts of the standard library.
> This was confirmed / suggested by the Studio folks Erik consulted,
> providing such limited access while continuing to constrain our
> dependency on the library. Figuring out what can be used will need to
> be determined on a case-by-case basis. Maybe we could just link with
> a standard library on Solaris too. So far as I can tell, Solaris is
> the only platform where we don't do that. But Erik is trying to be
>> There are lots of other comments in that document regarding STLport that makes me think that using it may be introducing a fragile dependency into the OpenJDK code!
>> "STLport is an open source product and does not guarantee compatibility across different releases. In other words, compiling with a future version of STLport may break applications compiled with STLport 4.5.3. It also might not be possible to link binaries compiled using STLport 4.5.3 with binaries compiled using a future version of STLport."
>> "Future releases of the compiler might not include STLport4. They might include only a later version of STLport. The compiler option -library=stlport4 might not be available in future releases, but could be replaced by an option referring to a later STLport version."
>> None of that sounds very good to me.
> I don't see how this is any different from any other part of the
> process for using a different version of Solaris Studio.
> stlport4 is one of the three standard libraries that are presently
> included with Solaris Studio (libCstd, stlport4, gcc). Erik asked the
> Studio folks which to use (for the purposes of our present project, we
> don't have any particular preference, so long as it works), and
> stlport4 seemed the right choice (libCstd was, I think, described as
> "ancient"). Perhaps more importantly, we already use stlport4,
> including linking against it, for gtest builds. Mixing two different
> standard libraries seems like a bad idea...
>>> Webrev for jdk10-hs top level repository:
>>> Webrev for jdk10-hs hotspot repository:
>>> Testing: JPRT.
>>> Will need a sponsor.
More information about the hotspot-dev