This continues #23374, which always kept around both attributes, by
always including both propagated files: `propgated-native-build-inputs`
and `propagated-build-inputs`. `nativePkgs` and `crossPkgs` are still
defined as before, however, so this change should only barely
observable.
This is an incremental step to fully keeping the dependencies separate
in all cases.
* openjdk 8: code cleanup
as recommended by 0xABAB in #27194
* openjdk 9: init at ea build 176
this starts with copy of 8.nix and just updates hashes and replaces 8
with 9. it also tweaks the version handling because we aren't dealing
with an update version yet.
* openjdk 9: adapt patches from openjdk 8
fix-java-home: surrounding code changed slightly
swing-use-gtk-jdk9: location of the file being patched changed due to
modularization
read-truststore-from-env: the code that handles the trustStore was
refactored out into a helper class in upstream commit
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/904861872c0e
adlc_updater: this isn't present anymore
* openjdk 9: make two more warnings-as-errors non-fatal
this requires that we switch to configureFlagsArray to deal with
whitespace
the errors being suppressed are show below:
* For target support_native_java.desktop_libawt_xawt_awt_Robot.o:
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c: In function 'isXCompositeDisplay':
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:152:50: error: embedded '\0' in format
[-Werror=format-contains-nul]
snprintf(NET_WM_CM_Sn, sizeof(NET_WM_CM_Sn), "_NET_WM_CM_S%d\0", screenNumber);
^
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:152:50: error: embedded '\0' in format
[-Werror=format-contains-nul]
cc1: all warnings being treated as errors
* For target support_native_jdk.hotspot.agent_libsa_ps_core.o:
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/hotspot/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c: In function 'read_exec_segments':
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/hotspot/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c:834:7: error: ignoring return value of 'pread', declared
with attribute warn_unused_result [-Werror=unused-result]
pread(ph->core->exec_fd, interp_name, exec_php->p_filesz, exec_php->p_offset);
^
cc1: all warnings being treated as errors
* openjdk 9: ea+176 -> ea+180
* openjdk 9: TODO disable infinality patches, at least to start
the code being patched here seems to have changed substantially or
perhaps even disappeared altogether. need to investigate whether
these patches are still relevant.
* openjdk 9: update installPhase for modularization
* separate jdk and jre images are now present under build/*/images
* samples have been removed (JEP 298)
-- TODO that JEP says demos will be gone too, but it seems some are still present?
* bina directory is no longer present
* openjdk 9: TODO handle *.pf files or purge this code completely
* openjdk 9: update minimal jre components
in particular, the name of the config option for headless has changed,
per https://bugs.openjdk.java.net/browse/JDK-8163102
* TODO about echo -n vs printWords, #27427
As @oxij points out in [1], this breakage is especially serious because
it changes the contents of built environments without a corresonding
change in their hashes. Also, the revert is easier than I thought.
This reverts commit 3cb745d5a6.
[1]: https://github.com/NixOS/nixpkgs/pull/27427#issuecomment-317293040
This makes those files a bit easier to read. Also, for what it's worth,
it brings us one baby step closer to handling spaces in store paths.
Also, I optimized handling of many transitive deps with read. Probably,
not very beneficial, but nice to enforce the pkg-per-line structure.
Doing so let me find much dubious code and fix it.
Two misc notes:
- `propagated-user-env-packages` also needed to be adjusted as
sometimes it is copied to/from the propagated input files.
- `local fd` should ensure that file descriptors aren't clobbered
during recursion.
This makes several adjustments around what is linked into JRE.
* system giflib, libjpeg, zlib are now used unconditionally;
* libstdc++ is linked dynamically.
For full version:
* GTK+ and GNOME libraries are linked;
* Extra X11 libraries are linked;
* CUPS is linked;
* libmagic (file) is linked.
For minimal version:
* All X11 support is removed;
* Sound support is removed.
* Fonts and their support are not lined.
jre8_headless is added as a minimal build.
Overall this adds support for all things GUI into the default Java build and
removes them from the minimal build.
* openjdk: Keep {include,man} in $out/lib/opendjk.
This is a standard layout that some JDK consumers expect.
* openjdk/8: Improve clarity of some symlink commands with terminating slash.
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
This small patch makes it possible to control java's truststore path through
the environment. This lets you add (system- or session-wide) CAs that should
be allowed by Java. Java users can still use -Djavax.net.ssl.truststore to
override the truststore set by JAVAX_NET_SSL_TRUSTSTORE.
Something like this can be used to build the truststore (in this example just
using the standard pkgs.cacert CA-bundle):
{
environment.variables.JAVAX_NET_SSL_TRUSTSTORE = "${
pkgs.runCommand "cacerts" {} ''
${pkgs.perl}/bin/perl \
${pkgs.path}/pkgs/development/compilers/openjdk/generate-cacerts.pl \
${pkgs.jre}/bin/keytool \
${pkgs.cacert}/etc/ca-bundle.crt
mv cacerts $out
''
}";
}
Ideally, the dependency on pkgs.cacert should also be removed from pkgs.openjdk
to avoid rebuilding java each time the standard CA-bundle changes. Something
along the example above must then be added to NixOS (however, it would be
nice to not depend on ${pkgs.jre}/bin/keytool to generate that environment
variable).
HotSpot uses the absolute path of libjvm.so to determine the java.home
property (ignoring $JAVA_HOME), which is in turn used by
ToolProvider.getSystemJavaCompiler() to load tools.jar. So we need to
do some trickery to ensure that if java gets invoked from the jdk
output (ratherthan the jre output), it finds libjvm.so in the jdk output.
