Bug 848370
Summary: | Recompile failure on sparc64 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bryce <root> |
Component: | java-1.7.0-openjdk | Assignee: | Andrew John Hughes <ahughes> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | ahughes, chphilli, dbhole, jvanek, omajid |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | sparc64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-02-05 12:03:38 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bryce
2012-08-15 12:31:20 UTC
An easy workaround for this is to pass: CFLAGS_WARN= WARNINGS_ARE_ERRORS= to the OpenJDK build, which will turn off the -Werror and at least allow it to get further. diff --git a/java-1.7.0-openjdk.spec b/java-1.7.0-openjdk.spec index 85d2d24..4509a11 100644 --- a/java-1.7.0-openjdk.spec +++ b/java-1.7.0-openjdk.spec @@ -853,6 +853,9 @@ make \ ZERO_ENDIANNESS="little" \ %endif %endif +%ifarch sparcv9 sparc64 + CFLAGS_WARN="" WARNINGS_ARE_ERRORS="" \ +%endif %{nil} export JDK_TO_BUILD_WITH=$PWD/build/linux-%{archbuild}/j2sdk-image Sorry the patch should be: diff --git a/java-1.7.0-openjdk.spec b/java-1.7.0-openjdk.spec index 85d2d24..f2dccb2 100644 --- a/java-1.7.0-openjdk.spec +++ b/java-1.7.0-openjdk.spec @@ -910,6 +910,9 @@ make \ ZERO_ENDIANNESS="little" \ %endif %endif +%ifarch sparcv9 sparc64 + CFLAGS_WARN="" WARNINGS_ARE_ERRORS="" \ +%endif %{debugbuild} popd >& /dev/null The higher make is for (unused) bootstrap builds only. well it's the definition of size_t that's the problem really but since thats a defined type there is not much chance of changing that to suit 8) /* sparc 64 bit */ typedef unsigned long __kernel_size_t; /* sparc 32 bit */ typedef unsigned int __kernel_size_t; I was thinking more along the lines of promoting the rhs to unsigned long (count > (unsigned long)(BlockZeroingLowLimit >> LogHeapWordSize))) { although that would not be the only possible place still the C standard does limit the size_t type to the same range of values even though it's vast as a long so we could live with the warnings (probably) Yes, as I said, it's a workaround not a fix :-) I'm a bit wary of patching the code without the ability to test the fix. If you have something that fixes it, then by all means post it. getting there 8) sparc64 is a pita to get all the ducks in a row though Example of a 'duck' in the row,... /usr/include/asm/traps.h:#define SP_TRAP_SBPT 0x81 DEBUG: g++ -DLINUX -D_GNU_SOURCE -DSPARC -DPRODUCT -I. -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/prims -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/precompiled -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/sparc/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/os_cpu/linux_sparc/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/os/linux/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.0-b21\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mockbuild\"" -DHOTSPOT_LIB_ARCH=\"sparcv9\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_sparc -DTARGET_ARCH_MODEL_sparc -DTARGET_OS_ARCH_linux_sparc -DTARGET_OS_ARCH_MODEL_linux_sparc -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -mcpu=v9 -pipe -g -O3 -fno-strict-aliasing -gstabs -D_LP64=1 -DINCLUDE_TRACE -Wpointer-arith -Wsign-compare -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/c1_Instruction.o.d -o c1_Instruction.o /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/c1/c1_Instruction.cpp DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp:37:30: warning: asm-sparc/traps.h: No such file or directory assembler_linux_sparc.cpp: #if defined(__sparc__) && defined(__arch64__) # include <asm-sparc/traps.h> #else # include <asm/traps.h> #endif -sigh- I guess this is kernel header dependant 8/ pity C preprocessing doesn't allow for a 'this or that' directive Still picking through other compiler grumbles,... Not my idea of a fun time Do you have asm/traps.h and does that work? This was already patched from: -#include <asm-sparc/traps.h> +/* Headers for 32bit sparc with a 32bit userland end up in asm/ + * Headers for 32bit sparc with a 64bit userland end up in asm-sparc/ + * There is no traps.h in asm-sparc64/ + */ + +#if defined(__sparc__) && defined(__arch64__) +# include <asm-sparc/traps.h> +#else +# include <asm/traps.h> +#endif yes, in a sparc64 environment, I have a /usr/include/asm/trap.h and it has apparently got enough in it to keep the compile quiet. /usr/include/asm-sparc doesn't exist but I'll assume thats down to the kernel folk shifting kernel headers around again. Now if only I knew what all the types where,... Maybe I should try and bootstrap this build first. [root@sparc10 ~]# gcc -dM -E - < /dev/null | egrep "__sparc__|__arch64__" #define __sparc__ 1 #define __arch64__ 1 [root@sparc10 ~]# uname -m sparc64 [root@sparc10 ~]# find /usr/include -name traps.h /usr/include/asm/traps.h hurm ok well I've patched up so far to the http://tinyurl.com/cr5a9qw event so I'm now staring at a pile of "CON__G1 not declared in this scope" messages. ugh,.. access to sparc64 externally (reading following emails),.. I could possibly do though I'd have to dmz it. Thats if you were intrested but I think you'd rather I did the lifting for you for a while until it's seriously foobared 8) I'll try adding the patch from the mail list momentarily,.. (ah the joys of patching srpms..) Phil =--= Ok, a bit further along,... Past the CON__ -> CON_ changes and banging into other problems. DEBUG: g++ -DLINUX -D_GNU_SOURCE -DSPARC -DPRODUCT -I. -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/prims -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/precompiled -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/sparc/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/os_cpu/linux_sparc/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/os/linux/vm -I/builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"23.0-b21\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mockbuild\"" -DHOTSPOT_LIB_ARCH=\"sparcv9\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_sparc -DTARGET_ARCH_MODEL_sparc -DTARGET_OS_ARCH_linux_sparc -DTARGET_OS_ARCH_MODEL_linux_sparc -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64 -mcpu=v9 -pipe -g -O3 -fno-strict-aliasing -gstabs -D_LP64=1 -DINCLUDE_TRACE -Wpointer-arith -Wsign-compare -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/synchronizer.o.d -o synchronizer.o /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/runtime/synchronizer.cpp DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/sparc/vm/stubGenerator_sparc.cpp: In member function 'void StubGenerator::copy_16_bytes_forward_with_shift(RegisterImpl*, RegisterImpl*, RegisterImpl*, int, Label&)': DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/sparc/vm/stubGenerator_sparc.cpp:1280: error: no matching function for call to 'StubGenerator::disjoint_copy_core(RegisterImpl*&, RegisterImpl*&, RegisterImpl*&, int&, int, <unresolved overloaded function type>)' DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/sparc/vm/stubGenerator_sparc.cpp:1128: note: candidates are: void StubGenerator::disjoint_copy_core(RegisterImpl*, RegisterImpl*, RegisterImpl*, int, int, void (StubGenerator::*)(RegisterImpl*, RegisterImpl*, RegisterImpl*, int, Label&, bool, bool)) DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/sparc/vm/stubGenerator_sparc.cpp: In member function 'void StubGenerator::generate_disjoint_int_copy_core(bool)': DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/sparc/vm/stubGenerator_sparc.cpp:2159: error: no matching function for call to 'StubGenerator::disjoint_copy_core(RegisterImpl* const&, RegisterImpl* const&, RegisterImpl* const&, int, int, <unresolved overloaded function type>)' DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/sparc/vm/stubGenerator_sparc.cpp:1128: note: candidates are: void StubGenerator::disjoint_copy_core(RegisterImpl*, RegisterImpl*, RegisterImpl*, int, int, void (StubGenerator::*)(RegisterImpl*, RegisterImpl*, RegisterImpl*, int, Label&, bool, bool)) DEBUG: Compiling /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/classfile/systemDictionary.cpp DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/sparc/vm/stubGenerator_sparc.cpp: In member function 'void StubGenerator::generate_disjoint_long_copy_core(bool)': DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/sparc/vm/stubGenerator_sparc.cpp:2440: error: no matching function for call to 'StubGenerator::disjoint_copy_core(RegisterImpl* const&, RegisterImpl* const&, RegisterImpl* const&, int, int, <unresolved overloaded function type>)' DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/cpu/sparc/vm/stubGenerator_sparc.cpp:1128: note: candidates are: void StubGenerator::disjoint_copy_core(RegisterImpl*, RegisterImpl*, RegisterImpl*, int, int, void (StubGenerator::*)(RegisterImpl*, RegisterImpl*, RegisterImpl*, int, Label&, bool, bool)) Seems to have been seen before. Am I working with the right srpm? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660871 Borrowed http://patch-tracker.debian.org/patch/series/view/openjdk-7/7~u3-2.1.1-3/sparc-stubgenerator.diff from debian,.. Gah,.. so close 8/ DEBUG: echo Linking vm...; \ DEBUG: \ DEBUG: gcc -m64 -mcpu=v9 -Xlinker -O1 -Wl,--hash-style=both -Xlinker -z -Xlinker noexecstack -shared \ DEBUG: -Xlinker --version-script=mapfile_reorder -Xlinker -soname=libjvm.so -o libjvm.so abstractCompiler.o..... <LONG LIST TRUNCATED> DEBUG: Linking vm... DEBUG: abstractCompiler.o: In function `AbstractCompiler::initialize_runtimes(void (*)(), int volatile*)': DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/compiler/abstractCompiler.cpp:29: relocation truncated to fit: R_SPARC_GOT13 against symbol `ThreadLocalStorage::_thread_index' defined in .data section in threadLocalStorage.o DEBUG: abstractCompiler.o: In function `AbstractCompiler::initialize_runtimes(void (*)(), int volatile*)': DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/runtime/interfaceSupport.hpp:214: relocation truncated to fit: R_SPARC_GOT13 against symbol `os::_processor_count' defined in .bss section in os.o DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/runtime/interfaceSupport.hpp:215: relocation truncated to fit: R_SPARC_GOT13 against symbol `UseMembar' defined in .bss section in globals.o DEBUG: abstractCompiler.o: In function `AbstractCompiler::initialize_runtimes(void (*)(), int volatile*)': DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/runtime/safepoint.hpp:150: relocation truncated to fit: R_SPARC_GOT13 against symbol `SafepointSynchronize::_state' defined in .bss section in safepoint.o DEBUG: abstractCompiler.o: In function `AbstractCompiler::initialize_runtimes(void (*)(), int volatile*)': DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/compiler/abstractCompiler.cpp:37: relocation truncated to fit: R_SPARC_GOT13 against symbol `CompileThread_lock' defined in .bss section in mutexLocker.o DEBUG: abstractCompiler.o: In function `AbstractCompiler::initialize_runtimes(void (*)(), int volatile*)': DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/runtime/interfaceSupport.hpp:181: relocation truncated to fit: R_SPARC_GOT13 against symbol `UseMembar' defined in .bss section in globals.o DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/runtime/interfaceSupport.hpp:214: relocation truncated to fit: R_SPARC_GOT13 against symbol `UseMembar' defined in .bss section in globals.o DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/runtime/interfaceSupport.hpp:181: relocation truncated to fit: R_SPARC_GOT13 against symbol `UseMembar' defined in .bss section in globals.o DEBUG: abstractCompiler.o: In function `AbstractCompiler::initialize_runtimes(void (*)(), int volatile*)': DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/runtime/os.hpp:330: relocation truncated to fit: R_SPARC_GOT13 against symbol `os::_serialize_page_mask' defined in .bss section in os.o DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/runtime/os.hpp:330: relocation truncated to fit: R_SPARC_GOT13 against symbol `os::_mem_serialize_page' defined in .bss section in os.o DEBUG: abstractCompiler.o: In function `AbstractCompiler::initialize_runtimes(void (*)(), int volatile*)': DEBUG: /builddir/build/BUILD/java-1.7.0-openjdk/openjdk/hotspot/src/share/vm/runtime/safepoint.hpp:150: additional relocation overflows omitted from the output DEBUG: collect2: ld returned 1 exit status DEBUG: ln: accessing `libjvm.so.1': Too many levels of symbolic links DEBUG: [ -f libjvm.debuginfo ] || ln -s libjvm.debuginfo libjvm.debuginfo DEBUG: make[6]: stat: libjvm.so: Too many levels of symbolic links DEBUG: echo Linking launcher... DEBUG: Linking launcher... Lets see, that'll be the relocation table probably using -fpic somewhere instead of -fPIC (or possibly -fpie v -fPIE),.. holy moely ,.. gotta wade through all that compile output ,.. gah,... Where are we now,.. java-1.7.0-openjdk/openjdk/hotspot/make/linux/makefiles/vm.make Oh great,.. selinux is in the mix,. flee! I hate makefiles that are a rats nest of macros 8/ # With more recent Redhat releases (or the cutting edge version Fedora), if # SELinux is configured to be enabled, the runtime linker will fail to apply # the text relocation to libjvm.so considering that it is built as a non-PIC # DSO. To workaround that, we run chcon to libjvm.so after it is built. See # details in bug 6538311. $(LIBJVM): $(LIBJVM.o) $(LIBJVM_MAPFILE) $(LD_SCRIPT) $(QUIETLY) { \ echo Linking vm...; \ $(LINK_LIB.CXX/PRE_HOOK) \ $(LINK_VM) $(LD_SCRIPT_FLAG) \ $(LFLAGS_VM) -o $@ $(LIBJVM.o) $(LIBS_VM); \ $(LINK_LIB.CXX/POST_HOOK) \ rm -f $@.1; ln -s $@ $@.1; \ [ -f $(LIBJVM_G) ] || { ln -s $@ $(LIBJVM_G); ln -s $@.1 $(LIBJVM_G).1; }; \ if [ \"$(CROSS_COMPILE_ARCH)\" = \"\" ] ; then \ if [ -x /usr/sbin/selinuxenabled ] ; then \ /usr/sbin/selinuxenabled; \ if [ $$? = 0 ] ; then \ /usr/bin/chcon -t textrel_shlib_t $@; \ if [ $$? != 0 ]; then \ echo "ERROR: Cannot chcon $@"; \ fi \ fi \ fi \ fi \ } Mmm what to do here (if anything)... dredging through the compile log,.. 558 files compiled with -fpic 2 files compile with -fPIC looking at java-1.7.0-openjdk/openjdk/hotspot/make/linux/makefiles/gcc.make # position-independent code ifneq ($(filter parisc ppc ppc64 s390 s390x sparc sparc64 sparcv9,$(ZERO_LIBARCH)),) PICFLAG = -fPIC else PICFLAG = -fpic endif eh? is that right? what happened to i?86/x86_64 ? Phil =--= Oh apologies I should have closed this,.. once you setup to use -fPIC from the java-1.7.0-openjdk/openjdk/hotspot/make/linux/makefiles/gcc.make, the rest will compile up successfully. Can't vouch for it's usability thereafter, but that is not really my department. Actualy the patces I made are a little untidy, I'll clean thpose up and add them here before I close this out before the weekend -busy busy busy!- Phil =--= Any update on this? This bug is quite old now. There is -Werror support in IcedTea HEAD now. Oh, err yeah, I did build this [root@bryce1-ldom ~]# java -version java version "1.7.0_09-icedtea" OpenJDK Runtime Environment (rhel-2.3.4.1.0.2.el6_3-sparc64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode) just meddling with some of the memory model pieces. as you can see this is 7u9 but I was hoping to weld 7u15 into the mix, just other problems have kept me at bay for a while I'll get back to all this again in a few weeks (I'm travelling to the US for a couple of weeks so everything is up in the air *again* (literally)) I have consolidated patches for the above, just I don't think there is a sparc in the RHT/Fedora build system anymore 8( Phil =--= This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |