Age | Commit message (Collapse) | Author |
|
Now that generation of the Java keystore actually works (again?),
OE-core commit 09bb7718d74 ("ca-certificates: use relative symlinks from $ETCCERTSDIR"),
do_compile() will fail when invoked multiple times.
The reason is that during do_compile(), the Java keytool is
used to create a Java keystore with the certificates provided
by ca-certificates. Before above OE-core commit, no
certificates were actually being added, but as certificates
are being added now, multiple do_compile() runs will end up
adding the same certificate twice when rm_work is disabled,
causing a keytool exception, as that is not allowed.
So let's remove any previously generated keystore before trying
to add certificates to it.
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
|
|
As a simplification for the upcoming aarch32 port.
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Leitner <dev@g0hl1n.net>
|
|
The code moved is not relevant to anything using java, just for
compiling java itself. It doesn't make sense to have here.
Move it into openjdk-build-helper
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
|
|
The latest oe-core has changed the X protocol header provider package
name.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Reviewed-by: Richard Leitner <richard.leitner@skidata.com>
Tested-by: Richard Leitner <richard.leitner@skidata.com>
Signed-off-by: Henning Heinold <henning@itconsulting-heinold.de>
|
|
The intention seems to be to build against above system
libraries, but configure still picked the bundled versions,
even though the libraries are in the sysroot. Make it
deterministic and force use of the system libraries using
PACKAGECONFIG and the appropriate configure arguments.
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Maxin B. John <maxin.john@intel.com>
|
|
This didn't actually before. Patches taken from Debian / OpenJDK-9.
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Maxin B. John <maxin.john@intel.com>
|
|
Solution on how to be able to build openjdk for a build
host that need the environment variable JAVA_TOOL_OPTIONS.
Use JAVA_TOOL_OPTIONS from environment. On some machines this is needed
in order to start java when the amount of RAM is limited for the user.
Author: Peter Bergin <peter.bergin@windriver.com>
Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com>
Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
Without this it fails in do_configure because "comm"
is not found.
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Maxin B. John <maxin.john@intel.com>
|
|
Simplifies duplicated implementation across multiple recipes that all
inherited from java.bbclass.
Previously implementation was not flexible in supporting other make
job-limiting flags (like -l for load) that are typically passed in
through PARALLEL_MAKE. (OpenJDK doesn't know about these other flags
that might have gotten tagged on after the value for -j.)
Signed-off-by: Kyle Russell <bkylerussell@gmail.com>
Signed-off-by: Maxin B. John <maxin.john@intel.com>
|
|
GCC 6 sets the default C++ standard to C++14 and introduces dead store
elimination by default. OpenJDK 8 is not ready for either of these
changes, so set the C++ standard back to gnu++98 and disable dead
store elimination.
Switched to using --with-extra-cflags, cxxflags, and ldflags. The added
patch fixes building when using those flags, and are needed to get
CFLAGS into the JDK build in the native case.
Signed-off-by: Daniel McGregor <daniel.mcgregor@vecima.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
|
|
We had:
virtual/jar-native provided by fastjar-native
virtual/java-native provided by cacao-native and jamvm-native
virtual/javac-native provided by ecj-bootstrap-native
Then openjdk-8-native added and also provides:
virtual/java-native and virtual/javac-native
(it also installs ${STAGING_BINDIR_NATIVE}/jar but
doesn't add virtual/jar-native in the PROVIDES)
which introduces circular dependencies,
java-bootstrap-components.bbclass is to avoid the
circular dependencies but it's not a correct way
since it make two conflicted packages build into
the same sysroot:
DEPENDS_prepend_class-native = " ecj-bootstrap-native "
DEPENDS_prepend_class-target = " virtual/javac-native "
virtual/javac-native is provided by openjdk-8-native,
and it assumed that ecj-bootstrap-native, fastjar-native and
cacao-native/jamvm-native are always built before openjdk-8-native,
then in the do_install of penjdk-8-native, it removes them from
staging dirs first, then install (create symlinks for) these files
in staging dirs directly, which results with empty sstate and
builds from sstate cache or builds not in this assumption
will fail.
The fixes here includes:
- Revert "meta-java: rely on well known bootstrap-path" in
previous commit to remove the improper
java-bootstrap-components.bbclass
- Do not let openjdk-8-native provides jar, java and javac,
just like what we do in icedtea7-native, which can provides
but not to avoid circular dependencies and conflicts.
- make cacao-native back to provide virtual/java-native,
and ecj-bootstrap-native back to provide virtual/javac-native
- Add back provider settings in README.
- Remove the update-alternatives in openjdk-8-native,
it doesn't work for native package.
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
|
|
This adds openjdk-8 for native and target builds and allows a stripped
openjre-8 being built as well instead of trying to cherry-pick jre
components from jdk-image.
The recipes allow building openjdk-8 with or without:
* x11
* cups
* alsa/pulseaudio
and let packager enable unlimited-crypto, if desired.
To support certificate based java libraries, cacerts is created based on
ca-certificates from OE-core.
Since there can be only one PROVIDES for virtual/java-native and virtual/javac-native,
move the provides to openjdk-8-native (I think everyone agrees it's a better
choice than ecj-bootstrap-native).
Plus: Applying a fix from openjdk-9 repository which fixes build issues using gcc5
Signed-off-by: Jens Rehsack <sno@netbsd.org>
Signed-off-by: Maxin B. John <maxin.john@intel.com>
|