Buildroot currently installs openjdk-bin to $(HOST_DIR)/ instead of the more
traditional (for java installations) $(HOST_DIR)/usr/lib/jvm.
As described in https://bugs.busybox.net/show_bug.cgi?id=13001
"Openjdk-bin provides it's own libfreetype.so and places it into
$(HOST_DIR)/lib/. This library causes build failures with the
host-xapp_mkfontscale package due to the overwritten libfreetype.so.
mkfontscale.o: In function `doDirectory':
mkfontscale.c:(.text+0x1a80): undefined reference to `FT_Get_BDF_Property'
collect2: error: ld returned 1 exit status
Reproducing the error is done by repeating the following steps.
make host-freetype
make host-openjdk-bin
make host-xapp_mkfontscale"
There are two options for fixing this problem:
1) add host-freetype and host-lksctp-tools as dependencies to host-openjdk-bin
and then remove the provided libfreetype.so and libsctp.so libraries
in a post_extract_hook.
2) change the installation directory from $(HOST_DIR)/ to
$(HOST_DIR)/usr/lib/jvm just like the target OpenJDK package and
copy the entire source directories contents to the above location.
The second option provides the following advantages:
- the directory structure is consistent with how we handle the target OpenJDK.
- the HOST_OPENJDK_BIN_INSTALL_CMDS step is simplified.
- packages such as Maven require directories of which we are currently not
copying. These missing directories cause programs such as Maven to crash
when running with an error such as
"Can't read cryptographic policy directory: unlimited."
- does not miss any other libraries that solution 1 would not cope with
(e.g. libzip.so from host-libzip, or libnet.so from not-yet existing
host-libnet, or libsctp.so from not-yet existing host-lksctp-tools)
Because the second option is both simple, easier to implement, is low-impact,
and fixes the problems described above wholly, it is the best to implement.
To implement the above changes, we must also modify the following files in the
same patch to match the host's new directory paths:
- openjdk.mk
- openjdk-jni-test.mk
- openjdk-hello-world.mk
To avoid having to change all those packages in the future, expose two
new variables, HOST_OPENJDK_BIN_ROOT_DIR which contains the path where
the openjdk-bin was installed in, and JAVAC, which contains the path to
the javac compiler (modeled after the way the autoconf et al. variables
are set and exposed).
Tested with:
./support/testing/run-tests -o out -d dl tests.package.test_openjdk.TestOpenJdk
Fixes: https://bugs.busybox.net/show_bug.cgi?id=13001
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[yann.morin.1998@free.fr:
- introduce HOST_OPENJDK_BIN_ROOT_DIR and JAVAC
- expand and tweak the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As Java is used quite a bit in the enterprise world, having the option to
build the LTS version of OpenJDK is quite convenient and also a requirement
for many companies wanting to use Java.
As such, there are three options:
1) Continue only to support the latest version of OpenJDK.
2) Downgrade our existing OpenJDK package from 14 to 11.
3) Add an option to support either OpenJDK 11 or 14.
OpenJDK 11 and 14 currently have:
- The same configure options.
- The same license files and hashes for those license files.
- The same dependencies.
- The same method to build and install.
As such, supporting both 11 and 14 is not only an easy option to add to
Buildroot, but also a nice feature for users who wish to use Java in an
embedded environment with a company that mandates the use of the LTS version.
To make it explicit that this choice really is about LTS vs. latest, and
not about 11 vs. 14, the options are really named with LTS and LATEST,
so that future defconfigs will not have to migrate when the versions
changes (e.g. we update from 14->15, or from 11 to the next LTS).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[yann.morin.1998@free.fr:
- keep latest as the default, for existing defconfigs
- rename options: drop numbers, use LTS and LATEST
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Other changes:
- Add --with-stdc++lib=dynamic to openjdk.mk or else openjdk will fail to
build because it defaults to looking for a static libstdc++ library.
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes the following security issues:
CVE-2019-7317 CVE-2019-2821 CVE-2019-2769 CVE-2019-2762 CVE-2019-2745
CVE-2019-2816 CVE-2019-2842 CVE-2019-2786 CVE-2019-2818 CVE-2019-2766
CVE-2019-6129
For details. see the advisory:
https://openjdk.java.net/groups/vulnerability/advisories/2019-07-16
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Arnout: rebase after change of version formatting]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Because one package relies on the other, bump both at the same time.
Other changes:
- Drop --with-cpu-port=aarch64 option as it is no longer a valid option.
(See https://openjdk.java.net/jeps/340)
- Add xlib_libXrandr as a dependency.
Tested with:
./support/testing/run-tests -s -o ./output/ -d dl tests.package.test_openjdk.TestOpenJdk
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Paradoxically, building OpenJDK requires a pre-existing JDK. This
pre-existing JDK is called the "boot JDK."
The boot JDK for building JDK major version N should be a JDK of major
version N-1, so for building JDK11, JDK10 would be needed. This
requirement is an issue when building on most distributions, as the
host JDK tends to be JDK8.
The AdoptOpenJDK project provides binaries that can act as the boot
JDK to build the target JDK, which is what this package provides.
Currently, only a x86_64 host is supported, for two reasons:
1) A 32bit x86 binary distribution is not available from AdoptOpenJDK
2) We didn't had access to a host machine using an architecture other
than x86-64
The provided unpack200 has an invalid RPATH and relies on libzlib.
When host-libzlib runs the install step, the following error is
generated:
*** ERROR: package host-libzlib installs executables without proper RPATH:
*** $(HOST_DIR)/bin/unpack200
Because unpack200 is a deprecated tool, removing it after installation
is safe and fixes the issue.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- fix comments in the code
- use the more usual "cp -dpfr" command to copy files over]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
