Summary: | =dev-java/icedtea-7.2.5.4 - Makefile:124: recipe for target '/var/tmp/portage/dev-java/icedtea-7.2.5.4/work/icedtea-2.5.4/openjdk.build-boot/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class' failed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | David Kredba <kredba> |
Component: | [OLD] Java | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ktrackfd, wireless |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Build.log gzipped |
Description
David Kredba
2015-02-26 19:25:27 UTC
Created attachment 397570 [details]
Build.log gzipped
Are you using Hardened? The failure seems to be coming from /sbin/paxctl -m /var/tmp/portage/dev-java/icedtea-7.2.5.4/work/icedtea-2.5.4/openjdk.build-boot/bin/java I am not. "Normal" profile. I saw it but told myself that it can cause troubles on "hardened" only :-). I will try it after paxctl renamed and let you know. Thank you. It builds fine with /sbin/paxctl renamed. I got paxctl binary to system as dependency of sys-apps/paxctl-0.9 pulled in by: net-libs/webkit-gtk-2.4.8 requires sys-apps/paxctl and its bug #407085. Maybe detection of real hardened system should not depend on existence of /sbin/paxctl file. Thank you. Confirmed, renaming /sbin/paxctl while building dev-java/icedtea-7.2.5.4 solved the issue. sys-apps/paxctl is installed because of: # equery d paxctl * These packages depend on paxctl: dev-java/oracle-jdk-bin-1.8.0.40 (pax_kernel ? sys-apps/paxctl:0) net-libs/webkit-gtk-2.4.8 (jit ? sys-apps/paxctl) net-libs/webkit-gtk-2.6.5 (jit ? sys-apps/paxctl) www-client/epiphany-3.14.2 (sys-apps/paxctl) System profile is not hardened: # eselect profile show Current /etc/portage/make.profile symlink: default/linux/amd64/13.0/no-emul-linux-x86/desktop/gnome/systemd It doesn't: checking if a PaX kernel is in use... no So I wonder why it's still running it... Looks like they added in 2.5.4 it due to G477456: cd /var/tmp/portage/dev-java/icedtea-7.2.5.4/work srv5 work # find . -type f -exec grep -H paxctl {} \; ./icedtea-2.5.4/NEWS: - G477456: emerge fails on pax system: java attempts RWX map, paxctl -m missing ./icedtea-2.5.4/acinclude.m4: AC_PATH_PROG(PAX_COMMAND, "paxctl-ng") ./icedtea-2.5.4/acinclude.m4: AC_PATH_PROG(PAX_COMMAND, "paxctl") ./icedtea-2.5.4/configure: # Extract the first word of ""paxctl-ng"", so it can be a program name with args. ./icedtea-2.5.4/configure:set dummy "paxctl-ng"; ac_word=$2 ./icedtea-2.5.4/configure: # Extract the first word of ""paxctl"", so it can be a program name with args. ./icedtea-2.5.4/configure:set dummy "paxctl"; ac_word=$2 ./icedtea-2.5.4/ChangeLog: currently paxmark.sh, paxctl-ng, chpax and paxctl - ./configure has --with-pax=COMMAND the command used for pax marking The machinery in ./configure around PaX is big and to me looks unconditional. If there is paxctl(-ng) binary found it is used after. What about to make it /bin/true for non PaX systems/kernels? Or remove it form autoconf machinery reverting G477456 on non PaX/hardened systems? Well, I see the problem... it's testing for it, alright, but then it does nothing with the result :( The test will be extended in the upcoming releases so that the PaX marking in the build is only applied if a PaX kernel is running: - echo " $(PAX_COMMAND) $(PAX_COMMAND_ARGS) ./\$${GAMMA_PROG}"; \ + echo " if cat /proc/self/status | grep '^PaX' > /dev/null ; then "; \ + echo " $(PAX_COMMAND) $(PAX_COMMAND_ARGS) ./\$${GAMMA_PROG}"; \ + echo " fi"; \ We'll also change configure so it only tries to find a tool if running on a PaX kernel. Specifying with-pax=<tool> will be able to override this, so the pax_kernel USE flag will still work. This should be resolved in 2.6.0 (http://bitly.com/it20600) now in java overlay. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2507 Thank you, it works for me. Can I close this bug? (In reply to David Kredba from comment #11) > Can I close this bug? Please allow me to close it when it hits the main tree. Of course, thank you. I was thinking the same, that it will be good to keep it open until that. Fixed version now in the tree. |