On Tuesday, 15 September, 2015 10:41 CEST, Gordan Bobic <[email protected]> wrote: > On 2015-09-15 09:09, Jacco Ligthart wrote: > > On 14-09-15 15:41, Gordan Bobic wrote: > >> Here is the patch I wrote to get it to compile: > >> http://ftp.redsleeve.org/pub/patches/tmp/gcc-rtti-arm.patch > >> > >> You will find the modified spec file in the same directory, that also > >> needed changing (no idea what the deal is with: > >> %global _gnu 7E > >> happens to be, it makes no sense to me, and it was breaking the build > >> badly. > > > > OK, I got gcc-4.8.2 to compile. > > I installed it in a mock chroot and "fixed" FF to not use the bundeled > > gcc. > > You mean you built the bundled gcc, installed it in the chroot, and are > building FF in that chroot so you don't have to rebuild gcc on every> > attempt? I found that doing that gave me a different FTBFS than using> the > (fixed) (re)bundled version.
That's exactly what I meant. I did not try the bundled method, so I don't know if there is a difference (for FF) > > > the FF build now fails on me with these errors: > > > > <error_msg> > > /builddir/build/BUILD/firefox-38.2.1/mozilla-esr38/js/src/jit/BaselineDebugModeOSR.cpp: > > In function 'void > > EmitBaselineDebugModeOSRHandlerTail(js::jit::MacroAssembler&, > > js::jit::Register, bool)': > > /builddir/build/BUILD/firefox-38.2.1/mozilla-esr38/js/src/jit/BaselineDebugModeOSR.cpp:1080:23: > > error: reference to 'R0' is ambiguous > > jumpRegs.take(R0); > > ^ > > /usr/include/sys/ucontext.h:43:3: note: candidates are: <anonymous > > > > enum> R0 > > R0 = 0, > > ^ > > /builddir/build/BUILD/firefox-38.2.1/mozilla-esr38/js/src/jit/arm/BaselineRegisters-arm.h:26:39: > > note: constexpr const js::jit::ValueOperand js::jit::R0 > > static MOZ_CONSTEXPR_VAR ValueOperand R0(r3, r2); > > ^ > > /builddir/build/BUILD/firefox-38.2.1/mozilla-esr38/js/src/jit/BaselineDebugModeOSR.cpp:1081:23: > > error: reference to 'R1' is ambiguous > > jumpRegs.take(R1); > > ^ > > /usr/include/sys/ucontext.h:45:3: note: candidates are: <anonymous > > > > enum> R1 > > R1 = 1, > > ^ > > /builddir/build/BUILD/firefox-38.2.1/mozilla-esr38/js/src/jit/arm/BaselineRegisters-arm.h:27:39: > > note: constexpr const js::jit::ValueOperand js::jit::R1 > > static MOZ_CONSTEXPR_VAR ValueOperand R1(r5, r4); > > ^ > > /builddir/build/BUILD/firefox-38.2.1/mozilla-esr38/js/src/jit/BaselineDebugModeOSR.cpp:1091:23: > > error: reference to 'R1' is ambiguous > > masm.popValue(R1); > > ^ > > /usr/include/sys/ucontext.h:45:3: note: candidates are: <anonymous > > > > enum> R1 > > R1 = 1, > > ^ > > /builddir/build/BUILD/firefox-38.2.1/mozilla-esr38/js/src/jit/arm/BaselineRegisters-arm.h:27:39: > > note: constexpr const js::jit::ValueOperand js::jit::R1 > > static MOZ_CONSTEXPR_VAR ValueOperand R1(r5, r4); > > ^ > > /builddir/build/BUILD/firefox-38.2.1/mozilla-esr38/js/src/jit/BaselineDebugModeOSR.cpp:1092:23: > > error: reference to 'R0' is ambiguous > > masm.popValue(R0); > > ^ > > /usr/include/sys/ucontext.h:43:3: note: candidates are: <anonymous > > > > enum> R0 > > R0 = 0, > > ^ > > /builddir/build/BUILD/firefox-38.2.1/mozilla-esr38/js/src/jit/arm/BaselineRegisters-arm.h:26:39: > > note: constexpr const js::jit::ValueOperand js::jit::R0 > > static MOZ_CONSTEXPR_VAR ValueOperand R0(r3, r2); > > ^ > > make[5]: *** [Unified_cpp_js_src3.o] Error 1 > > </error_msg> > > Just out of interest, did you use my modified FF spec file? Nope, I think you refer to FF version 24. I thought that the version difference was so big that it made sense to start from scratch (and because the same builds just fine on 7.1) > And did you apply the armv5tel patch for the configure script? same, no > > Looking at the errors here, they don't look familiar, I think my FTBFS > was > different. I have a sneaky suspicion it might be related to some headers > somewhere (/usr/include/sys/ucontext.h ?) You could be right, ucontext.h defines R0 and R1 etc, where the same things are called REG_R0 etc on RHEL6 (and RSEL7) > As a possible alternative bodge, is there a configure option to disable > jit support completely at build time? > > > I wonder how this can fail while the same code compiles on RSEL7 :(> > > > google does not hold any answers today. > > Probably the best course of action is to review all patches included in > > FF for 6.7 vs those in 7.1 and see if something points in the direction > > of these errors. > > I looked into that, but I couldn't spot anything too obvious. The spec > file > was very similar and I don't recall any difference in the patches. But > it's > worth re-checking with a fresh pair of eyes. > > > but first I'm going to test TB. > > So TB built OK? Nah, I meant test if it builds. test done, it doesn't. It fails similar to FF both when I bundle gcc and when I don't. So apparently, first step is to verify if ucontext.h is "correct". is it similar to older glibc-header files? etc. Jacco _______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
