package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
################################################################################
|
|
|
|
|
#
|
|
|
|
|
# openjdk
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
package/{openjdk, openjdk-bin}: add support for building either lts or latest
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>
2020-04-22 21:21:18 +02:00
|
|
|
ifeq ($(BR2_OPENJDK_VERSION_LATEST),y)
|
package/openjdk{, -bin}: bump latest to version 16.0.1+9
When introducing OpenJDK to buildroot, the OpenJDK project did not put
releases on their GitHub page. Since then, the OpenJDK developers have
not only added OpenJDK releases to Github, they are starting to phase
out adding releases to their public-facing mercurial repository.
Compare the following URLs:
https://wiki.openjdk.java.net/display/JDKUpdates/JDK+14u
https://wiki.openjdk.java.net/display/JDKUpdates/JDK+15u
https://wiki.openjdk.java.net/display/JDKUpdates/JDK+16u
With JDK14, only the mercurial repository is listed. With OpenJDK15,
both the GitHub and mercurial repository are listed. Finally, with
OpenJDK16, only the GitHub repository is listed.
For consistency's sake, and for the version bump of JDK latest from 14
to 16 do the following:
- Change the repository for OpenJDK14 to point to the official GitHub
repository,
- In order to simplify and reuse the GitHub URL, modify the
OPENJDK_VERSION_MAJOR and OPENJDK_VERSION_MINOR definitions to only
include a single number for the MAJOR definition.
- Change openjdk-bin.mk to also use the same format as the openjdk.mk
file
Unfortunately, we can't yet do the switch for OpenJDK11: the Github
repository is missing a Mercurial-related file, so that the archive
for OpenJDK11 11.0.11+9 would change from the one we already have on
s.b.o and that people would alreay have locally, and we'd have a hash
mismatch, either on master, or on all pur previous relases. OpenJDK11
just got a new release mere hours ago (as of this writing), but it
hasn't yet trickled down to AdoptOpenJDK/openjdk11-binaries, so we
can't do the bump just yet...
Add a note to the OpenJDK11 case, to prepare the migration to Github
with the next version bump.
Finally, remove upstreamed patch 0001-fix-gcc-10-support.patch as it's
no longer needed.
Signed-off-by: Adam Duskett <aduskett@gmail.com>
[yann.morin.1998@free.fr:
- meld the github switch and 14->16 bump together
- drop the github switch for 11 9because hash mismatch)
- expand commit log accordingly
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-05-04 23:00:25 +02:00
|
|
|
OPENJDK_VERSION_MAJOR = 16
|
|
|
|
|
OPENJDK_VERSION_MINOR = 0.1+9
|
package/{openjdk, openjdk-bin}: add support for building either lts or latest
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>
2020-04-22 21:21:18 +02:00
|
|
|
else
|
package/openjdk: fully switch to Github, commonalise version scheme
Commit 057e27029c98 (package/openjdk{, -bin}: bump latest to version
16.0.1+9) partially switched over to using the Github repository (which
is the new official publication channel for OpenJDK).
However, only the JDK16 was switched, because of concerns about a change
in the hash of Github-generated archives for the JDK11, due to a missing
Hg-related file on Github.
But as Arnout put it:
There's a trivial workaround: drop OPENJDK_SOURCE = .... That way,
the tarball name becomes openjdk-... instead of jdk-... and it's a
different file.
There is indeed no good reason to force a non-default filename for the
archive, so we do drop it.
As a consequence, we can fully switch over to Github for openjdk, using
the new version scheme. Of course the hash changes, but it is a new
file, so that's OK.
The filename for the JDK16 changes, but the content does not change, so
the hash does not change.
For consistency, the version scheme is also applied to openjdk-bin. Even
though it was already using Github, using that new version scheme also
allows to commonalise the variables too. The archives are the exact
same: no change in filename or content, so no hash to fixup.
Reported-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
cc: Adam Duskett <aduskett@gmail.com>
Tested-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-05-06 21:48:25 +02:00
|
|
|
OPENJDK_VERSION_MAJOR = 11
|
|
|
|
|
OPENJDK_VERSION_MINOR = 0.11+9
|
package/{openjdk, openjdk-bin}: add support for building either lts or latest
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>
2020-04-22 21:21:18 +02:00
|
|
|
endif
|
package/openjdk: fully switch to Github, commonalise version scheme
Commit 057e27029c98 (package/openjdk{, -bin}: bump latest to version
16.0.1+9) partially switched over to using the Github repository (which
is the new official publication channel for OpenJDK).
However, only the JDK16 was switched, because of concerns about a change
in the hash of Github-generated archives for the JDK11, due to a missing
Hg-related file on Github.
But as Arnout put it:
There's a trivial workaround: drop OPENJDK_SOURCE = .... That way,
the tarball name becomes openjdk-... instead of jdk-... and it's a
different file.
There is indeed no good reason to force a non-default filename for the
archive, so we do drop it.
As a consequence, we can fully switch over to Github for openjdk, using
the new version scheme. Of course the hash changes, but it is a new
file, so that's OK.
The filename for the JDK16 changes, but the content does not change, so
the hash does not change.
For consistency, the version scheme is also applied to openjdk-bin. Even
though it was already using Github, using that new version scheme also
allows to commonalise the variables too. The archives are the exact
same: no change in filename or content, so no hash to fixup.
Reported-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
cc: Adam Duskett <aduskett@gmail.com>
Tested-by: Adam Duskett <Aduskett@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-05-06 21:48:25 +02:00
|
|
|
OPENJDK_VERSION = $(OPENJDK_VERSION_MAJOR).$(OPENJDK_VERSION_MINOR)
|
|
|
|
|
OPENJDK_SITE = $(call github,openjdk,jdk$(OPENJDK_VERSION_MAJOR)u,jdk-$(OPENJDK_VERSION))
|
package/{openjdk, openjdk-bin}: add support for building either lts or latest
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>
2020-04-22 21:21:18 +02:00
|
|
|
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
OPENJDK_LICENSE = GPL-2.0+ with exception
|
|
|
|
|
OPENJDK_LICENSE_FILES = LICENSE
|
2020-06-16 02:12:43 +02:00
|
|
|
OPENJDK_INSTALL_STAGING = YES
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
|
|
|
|
|
# OpenJDK requires Alsa, cups, and X11 even for a headless build.
|
|
|
|
|
# host-zip is needed for the zip executable.
|
|
|
|
|
OPENJDK_DEPENDENCIES = \
|
2019-06-01 18:06:20 +02:00
|
|
|
host-gawk \
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
host-openjdk-bin \
|
|
|
|
|
host-pkgconf \
|
|
|
|
|
host-zip \
|
|
|
|
|
host-zlib \
|
|
|
|
|
alsa-lib \
|
|
|
|
|
cups \
|
|
|
|
|
fontconfig \
|
|
|
|
|
giflib \
|
|
|
|
|
jpeg \
|
|
|
|
|
lcms2 \
|
|
|
|
|
libpng \
|
|
|
|
|
libusb \
|
2019-03-22 15:19:54 +01:00
|
|
|
xlib_libXrandr \
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
xlib_libXrender \
|
|
|
|
|
xlib_libXt \
|
|
|
|
|
xlib_libXtst \
|
|
|
|
|
zlib
|
|
|
|
|
|
|
|
|
|
# JVM variants
|
|
|
|
|
ifeq ($(BR2_PACKAGE_OPENJDK_JVM_VARIANT_CLIENT),y)
|
2019-04-17 16:33:25 +02:00
|
|
|
OPENJDK_JVM_VARIANT = client
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
endif
|
|
|
|
|
ifeq ($(BR2_PACKAGE_OPENJDK_JVM_VARIANT_SERVER),y)
|
2019-04-17 16:33:25 +02:00
|
|
|
OPENJDK_JVM_VARIANT = server
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
endif
|
2019-02-26 18:36:45 +01:00
|
|
|
ifeq ($(BR2_PACKAGE_OPENJDK_JVM_VARIANT_ZERO),y)
|
2019-04-17 16:33:25 +02:00
|
|
|
OPENJDK_JVM_VARIANT = zero
|
2019-02-26 18:36:45 +01:00
|
|
|
OPENJDK_DEPENDENCIES += libffi
|
|
|
|
|
endif
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
|
2020-04-18 21:07:01 +02:00
|
|
|
ifeq ($(BR2_PACKAGE_OPENJDK_FULL_JDK),y)
|
|
|
|
|
OPENJDK_VARIANT = jdk
|
|
|
|
|
OPENJDK_MAKE_TARGET = jdk-image
|
|
|
|
|
else
|
|
|
|
|
OPENJDK_VARIANT = jre
|
|
|
|
|
OPENJDK_MAKE_TARGET = legacy-jre-image
|
|
|
|
|
endif
|
|
|
|
|
|
package/openjdk: fix installation with merged usr directories
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>
2020-04-18 21:06:59 +02:00
|
|
|
# OpenJDK installs a file named 'modules' in jre/lib, which gets installed as
|
|
|
|
|
# /usr/lib/modules. However, with a merged /usr, this conflicts with the
|
|
|
|
|
# directory named 'modules' installed by the kernel. If OpenJDK gets built
|
|
|
|
|
# after the kernel, this manifests itself with: "cp: cannot overwrite
|
|
|
|
|
# directory '/usr/lib/modules with non-directory."
|
|
|
|
|
OPENJDK_INSTALL_BASE = /usr/lib/jvm
|
|
|
|
|
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
# OpenJDK ignores some variables unless passed via the environment.
|
|
|
|
|
# These variables are PATH, LD, CC, CXX, and CPP.
|
|
|
|
|
# OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
|
|
|
|
|
# arguments during the linking process, which causes compilation failures.
|
|
|
|
|
# To fix this issue, LD is set to point to gcc.
|
|
|
|
|
OPENJDK_CONF_ENV = \
|
|
|
|
|
PATH=$(BR_PATH) \
|
|
|
|
|
CC=$(TARGET_CC) \
|
|
|
|
|
CPP=$(TARGET_CPP) \
|
|
|
|
|
CXX=$(TARGET_CXX) \
|
|
|
|
|
LD=$(TARGET_CC) \
|
|
|
|
|
BUILD_SYSROOT_CFLAGS="$(HOST_CFLAGS)" \
|
|
|
|
|
BUILD_SYSROOT_LDFLAGS="$(HOST_LDFLAGS)"
|
|
|
|
|
|
|
|
|
|
OPENJDK_CONF_OPTS = \
|
|
|
|
|
--disable-full-docs \
|
|
|
|
|
--disable-hotspot-gtest \
|
|
|
|
|
--disable-manpages \
|
|
|
|
|
--disable-warnings-as-errors \
|
|
|
|
|
--enable-headless-only \
|
|
|
|
|
--enable-openjdk-only \
|
|
|
|
|
--enable-unlimited-crypto \
|
|
|
|
|
--openjdk-target=$(GNU_TARGET_NAME) \
|
package/openjdk-bin: install to host/usr/lib/jvm
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>
2020-06-17 23:55:20 +02:00
|
|
|
--with-boot-jdk=$(HOST_OPENJDK_BIN_ROOT_DIR) \
|
2020-02-02 21:39:31 +01:00
|
|
|
--with-stdc++lib=dynamic \
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
--with-debug-level=release \
|
|
|
|
|
--with-devkit=$(HOST_DIR) \
|
|
|
|
|
--with-extra-cflags="$(TARGET_CFLAGS)" \
|
|
|
|
|
--with-extra-cxxflags="$(TARGET_CXXFLAGS)" \
|
package/openjdk: fix installation with merged usr directories
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>
2020-04-18 21:06:59 +02:00
|
|
|
--with-extra-ldflags="-Wl,-rpath,$(OPENJDK_INSTALL_BASE)/lib,-rpath,$(OPENJDK_INSTALL_BASE)/lib/$(OPENJDK_JVM_VARIANT)" \
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
--with-giflib=system \
|
|
|
|
|
--with-jobs=$(PARALLEL_JOBS) \
|
2019-04-17 16:33:25 +02:00
|
|
|
--with-jvm-variants=$(OPENJDK_JVM_VARIANT) \
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
--with-lcms=system \
|
|
|
|
|
--with-libjpeg=system \
|
|
|
|
|
--with-libpng=system \
|
|
|
|
|
--with-zlib=system \
|
|
|
|
|
--with-native-debug-symbols=none \
|
|
|
|
|
--without-version-pre \
|
|
|
|
|
--with-sysroot=$(STAGING_DIR) \
|
|
|
|
|
--with-version-build="$(OPENJDK_VERSION_MAJOR)" \
|
|
|
|
|
--with-version-string="$(OPENJDK_VERSION_MAJOR)"
|
|
|
|
|
|
2019-03-15 21:52:32 +01:00
|
|
|
# If building for AArch64, use the provided CPU port.
|
|
|
|
|
ifeq ($(BR2_aarch64),y)
|
2019-03-22 15:19:54 +01:00
|
|
|
OPENJDK_CONF_OPTS += --with-abi-profile=aarch64
|
2019-03-15 21:52:32 +01:00
|
|
|
endif
|
|
|
|
|
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
ifeq ($(BR2_CCACHE),y)
|
|
|
|
|
OPENJDK_CONF_OPTS += \
|
|
|
|
|
--enable-ccache \
|
|
|
|
|
--with-ccache-dir=$(BR2_CCACHE_DIR)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# Autogen and configure are performed in a single step.
|
|
|
|
|
define OPENJDK_CONFIGURE_CMDS
|
|
|
|
|
chmod +x $(@D)/configure
|
|
|
|
|
cd $(@D); $(OPENJDK_CONF_ENV) ./configure autogen $(OPENJDK_CONF_OPTS)
|
|
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
# Make -jn is unsupported. Instead, set the "--with-jobs=" configure option,
|
|
|
|
|
# and use $(MAKE1).
|
|
|
|
|
define OPENJDK_BUILD_CMDS
|
2020-04-18 21:07:01 +02:00
|
|
|
$(TARGET_MAKE_ENV) $(OPENJDK_CONF_ENV) $(MAKE1) -C $(@D) $(OPENJDK_MAKE_TARGET)
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
# Calling make install always builds and installs the JDK instead of the JRE,
|
|
|
|
|
# which makes manual installation necessary.
|
|
|
|
|
define OPENJDK_INSTALL_TARGET_CMDS
|
package/openjdk: fix installation with merged usr directories
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>
2020-04-18 21:06:59 +02:00
|
|
|
mkdir -p $(TARGET_DIR)$(OPENJDK_INSTALL_BASE)
|
2020-04-18 21:07:01 +02:00
|
|
|
cp -dpfr $(@D)/build/linux-*-release/images/$(OPENJDK_VARIANT)/* \
|
package/openjdk: fix installation with merged usr directories
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>
2020-04-18 21:06:59 +02:00
|
|
|
$(TARGET_DIR)$(OPENJDK_INSTALL_BASE)/
|
|
|
|
|
cd $(TARGET_DIR)/usr/bin && ln -snf ../..$(OPENJDK_INSTALL_BASE)/bin/* .
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
endef
|
|
|
|
|
|
2020-06-16 02:12:43 +02:00
|
|
|
define OPENJDK_INSTALL_STAGING_CMDS
|
|
|
|
|
mkdir -p $(STAGING_DIR)/usr/include/jvm
|
|
|
|
|
cp -dpfr $(@D)/build/linux-*-release/jdk/include/* \
|
|
|
|
|
$(STAGING_DIR)/usr/include/jvm
|
|
|
|
|
endef
|
|
|
|
|
|
2020-04-18 21:07:01 +02:00
|
|
|
# Demos and includes are not needed on the target
|
|
|
|
|
ifeq ($(BR2_PACKAGE_OPENJDK_FULL_JDK),y)
|
|
|
|
|
define OPENJDK_REMOVE_UNEEDED_JDK_DIRECTORIES
|
|
|
|
|
$(RM) -r $(TARGET_DIR)$(OPENJDK_INSTALL_BASE)/include/
|
|
|
|
|
$(RM) -r $(TARGET_DIR)$(OPENJDK_INSTALL_BASE)/demo/
|
|
|
|
|
endef
|
|
|
|
|
OPENJDK_TARGET_FINALIZE_HOOKS += OPENJDK_REMOVE_UNEEDED_JDK_DIRECTORIES
|
|
|
|
|
endif
|
|
|
|
|
|
package/openjdk: new package
OpenJDK is a free and open-source implementation of the Java Platform.
This package provides the option to build a client or a server JVM
interpreter.
The default option is the server option, as that is what the majority
of users use. This JVM interpreter loads more slowly, putting more
effort into JIT compilations to yield higher performance.
Unlike most autotools packages, OpenJDK is exceptionally different and
has many quirks, some of which are below:
- X11, alsa, and cups are required to build Java, even if it's a headless build.
See
http://hg.openjdk.java.net/jdk10/jdk10/raw-file/tip/common/doc/building.html#external-library-requirements
for more information.
- host-zip is needed for the zip executable.
- There is no autogen.sh file, instead, a user must call "./configure
autogen."
- OpenJDK ignores some variables unless passed via the environment.
These variables are: PATH, LD, CC, CXX, and CPP.
- OpenJDK defaults ld to the ld binary but passes -Xlinker and -z as
arguments during the linking process, which causes linking failures.
To fix this issue, ld is set to gcc.
- Make -jn is unsupported. Instead, one must use the "--with-jobs="
configure option, and use $(MAKE1).
Signed-off-by: Adam Duskett <Aduskett@gmail.com>
[Thomas:
- drop explanations about CC, LD, CXX, etc. be set to their "actual
binaries" instead of ccache: TARGET_CC/TARGET_LD/TARGET_CXX point
to the compiler wrapper, so the usage of ccache is hidden
- make sure at least one of the variants is enabled in Config.in
- drop the submenu for variant selection
- use system zlib instead of the bundled one. This works fine when
BUILD_SYSROOT_CFLAGS and BUILD_SYSROOT_LDFLAGS are passed
- fix minor nits in the Config.in comments]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-03-15 21:52:31 +01:00
|
|
|
$(eval $(generic-package))
|
