aboutsummaryrefslogtreecommitdiffstats
path: root/recipes-core
AgeCommit message (Collapse)AuthorFilesLines
2018-10-22openjdk-8: support rm_work disabledAndré Draszik1-0/+1
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>
2018-10-02openjdk-7-common: fix jvm postinst scriptsRichard Leitner1-18/+18
As the JVM postinst scripts fail during rootfs creation we postpone them to the target using the "pkg_postinst_ontarget_" function. Failing the build at failing postinst scripts was intentionally introduced by oe-core. Furthermore remove the no longer needed $D prefixes from those postinst scripts. Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-10-02icedtea: disable error format-overflow for gcc 7Andreas Obergschwandtner2-0/+43
As no patch has been found in debian and hotspot repo for this issue we just disable this warning which was introduced with GCC 7. Also known as: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881824 Signed-off-by: Andreas Obergschwandtner <andreas.obergschwandtner@skidata.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-10-02openjdk-7: merge postinst into openjdk-7-commonRichard Leitner2-101/+99
As openjdk-7-common was the only consumer of openjdk-postinst.inc move it's content and remove openjdk-postinst.inc. Now all files in recipes-core/openjdk are named correctly according to their versions again. Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-10-02openjdk-8: use openjdk-commonRichard Leitner1-6/+1
As openjdk-common.inc now serves all OpenJDK version let openjdk-8-common require it. Furthermore remove the now duplicated lines. Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-10-02openjdk-7: remove version dependent stuff from openjdk-commonRichard Leitner2-37/+38
Move the OpenJDK-7 specific parts from openjdk-common.inc to openjdk-7-common.inc. Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-10-02icedtea7-native: use openjdk_build_helper's ARCH translation functionsRichard Leitner1-39/+3
As the openjdk_build_helper now provides the ARCH translation function use those and drop the local ones. Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-10-02openjdk-7: use openjdk_build_helper's ARCH translation functionsRichard Leitner2-41/+2
As the openjdk_build_helper now provides the ARCH translation function use those and drop the local ones. Furthermore remove the duplicated LLVM_CONFIGURE_ARCH export. Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-10-02openjdk-8: use openjdk_build_helper's ARCH translation functionsRichard Leitner1-40/+3
As the openjdk_build_helper now provides the ARCH translation function use those and drop the local ones. Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-10-02openjdk-8: add aarch32 port 8u172b11André Draszik17-98/+416
Similar to the aarch64 build, we import the specific aarch32 port when building for ARMv7. We also add all the necessary patches to: * compile using gcc v8 * compile against musl This was tested on: * QEMU with cortex A7 emulation (using glibc) * real hardware (using musl) Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-08-21openjdk-8: allow to build client JVM via PACKAGECONFIGAndré Draszik1-0/+2
The aarch32 port will need to unconditionally enable this. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <dev@g0hl1n.net>
2018-08-21openjdk-8: always apply some patchesAndré Draszik2-3/+2
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>
2018-08-21openjdk-8: fix malformed patchesAndré Draszik16-32/+32
git am complains: Warning: commit message did not conform to UTF-8. You may want to amend it after fixing the message, or set the config variable i18n.commitencoding to the encoding your project uses. Not sure what happened there when they were applied to git, they certainly weren't sent like that to the mailing list. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <dev@g0hl1n.net>
2018-08-14openjdk-8: gcc-8 fix #4: undefined behaviour (hotspot)André Draszik11-2/+673
Using gcc-8, Hotspot is being miscompiled, resulting in non- working binaries. The reason is undefined behaviour, which gcc-8 even warns about and errors out. We have so far have taped over those warnings, but it turns out that we simply cannot do that. Add patches to address undefined behaviour causing miscompilation of hotsport. This also means we can remove the -Wno-error=return-type C compiler flag again which was recently added in error in commit 52fb41cec7d5 ("openjdk-8: fix build for gcc8.x") only hiding the compiler warnings/errors that were flagging the incorrect code in the first place. With these patches applied, the openjdk-8 ARM port works again: | RESULTS: | RESULTS - ping.PingTest.test_ping - Testcase 964: PASSED (0.04s) | RESULTS - ssh.SSHTest.test_ssh - Testcase 224: PASSED (0.68s) | RESULTS - java.JavaTest.test_java_exists - Testcase -1: PASSED (0.14s) | RESULTS - java.JavaTest.test_java_jar_comp_mode - Testcase -1: FAILED (5.13s) | RESULTS - java.JavaTest.test_java_jar_int_mode - Testcase -1: PASSED (4.48s) | RESULTS - java.JavaTest.test_java_jar_works - Testcase -1: PASSED (4.44s) | RESULTS - java.JavaTest.test_java_version - Testcase -1: PASSED (3.66s) | RESULTS - javac.JavacTest.test_javac_exists - Testcase -1: PASSED (0.13s) | RESULTS - javac.JavacTest.test_javac_works - Testcase -1: PASSED (30.87s) | SUMMARY: | openjdk-8-test-image () - Ran 9 tests in 50.263s The java.JavaTest.test_java_jar_comp_mode failure can be ignored for now, as that test verifies compiled mode which is not available on arm. The testcase must be fixed instead. (We need to refresh one unrelated existing patch to avoid patch fuzz warnings) Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-08-13openjdk-build-helper: move c compiler flags retrieval to here (from openjdk-8)André Draszik1-41/+4
Icedtea 7 and OpenJDK 7 will need to apply new compiler flags for certain compiler version without breaking support for older (host) compilers. Move here so that the same code can be re-used. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-08-13java.bbclass: move openjdk/icedtea specific code into new classAndré Draszik6-4/+7
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>
2018-08-13openjdk-7: clarify a bitbake warningRichard Leitner1-1/+2
We get a bitbake warning during recipe building complaining about unsupported architectures unconditionally. That check is relevant only for shark builds, so it is quite confusing for non-shark builds. Make the warning conditional on whether shark builds are enabled or not. This is the same patch as the one for openjdk-8 by André Draszik (commit 86c729cb51f880fd5a1ec6485baddfa2bedaa998) Signed-off-by: Richard Leitner <richard.leitner@skidata.com> Acked-by: Henning Heinold <henning@itconsulting-heinold.de>
2018-08-13openjdk-8: update to 8u172b11André Draszik8-90/+75
Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-08-13openjdk-8: gcc-8 fix #3: working binariesAndré Draszik1-1/+1
Similar to the existing gcc-6 and gcc-7 support, we need to add the same specific compiler flags to avoid miscompilation on gcc-8: -fno-lifetime-dse -fno-delete-null-pointer-checks With this, bitbake -c testimage openjdk-8-test-image works again for x86_64 and aarch64: RESULTS: RESULTS - ping.PingTest.test_ping - Testcase 964: PASSED (0.12s) RESULTS - ssh.SSHTest.test_ssh - Testcase 224: PASSED (1.20s) RESULTS - java.JavaTest.test_java_exists - Testcase -1: PASSED (0.15s) RESULTS - java.JavaTest.test_java_jar_comp_mode - Testcase -1: PASSED (41.98s) RESULTS - java.JavaTest.test_java_jar_int_mode - Testcase -1: PASSED (1.76s) RESULTS - java.JavaTest.test_java_jar_works - Testcase -1: PASSED (2.13s) RESULTS - java.JavaTest.test_java_version - Testcase -1: PASSED (1.51s) RESULTS - javac.JavacTest.test_javac_exists - Testcase -1: PASSED (0.11s) RESULTS - javac.JavacTest.test_javac_works - Testcase -1: PASSED (17.64s) SUMMARY: openjdk-8-test-image () - Ran 9 tests in 67.112s openjdk-8-test-image - OK - All required tests passed NOTE: armv5e still doesn't work with gcc v8, and other arches weren't tested. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-08-13openjdk-8: gcc-8 fix #2: silence build warnings/errors (return-type)André Draszik1-0/+1
Similar to the patch just reverted, we silence the build warnings regarding return type of functions, but we only do this for gcc versions where it matters, now that our infrastructure for doing so works again: | <<PKGBUILDDIR>>/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp:223:32: error: control reaches end of non-void function [-Werror=return-type] | #define BREAKPOINT ::breakpoint() | ~~~~~~~~~~~~^~ | <<PKGBUILDDIR>>/hotspot/src/share/vm/utilities/debug.hpp:192:3: note: in expansion of macro 'BREAKPOINT' | BREAKPOINT; \ | ^~~~~~~~~~ | <<PKGBUILDDIR>>/hotspot/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp:197:2: note: in expansion of macro 'ShouldNotReachHere' | ShouldNotReachHere(); | ^~~~~~~~~~~~~~~~~~ etc. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-08-13Revert "openjdk-8: fix build for gcc8.x"André Draszik2-22/+0
This reverts commit 52fb41cec7d5125bb11c718705158696ffef11f8. The change being reverted has two problems: - it still doesn't produce working binaries - compilation on pre-gcc v7 compilers fails (which is relevant for compiling openjdk-8-native, as that uses the build machine's gcc, not yocto's gcc): | At global scope: | cc1plus: error: unrecognized command line option ‘-Wno-stringop-overflow’ [-Werror] | cc1plus: all warnings being treated as errors We now use a different approach to address the issues than that patch, and it is thusly not needed anymore. We fully support gcc < 7 again. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-08-13openjdk-8: gcc-8 fix #1: backport patch to fix misuses of strncpy/strncatAndré Draszik2-0/+182
The original approach doesn't work with all compilers, as not all compilers support the flag used to suppress the warnings / errors. This patch here avoids passing unsupported compiler options into older compilers, and at the same time fixes the bugs, rather than just silencing the compiler. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-08-13openjdk-8: fix infrastructure for version host gcc != cross gcc (again)André Draszik2-25/+33
Building OpenJDK-8 (target) with an older host compiler (gcc < 6) does not work as the build errors with error messages regarding unrecognized gcc command line options. As part of the (cross) build particularly, OpenJDK-8 builds a host tool (adlc) using the host gcc. We have a patch, openjdk8-fix-adlc-flags.patch, that tries to make the adlc build use the correct / intended compiler flags. This doesn't work right now, as that build still sees compiler flags intended for / understood by the gcc version used for the actual cross compile only. The reason is that while we have infrastructure in place to add compiler flags based on the compiler version, we add all of them unconditionally to CFLAGS / CXXFLAGS directly but above patch uses TARGET_CFLAGS / TARGET_CXXFLAGS to filter out unwanted BUILD_CFLAGS / BUILD_CXXFLAGS from CFLAGS / CXXFLAGS, In other words above patch cannot do what it intends to do and all compiler version specific flags (-fno-lifetime-dse & -fno-delete-null-pointer-checks) end up in CFLAGS / CXXFLAGS. So far, this was only affecting people using host gcc < 6, but upcoming patches adding support for gcc >= 8 will add even more compiler flags that even gcc < 7 don't support - it's time to finally address this. We fix the issue by adding the compiler version specific flags to BUILD_CFLAGS / BUILD_CXXFLAGS and TARGET_CFLAGS / TARGET_CXXFLAGS as necessary, so that above patch can work as intended. We now support all necessary combinations: * -native builds * -target builds * host tools built using the native compiler during the -target build A similar but different patch existed here before as commit 6801f6d4e19c ("openjdk-8-common: Fix the issue of building failed adlc on host with gcc < 6") but was reverted subsequently due to reportedly still(?) having (new?) issues with older compilers. This patch here is different from the older patch in that it *doesn't* set the cflags during a python_anonymous() function, and thus it guarantees deterministic execution order. This change here was tested to work using host gcc versions 4.8.4 and 6.3.0 and 7.3.0 Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-08-13openjdk-8: remove superfluous compiler flag (-std=gnu++98)André Draszik1-1/+0
These days, OpenJDK-8 adds this to the build itself, no need to do it again here in the recipe. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-08-13openjdk-8: speed-up do_install() (pack200)André Draszik1-2/+2
We run pack200 sequentially on all found archives, but there doesn't seem to be a reason to do so, the java_get_parallel_make() apperas to be related to compiling java itself, running multiple java applications (pack200) at the same time on the same machine should be possible, otherwise we have a big problem... Just run up to BB_NUMBER_THREADS pack200 processes at the same time to speed up the build. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-08-02ca-certificates-java: update to v20180516André Draszik2-2/+1
This is the latest available version and contains some fixes for Java 10 & Java 11 Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-07-31openjdk-8: 'do_unpack_remove_X11_wrappers' confuses pyro bitbake parserMatthew McClain1-2/+2
When building without X11 support on the sumo or master branches of meta-java with the pyro branch of poky, meta-oe, etc, the recipe fails to parse. Renaming the function to anything else allows the recipe to be parsed. The problem appears to be the word "_remove_". Signed-off-by: Matthew McClain <mmcclain@uplogix.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-07-10openjdk-8: correct the typo mistakefan.xin1-1/+1
Signed-off-by: Fan Xin <fan.xin@jp.fujitsu.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-06-19classpath: harmonise -native and -initial-native recipesAndré Draszik3-59/+51
removing lots of code-duplication Signed-off-by: André Draszik <andre.draszik@jci.com> Tested-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-06-19set SUMMARY instead of DESCRIPTIONAndré Draszik47-48/+48
Short descriptions should go into SUMMARY (DESCRIPTION will get the same value if not set.) Signed-off-by: André Draszik <andre.draszik@jci.com> Tested-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-06-19libecj-bootstrap-native: simplify buildAndré Draszik1-18/+7
Piping 'find' output into multiple files to re-read them seems inelegant and is error prone - just use a pipe with appropriate options instead. This avoids potential problems with funny file names, and now also makes use of BB_NUMBER_THREADS to speed up compilation. This is a better example to copy from now... Signed-off-by: André Draszik <andre.draszik@jci.com> Tested-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-06-19openjdk-8: give downloaded files a more descriptive nameAndré Draszik2-15/+23
Rather than using the HG (mercurial) changeset IDs directly, add a more descriptive part to the file name. This can help with download cache management. Signed-off-by: André Draszik <andre.draszik@jci.com> Tested-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-06-15ca-certificates-java: update SRC_URIRichard Leitner1-1/+1
Debian changed the URI of the ca-certificates-java repository, therfore use the new one. Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-06-15openjdk-8: fix build for gcc8.xRichard Leitner2-0/+22
Currently oe-core/YoctoProject migrated to gcc8.x. This update broke our openjdk-8 and openjre-8 build. This patch avoids this problem by disabling the problematic gcc warnings and errors. Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-06-15openjdk-8: remove redunant FILES_${PN}-dbgWenlin Kang1-29/+0
One recipe should only have one -dbg package, because OE only picks up all .debug file into the last one -dbg package listed in variable PACKAGES. Comments(oe-core's commit a3b000643898d7402b9e57c02e8d10e677cc9722) from Ross Burton as below: "meta: more removals of redunant FILES_${PN}-dbg In some recipes overly-split -dbg packages were merged into PN-dbg. Unless there's a very good reason, recipes should have a single -dev and -dbg package. " Signed-off-by: Wenlin Kang <wenlin.kang@windriver.com> Tested-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-06-15openjdk-8: remove debuglinkWenlin Kang1-0/+16
During openjdk-8 compiling, its debug file is xxx.debuginfo, and it will add libjvm.debuginfo as libjvm.so's debuglink section's file name, this name is different with that we will create and add in splitdebuginfo() of package.bbclass, in oe-core, the debug file name is the same with the corresponding executable file or library file, this will make we can't get symbol information when debug libjvm.so in gdb, so we must remove the previous debuglink before add it if it has existed(if a file has contained the debuglink section, it will not be changed when add again). Signed-off-by: Wenlin Kang <wenlin.kang@windriver.com> Tested-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-06-15jdepend: Retrieve source from Git rather than tarballMike Crowe1-4/+3
When Bitbake downloads jdepend-2.9.1.zip itself and I download https://github.com/clarkware/jdepend/blob/master/dist/jdepend-2.9.1.zip , the calculated hashes don't match the ones included in the recipe. The hashes were last changed in commit dd5c43fca8289b8795a9214aee616775e1493109 on 1st March, but GitHub claims that the file being downloaded was published on 20th January, so I can't explain why they are wrong. Ross Burton has provided a plausible reason in http://lists.openembedded.org/pipermail/openembedded-devel/2017-September/114916.html where he also advocates switching to using Git repositories rather than GitHub-generated tarballs. It seems that we can't really rely on these tarballs to remain unchanged, so let's download the Git hash that corresponds to v2.9.1 instead. This should always remain valid. Cc: André Draszik <andre.draszik@jci.com> Cc: Khem Raj <raj.khem@gmail.com> Cc: Ross Burton <ross.burton@intel.com> Signed-off-by: Mike Crowe <mac@mcrowe.com> Tested-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Richard Leitner <richard.leitner@skidata.com>
2018-06-12ca-certificates-java: add recipe to generate trustStoreAndré Draszik3-0/+214
The OpenJDK-8 package currently comes with a trustStore that was generated at OpenJDK-8-native build time from *all* certificates available in the system, not just from those that are marked as trusted. This isn't right... So this recipe hooks into the ca-certificates package and (re-) creates the Java trustStore based on the certificates trusted by the system, whenever they are updated. This works both at image build time, as well as during runtime on the target. It works by installing a hook into ca-certificates' $SYSROOT/etc/ca-certificates/update.d/ that is passed the added/removed certificates as arguments. That hook is then updating the Java trustStore and storing it in $SYSROOT/etc/ssl/certs/java/cacerts. The whole idea as well as the implementation of the hook is borrowed from debian's ca-certificate-java package, version 20170930 (the latest as of this commit). Looking at the debian package, it appears like the same binary trustStore ($SYSROOT/etc/ssl/certs/java/cacerts) can be used by different versions of Java: * OpenJDK-7, 8, 9 * Oracle Java 7, 8, 9 The Java sources here can be compiled by any compatible Java compiler, but the resulting jar file should only be run by one of the compatible Java versions mentioned above, so as to create a trustStore that can be read by any of the Java versions mentioned above. We try to ensure this using PACKAGE_WRITE_DEPS during image build time, and by trying to find a compatible Java version inside ${libdir_jvm} at runtime both during image build time and on the target. Given there is nothing that we can RDEPENDS on that would satisfy any of the above Java versions (either JDK or JRE), we simply RDEPENDS on java2-runtime, and test PREFERRED_RPROVIDER_java2-runtime to be satisfactory. Given I can only test OpenJDK/OpenJRE 8 at the moment, only those are actually allowed at the moment, though. This can easily be extended upon confirmation. Final note - as per the debian package, there are three cases when we can be called: 1) as part of update-ca-certificates -> add / remove certs as instructed 2) if first time install -> add all certs 3) package update -> do nothing We have no way to easily distinguish between first time install and package update in OE, so the distinction between cases 2) and 3) isn't perfect. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Maxin B. John <maxin.john@intel.com>
2018-06-06icetea7, openjdk-8: Fix depenency to xproto -> xorgprotoJason Wessel3-3/+3
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>
2018-04-09jamvm: refresh patchesMaxin B. John3-21/+47
Fixes this: Some of the context lines in patches were ignored. This can lead to incorrectly applied patches. The context lines in the patches can be updated with devtool: devtool modify <recipe> devtool finish --force-patch-refresh <recipe> <layer_path> Then the updated patches and the source tree (in devtool's workspace) should be reviewed to make sure the patches apply in the correct place and don't introduce duplicate lines (which can, and does happen when some of the context is ignored). Further information: http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450 Details: patching file src/Makefile.am Hunk #1 succeeded at 23 with fuzz 1. Signed-off-by: Maxin B. John <maxin.john@intel.com>
2018-03-15openjdk-8: fix build with --as-needed host toolchains (Ubuntu 16.04)André Draszik2-0/+92
As per the commit message - build on hosts with --as-needed toolchains (Ubuntu 16.04) using system provided zlib fails: If the (host) toolchain has been configured to unconditionally add --as-needed to the linker command line then linking can fail when using system libraries. The reason is that the order of command line arguments becomes important with --as-needed and the JDK build system places needed system libraries at the beginning of the command line where it would normally place the object files from its own bundled compiled version. Having those system libraries early in the command line is not useful, as they are discarded by the linker at that point in time as it hasn't seen any reference to the symbols provided yet. As it seems a generic pattern in the makefiles here, just place the $EXPECTED_OBJS early in the command line, before any additional libraries, so as to fix this once and for all. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Maxin B. John <maxin.john@intel.com>
2018-03-13openjdk-8: fix MAKE detection patchAndré Draszik1-1/+1
The patch had a few typos, leading to errors during ./configure ../jdk8u-4be07cb28b21/common/autoconf/configure: line 8408: test: too many arguments Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Maxin B. John <maxin.john@intel.com>
2018-03-06openjdk-8: add aarch64 supportAndré Draszik7-82/+164
This is using the aarch64 port to make it work, which is at version u161b15. We also add one patch to make this work with musl, too. Because the aarch64 port is fetched from a different repository, the version specific include has been split so as to have all common parts (URIs, patches, configuration bits) in one single file, and version specific bits (checksum, mercurial commit ID), in another file, to ease maintenance, and make distinguishing easier. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Maxin B. John <maxin.john@intel.com>
2018-03-06openjdk-8: fix musl buildAndré Draszik19-4/+1037
Add various patches to make it work in musl. Some of them are generic enough to be applied for all builds, some need to be specific to musl. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Maxin B. John <maxin.john@intel.com>
2018-03-06openjdk-8: stop passing obsolete make variables (freetype)André Draszik1-2/+0
OpenJDK's build system complains about passing in obsolete ALT_ variables. Stop passing in those for freetype, as pkg-config is used to figure out the correct compiler and linker flags. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Maxin B. John <maxin.john@intel.com>
2018-03-06openjdk-8: rename PACKAGECONFIG zip -> zlibAndré Draszik1-2/+2
The existing PACKAGECONFIG option 'zip' affects OpenJDK's usage of zlib, not zip, so this option is a bit inconsistent and confusing. Rename to zlib. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Maxin B. John <maxin.john@intel.com>
2018-03-06openjdk-8: build against system libgif & zlib by defaultAndré Draszik1-1/+1
This should really be the default so as to benefit from CVE fixes etc. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Maxin B. John <maxin.john@intel.com>
2018-03-06openjdk-8-native: really use system libgif & zlibAndré Draszik1-4/+4
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>
2018-03-06openjdk-8: add patches to support building against system libpng & libjpegAndré Draszik5-3/+420
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>
2018-03-06openjdk-8: add patch for compiling with enabled security flagsAndré Draszik3-57/+42
Rather than carrying an OE specific patch that just silences the warning on some platform only, backport the upstream patch to actually fix the issue. Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Maxin B. John <maxin.john@intel.com>