RFR (2xS): 8181318: Allow C++ library headers on Solaris Studio

David Holmes david.holmes at oracle.com
Thu Jun 1 01:22:31 UTC 2017


Hi Erik,

A small change with big questions :)

On 31/05/2017 11:45 PM, Erik Österlund wrote:
> Hi,
> 
> 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?

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

https://docs.oracle.com/cd/E19205-01/819-5267/bkakg/index.html

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

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.

Cheers,
David


> Webrev for jdk10-hs top level repository:
> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.00/
> 
> Webrev for jdk10-hs hotspot repository:
> http://cr.openjdk.java.net/~eosterlund/8181318/webrev.01/
> 
> Testing: JPRT.
> 
> Will need a sponsor.
> 
> Thanks,
> /Erik



More information about the build-dev mailing list