OpenJDK 7u and Fedora 17

[Andrew Hughes]

----- Original Message -----
> 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.
> 

I'm not just a distro packager, but maintainer of IcedTea and an
OpenJDK reviewer.  Most distros (Debian & Ubuntu AFAIK, Gentoo, Fedora
& RHEL for 6 only) use this and thus the build settings it uses.
STATIC_CXX=false has been set since at least March 2011.  I believe it
was disabled by a patch before that but upstream changes meant the patch
didn't work any more.

Your general point is correct, but I think the issue is wider than just
distro packages.  Pretty much everything one would build on a GNU/Linux
system links dynamically, so, in linking statically, OpenJDK is unusual.
Unless the user knows that static linking is taking place, they wouldn't
expect it.  This is demonstrated by the Fedora issue you experienced; static
libstdc++ linking is so uncommon, the library is in a package on its
own so it's not pulled in unless explicitly requested.

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

Indeed.  This is also why in-tree versions of zlib, lcms, libpng, giflib
and libjpeg are used, whereas we use system versions.

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

It's a pretty big deal if it means someone can't build.  That could effectively
dissuade them from getting involved in OpenJDK.

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

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07