OpenJDK 7u and Fedora 17

[Henri Gomez]

I understand you both :-)

Andrew, as distro packager, is rebuilding OpenJDK and package it for
distros he maintain.

So he's sure that stdlibc++ used at runtime will be same as one at
build time and he could even mandate it in its RPM spec file so it
will be installed by yum if not available.

For Oracle, where a binary should match cross distros, there is no
such way to ensure it, hence the static linking, if stdlibc++ is a
piece of "moving" code.

Not a big deal but it should be mentioned somewhere in build
documentation so packagers could do their own choices.

>> For 7 updates? Probably not.
>>
>> See http://markmail.org/message/yqexkr4ty7s4gelz for details. As
>> Kelly
>> said then "It is quite possible that we don't need to static link
>> anything
>> anymore, but that would need to be verified."
>>
>> Not worth the bother from my POV, as it's
>>
>> a) not a bug - it's the intended behavior,
>> b) those who desire not to statically link with libsdtc++ can do so
>> easily,
>> c) it would have to be done and verified on 8 first, and
>> d) 8 is getting a new build system anyway
>>
>> So, in short, there is not much of a point in changing it here now.
>>
>
> The OpenJDK packages in most distributions have been turning off static
> linking for years.  What more verification is needed?
>
> To respond to your points,
>
> a) I presume you mean Oracle's intended behaviour.  Most developers on GNU/Linux would
> not expect static linking to be taking place, as it's not the norm.
> b) This assumes they are a) aware it is happening in the first place and b)
> know how to turn it off.  Neither are that obvious, IMHO.  I believe we
> turned it off initially but then spotted it had regressed again, because
> Fedora moved the static library into its own package.  It's easier
> for Oracle to turn ON static linking for their packages, than it is to
> for users new to OpenJDK to know to install a non-standard package.
> c) This I agree with.  I hadn't realised it was being discussed on 7u and
> not build-dev (now CCed).
> d) I believe the new build system is copying verbatim from the old one
> at present, and comparing resulting images, so I don't see it changing
> as a result of that.
>
> I think the general issue here is we need to consider whether the build defaults
> should remain suited to producing proprietary binaries for Oracle, as they have previously,
> or whether they should instead fit the expected "norm" on the appropriate platform (i.e. how
> the majority of other packages do it).  One of the hurdles in attracting
> new developers to OpenJDK is the ease of initial builds.   I think a good aim
> would be to have it buildable by a simple "configure; make" on a standard install,
> without having to install a mass of non-standard packages or set lots of options.