Re: [oe] [meta-java][PATCH v2 2/2] openjdk-8-release-102b14.inc: Ignore deprecation
Hi Maxin, This failure is unrelated to the patch, caused by changes in the oe-core: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a98a8180863ff45b477a1f8439ebcec21151d282 As far as I can tell, the current openjdk version is equally affected. I'll look into fixing the error though. Best Regards, Erkka Kääriä > -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On > Behalf Of Maxin B. John > Sent: Thursday, August 18, 2016 3:27 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [meta-java][PATCH v2 2/2] openjdk-8-release-102b14.inc: > Ignore deprecation > > Hi Erkka, > > On Mon, Aug 15, 2016 at 12:36:20PM +0300, Erkka Kääriä wrote: > > readdir_r has been deprecated since glibc 2.24. As openjdk uses this > > function, a warning is generated during build that gets turned into an > > error when -Werror is used. > > Yes, this fixes the build error that we got with the first version. Thank you! > > However,we are getting another QA Error with the build: > > ERROR: openjre-8-102b14-r0 do_package_qa: QA Issue: No GNU_HASH in > the elf binary: '/media/poky/build/tmp/work/core2-64-poky-linux/openjre- > 8/102b14-r0/packages-split/openjre-8/usr/lib/jvm/openjre- > 8/lib/amd64/libjsig.so' > No GNU_HASH in the elf binary: '/media/poky/build/tmp/work/core2-64- > poky-linux/openjre-8/102b14-r0/packages-split/openjre- > 8/usr/lib/jvm/openjre-8/lib/amd64/server/libjvm.so' [ldflags] > ERROR: openjre-8-102b14-r0 do_package_qa: QA run found fatal errors. > Please consider fixing them. > ERROR: openjre-8-102b14-r0 do_package_qa: Function failed: > do_package_qa > ERROR: Logfile of failure stored in: /media/poky/build/tmp/work/core2-64- > poky-linux/openjre-8/102b14-r0/temp/log.do_package_qa.22839 > ERROR: Task /home/maxin/clone/meta-java/recipes-core/openjdk/openjre- > 8_102b14.bb:do_package_qa (/home/maxin/clone/meta-java/recipes- > core/openjdk/openjre-8_102b14.bb:do_package_qa) failed with exit code '1' > NOTE: Tasks Summary: Attempted 1344 tasks of which 1332 didn't need to be > rerun and 1 failed. > NOTE: Writing buildhistory > > > > Could you please look into this ? > > Best Regards, > Maxin > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-java] Openjdk-8 and D_FORTIFY_SOURCE
Hi,
Currently openjdk-8 fails to build if D_FORTIFY_SOURCE is set through
SECURITY_CFLAGS. This happens, because gcc requires at least -O for this
feature to work. Otherwise a warning is generated ("_FORTIFY_SOURCE requires
compiling with optimization"), which then gets turned into an error by -Werror.
This is easy enough to fix by providing appropriate compiler flags through
EXTRA_OECONF and -with-extra-cflags. The recipe however contains a warning that
adding -with-extra-cflags will break building demos for jdk. Everything seems
to work correctly on my machine even if I add the parameter (package is
generated for demos, no build failures), but I assume that this warning is
there for a reason.
There are few ways of solving this as far as I can see:
1. Just add the -with-extra-cflags and disable demos.
2. Remove D_FORTIFY_SOURCE from SECURITY_CFLAGS
3. Patch the openjdk build files, either removing -Werror or adding -O2
I personally prefer the first solution, as I don't really see any value in
providing demos. The second solution would weaken security, which I'd like to
avoid if at all possible. The third solution on the other hand feels like it's
too hacky-ish for this problem (not to mention that removing -Werror is
basically the same than removing D_FORTIFY_SOURCE).
Best Regards,
Erkka Kääriä
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-java] Sporadic segfaults when compiling jamvm-native and classpath-native
> From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On > Behalf Of Otavio Salvador > Sent: Friday, November 6, 2015 4:40 PM > To: OpenEmbedded Devel List de...@lists.openembedded.org> > Subject: Re: [oe] [meta-java] Sporadic segfaults when compiling jamvm- > native and classpath-native > > On Fri, Nov 6, 2015 at 9:44 AM, Kaaria, Erkka > wrote: > > There seems to be something wrong with cacao-initial-native JIT compiler > that causes sporadic segfaults when compiling jamvm-native or classpath- > native. This is fairly rare, I estimate around 1% of the builds fail due to > segfault. I use 64 bit Ubuntu 15.04 with GCC 4.9.2 as build machine. > > Did you check if cacao-staging tree does not include a fix for it? > Hi, I briefly glanced at the cacao-staging commit history, but I didn't find any patches that would fix this segfault specifically. There are several patches that fix issues and race conditions in the jit compiler, for example https://bitbucket.org/cacaovm/cacao-staging/commits/7e6eef2b4c94 and https://bitbucket.org/cacaovm/cacao-staging/commits/56697326cf27. One of these patches may very well fix the segfault, but the problem is that the cacao version that is used in the bootstrapping process is positively ancient (0.98, released in 2007). The linked patches for example are patching files that are either substantially different from the ones in 0.98 or don't even exist in 0.98. Backporting any patches to would not be easy. While the workaround would leave the underlying cause unfixed, it only requires changing one line. Since the cacao-initial-native is only used briefly during the build process, I think small workaround is better than large scale changes to the old codebase. I also didn't notice any difference in classpath-native or jamvm-native build times, so the performance impact is negligible. On a related note, I ran the clean\recompile script over the weekend and saw no segfaults, so I think the workaround works. Best Regards, Erkka Kääriä - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-java] Sporadic segfaults when compiling jamvm-native and classpath-native
Hi everyone,
There seems to be something wrong with cacao-initial-native JIT compiler that
causes sporadic segfaults when compiling jamvm-native or classpath-native. This
is fairly rare, I estimate around 1% of the builds fail due to segfault. I use
64 bit Ubuntu 15.04 with GCC 4.9.2 as build machine.
Example do_compile log:
make[6]: Entering directory
'/build/tmp/work/x86_64-linux/jamvm-native/1.5.5+1.6.0-devel+gitAUTOINC+ebd11bde0a-r0/build/src/classlib/gnuclasspath/lib'
mkdir classes
LOG: [0x7f32c46a7700] We received a SIGSEGV and tried to handle it, but we
were
LOG: [0x7f32c46a7700] unable to find a Java method at:
LOG: [0x7f32c46a7700]
LOG: [0x7f32c46a7700] PC=0x00440c09
LOG: [0x7f32c46a7700]
LOG: [0x7f32c46a7700] Dumping the current stacktrace:
<>
LOG: [0x7f32c46a7700] Exiting...
Aborted (core dumped)
Makefile:662: recipe for target 'classes.zip' failed
Examination of the core dump in this particular case indicates that the
segfault is caused by null pointer dereference in builtin_new at builtin.c:764:
#5
#6 builtin_new (c=0x0) at builtin.c:764
#7 0x7f23badb5a5f in ?? ()
#8 0x in ?? ()
Gdb is unable to show the calling method, and judging by the fact that the old
instruction pointer does not match any shared library addresses, I think it
originates from JIT compiled code.
This http://c1.complang.tuwien.ac.at/pipermail/cacao/2011-March/001350.html
thread seems to indicate that there could be a race condition in cacao JIT
compiler when multiple Java threads are involved. I forced the ecj to only use
one thread and segfaulting seems to have stopped.
Given the non-deterministic nature of the bug, I am not sure if I actually
managed to fix this or if I have just been lucky. As such, I request help to
a) Verify the presence of the bug
b) Verify that forcing ecj to only use single thread fixes the issue.
Multihreading can be disabled by adding -Djdt.compiler.useSingleThread=true to
the third line in "ecj-initial" script in build/tmp/sysroots//usr/bin/
example line:
${RUNTIME} -Xmx512m -Djdt.compiler.useSingleThread=true -cp ${ECJ_JAR}
org.eclipse.jdt.internal.compiler.batch.Main ${1+"$@"}
Script I use for the recompilation. I usually get a failure within 90 minutes,
but this naturally varies between computers. Run from the build folder
#!/bin/bash
while [ true ]; do
echo $(date)
echo "Cleaning..."
bitbake -c cleansstate jamvm-native > /dev/null
echo "Compiling..."
bitbake -c compile jamvm-native > /dev/null || { echo "Stopping"; exit 1; }
done
Best regards,
Erkka Kääriä
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-java][PATCH 4/4] openjdk-8: add recipes for openjdk-8 and openjre-8
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On > Behalf Of Jens Rehsack > Sent: Friday, October 30, 2015 1:47 PM > To: openembedded-devel@lists.openembedded.org > Subject: Re: [oe] [meta-java][PATCH 4/4] openjdk-8: add recipes for > openjdk-8 and openjre-8 > > > > > Also, the openjdk-8-cross.inc currently uses openjdk-8-native as the > boostrap jdk for the openjkd/openjre-8. The build readme > (http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html) > however suggests that you should use the previous jdk version as the > boostrap jdk and that using openjdk 8 to boostrap openjdk 8 may introduce > unwanted dependencies. Perhaps using icedtea7-native would be better > here? > > openjdk-8-native uses icedtea7-native to bootstrap, openjdk-8 and openjre- > 8 use openjdk-8-native to bootstrap. > Can you explain which unwanted dependency openjdk-8-native might > introduce you don't even have by using icedtea7-native? > > Cheers > -- > Jens Rehsack - rehs...@gmail.com > > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel Hi, I don't know if there are actually any issues when bootstrapping with openjdk-8-native. I just wanted to raise the issue as the openjdk build readme warns against this. Best Regards, Erkka Kääriä - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-java][PATCH 4/4] openjdk-8: add recipes for openjdk-8 and openjre-8
> -Original Message- > From: openembedded-devel-boun...@lists.openembedded.org > [mailto:openembedded-devel-boun...@lists.openembedded.org] On > Behalf Of Jens Rehsack > Sent: Tuesday, October 27, 2015 10:32 PM > To: OE-devel > Subject: [oe] [meta-java][PATCH 4/4] openjdk-8: add recipes for openjdk-8 > and openjre-8 > > > 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. > > 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 > --- > > Jens Rehsack - rehs...@gmail.com > > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel Hi, I tried applying this patch, but openjdk-8 do_fetch task failed due to multiple incorrect checksums (corba, jaxp, jaxws, openjdk). After fixing the checksums manually, openjdk8-fix-shark-build.patch failed due to hotspot/make/Makefile portion not applying. Also, the openjdk-8-cross.inc currently uses openjdk-8-native as the boostrap jdk for the openjkd/openjre-8. The build readme (http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html) however suggests that you should use the previous jdk version as the boostrap jdk and that using openjdk 8 to boostrap openjdk 8 may introduce unwanted dependencies. Perhaps using icedtea7-native would be better here? Best Regards, Erkka Kääriä - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-java] Commit duplication
Hi, There seem to have been a bad merge commit made December 17 2014 (http://git.yoctoproject.org/cgit/cgit.cgi/meta-java/commit/?id=12a0b10b35b1829eec11ea653af53d127a8b6fd1). This commit introduced duplicate commits into the git history (for example, http://git.yoctoproject.org/cgit/cgit.cgi/meta-java/commit/?id=8042dd1f8e3ccee2ddb31e792e3f88c6e2583847 and http://git.yoctoproject.org/cgit/cgit.cgi/meta-java/commit/?id=7b66b4940804b72150b33248b16b582ae6a48751). These duplications are causing issues with certain tools. - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
