- Drop first and second patches (already in version)
- Retrieve third patch from upstream
- Retrieve an additionnal patch from upstream
- host-gettext is needed for AM_ICONV since
0512f6d0a0
- Update indentation of hash file (two spaces)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
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>
python-jedi bundles its own copy of typeshed since version 0.14.0 and
7d2b7bb3c1
So add it to the license files (and update indentation of hash file to
two spaces while at it)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Notice: 5.5.x is now EOL, so should be dropped at the next version bump.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
[yann.morin.1998@free.fr: two spaces in hash file]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Some users may require the full JDK on the target to debug their programs.
This change is relatively trivial to add.
While the full JDK does have programs used for compiling on a target,
which is against Buildroot policy, the JDK also has several utilities used for
debugging purposes, which the JRE target does not build, and Buildroot supports
applications used for debugging purposes such as GDB.
As such, JDK support should be available for debugging purposes, and a note in
the Config.in file has been added under the JDK section, which informs the user
that JDK support is for debugging purposes only and that developing on a
target is not supported by Buildroot.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Reviewed-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
Tested-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
[yann.morin.1998@free.fr:
- s/OPENJDK_INSTALL_DIR/OPENJDK_VARIANT/
- slightly rewrap help text
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Several directories and files are currently not installed during the
target installation, these include:
- conf
Several configuration files, including security configuration files which
may be necessary for running various java applications.
- legal
This directory contains legal notices that some java applications may
require, as they may print legal information and will throw exceptions at
runtime if the legal files are not present on the system.
- release
This file contains a list of modules included in the image.
Because these directories take up less than of megabyte extra, it is not an
issue to install all of them.
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Reviewed-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
Tested-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Currently, Buildroot installs the jre libraries using
cp -dprf /build/linux-*-release/images/jre/lib/* $(TARGET_DIR)/usr/lib/
However, if a system has a merged /usr directory, and there is a built kernel
before installing OpenJDK, the installation fails because jre/lib has binary
modules file, which causes the following error: cp: cannot overwrite directory
'/usr/lib/modules with non-directory
The obvious fix is to install the modules to /usr/lib/jvm/ and set the
appropriate rpaths via the --with-extra-ldflags conf option. However, this fix
does not work because the built binaries themselves do not link against
libjava.so
Indeed, running readelf on the built java binary reports the following:
"(RUNPATH) Library runpath: [/usr/lib/jvm]" and /usr/lib/jvm/libjava.so exists.
However, when running the Java binary on the target, the following error
occurs: "Error: could not find libjava.so."
The following is the result of "strace java" ran on the target:
faccessat(AT_FDCWD, "/usr/lib/libjava.so", F_OK) = -1 ENOENT
faccessat(AT_FDCWD, "/usr/jre/lib/libjava.so", F_OK) = -1 ENOENT
newfstatat(AT_FDCWD, "/usr/lib/libjava.so", 0x7ffe7b4af8, 0) = -1 ENOENT
newfstatat(AT_FDCWD, "/usr/lib/jvm/libjli.so", [sic] AT_SYMLINK_NOFOLLOW) = 0
As seen above, the java binary searches for libjli.so in /usr/lib/jvm,
which demonstrates that the java binary searches for some of the
DT_NEEDED libraries using the correct rpath. But libjava.so is not
searched from the rpath; it is instead dl-opened manually, looked for in
the search paths hardcoded to the following directories:
- /usr/lib/
- /usr/jre/lib/
- $(dirname $0)/../lib/
The reason behind the hardcoded paths given by the maintainers is due to
historical purposes for the need to support several java versions at the
same time on a single system, and that changing the above behavior is not
likely to ever happen.
As such, most distributions such as Redhat do the following:
- Create the directory /usr/lib/jvm/java-$(JAVA_VERSION)/
- Install all directories and files found in images/jre to that directory.
- Symlink the binaries to in /usr/lib/jvm/java-$(JAVA_VERSION)/bin to
/usr/bin.
However, because Buildroot does not need to support multiple versions of java
concurrently, there is no need for the additional java-$(JAVA_VERSION)
directory.
To fix the above issue, the following changes are performed:
- Introduce the variable "OPENJDK_INSTALL_BASE" which points to /usr/lib/jvm
- Set the --with-extra-ldflags conf_opt to
"-Wl,-rpath,$(OPENJDK_INSTALL_BASE)/lib,-rpath,
$(OPENJDK_INSTALL_BASE)/lib/$(OPENJDK_JVM_VARIANT)"
- Run "mkdir -p $(TARGET_DIR)/usr/lib/jvm/" in the INSTALL_TARGET_CMDS step.
- Copy both the lib and bin directories to /usr/lib/jvm/
- Symlink the binaries in /usr/lib/jvm/bin/ to /usr/bin.
Fixes: https://bugs.busybox.net/show_bug.cgi?id=12751
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
Reviewed-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
Tested-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
[yann.morin.1998@free.fr: fix two remaining mis-placed '/']
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Prior to commit 4102db0f7a ("package/libglib2: bump to version 2.60.3")
which converted libglib2 to meson, Buildroot used to set a range of
autoconf options to bypass tests that require running binaries.
The meson version of libglib2's build system has many fewer of these
checks, but there are still some and these can be fed the "correct"
answer by adding properties to cross-compilation.conf.
Add the necessary properties to indicate that we have C99 compliant
print functions to avoid pulling in the gnulib fallback.
Signed-off-by: John Keeping <john@metanate.com>
Reviewed-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This version includes a new binary named "ualpn", a proxying
ACMEv2 tls-alpn-01 responder.
Signed-off-by: Nicola Di Lieto <nicola.dilieto@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This fixes CVE-2020-1967:
Server or client applications that call the SSL_check_chain() function during
or after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a
result of incorrect handling of the "signature_algorithms_cert" TLS extension.
The crash occurs if an invalid or unrecognised signature algorithm is received
from the peer. This could be exploited by a malicious peer in a Denial of
Service attack. OpenSSL version 1.1.1d, 1.1.1e, and 1.1.1f are affected by this
issue. This issue did not affect OpenSSL versions prior to 1.1.1d.
See https://www.openssl.org/news/secadv/20200421.txt
Also update the hash file to the new two spaces convention
Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
yaml-cpp builds only a static library by default, this will raise a
build failure with upcoming mongodb 4.2.x as reported by Ryan Barnett
due to mongodb linking with a static library that obviously will miss
-fPIC
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 791292c48d forgot to add
!BR2_PACKAGE_PYTHON dependency, without it the following error will be
raised if the user selects BR2_PACKAGE_PYTHON and python-selinux:
WARNING: unmet direct dependencies detected for BR2_PACKAGE_PYTHON3
Depends on [n]: !BR2_PACKAGE_PYTHON [=y] && BR2_USE_WCHAR [=y] && BR2_USE_MMU [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && !BR2_STATIC_LIBS [=n]
Selected by [y]:
- BR2_PACKAGE_SELINUX_PYTHON [=y] && BR2_USE_MMU [=y] && BR2_USE_WCHAR [=y] && BR2_TOOLCHAIN_HAS_THREADS [=y] && !BR2_STATIC_LIBS [=n]
Fixes:
- No autobuilder failures yet
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[yann.morin.1998@free.fr: add dependency on MMU]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Also:
* Drop patch 0001 (fix static linking of libmagic) applied upstream
* Add optional dependency on libmatroska
* Add upstream patch to fix building with libmatroska
* Adjust spacing in hash file to 2 spaces
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
