libjvm.so, jmods and --with-native-debug-symbols=internal
Omair Majid
omajid at redhat.com
Thu Feb 9 17:41:09 UTC 2017
Hi,
I have been working on building preview versions of OpenJDK 9 for
Fedora. You can see the latest build here:
https://copr.fedorainfracloud.org/coprs/omajid/openjdk9/build/509314/
One thing that I just realized is that we build OpenJDK 9 using the
configure option --with-native-debug-symbols=internal. As far as I
understand the build, this is what happens:
1. libjvm.so is built
2. libjvm.so is not stripped of any debug information
3. a jmod - java.base.jmod - containing libjvm.so is created
4. the jmod containing libjvm.so is extracted to create images/jdk/ (and
images/jre/)
Then the linux packaging tools (rpmbuild in my case) take over and do
the following:
5. strip libjvm.so in images/jdk/, put stripped symbols in a separate
location
6. Package up images/jdk/ into the distribution package
7. make a -debuginfo package (or -dbg in case of Debian) that contains
the stripped symbols from libjvm.so
So now users get a libjvm.so in the default package that's stripped and
less than 20MB. They also get an optional -debuginfo (or -dbg) package
that contains just the debug symbols. This lets them use the small
package containing libjvm and but also lets them download a large
package to debug libjvm.so if they wish. This is all great so far and
works like it should.
One new change that happened with OpenJDK 9 only is that the jmod
(java.base.jmod here) contains the original and unstripped libjvm.so.
This jmod also gets included into the images/jdk/. This bumps up the
images/jdk/jmods directory size to hundreds of megabytes. Anyone who now
wants to use jmods now ends up installing all the unstripped debuginfo,
unintentionally, eating up disk space.
Is this intentional or an unintended side-effect of various changes? Is
it a known issue?
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
More information about the build-dev
mailing list