Bug 113638 - webkitgtk 2.0.0 fails to build on OpenBSD (and maybe others) powerpc/mips64el/sparc64
Summary: webkitgtk 2.0.0 fails to build on OpenBSD (and maybe others) powerpc/mips64el...
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Other
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-30 03:06 PDT by Landry Breuil
Modified: 2015-08-20 10:41 PDT (History)
10 users (show)

See Also:


Attachments
patches for mips64el build, workable for Debian GNU/Linux (2.70 KB, patch)
2013-11-14 05:17 PST, YunQiang Su
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Landry Breuil 2013-03-30 03:06:26 PDT
As of now on those archs, build fails with :

rce/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp' || echo './'`Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp
In file included from ./Source/JavaScriptCore/bytecode/ValueRecovery.h:31,
                 from ./Source/JavaScriptCore/bytecode/CodeOrigin.h:31,
                 from ./Source/JavaScriptCore/bytecode/CodeBlock.h:39,
                 from Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:29:
./Source/JavaScriptCore/assembler/MacroAssembler.h:62:2: error: #error "The MacroAssembler is not supported on this platform."
In file included from /usr/include/g++/iosfwd:45,
                 from /usr/include/g++/bits/stl_algobase.h:70,
                 from /usr/include/g++/algorithm:65,
                 from ./Source/WTF/wtf/Alignment.h:25,
                 from ./Source/WTF/wtf/HashTable.h:25,
                 from ./Source/WTF/wtf/HashMap.h:24,
                 from ./Source/JavaScriptCore/runtime/JSCJSValue.h:31,
                 from ./Source/JavaScriptCore/heap/HandleTypes.h:29,
                 from ./Source/JavaScriptCore/runtime/WriteBarrier.h:30,
                 from ./Source/JavaScriptCore/runtime/PropertyStorage.h:29,
                 from ./Source/JavaScriptCore/runtime/IndexingHeader.h:29,
                 from ./Source/JavaScriptCore/runtime/ArrayConventions.h:24,
                 from ./Source/JavaScriptCore/runtime/JSArray.h:24,
                 from ./Source/JavaScriptCore/bytecode/ArrayProfile.h:29,
                 from Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:28:
/usr/include/g++/powerpc-unknown-openbsd5.3/bits/c++locale.h: In function 'int std::__convert_from_v(int* const&, char*, int, const char*, 
...)':
/usr/include/g++/powerpc-unknown-openbsd5.3/bits/c++locale.h:81: warning: function might be possible candidate for 'printf' format attribut
e
In file included from ./Source/JavaScriptCore/bytecode/ValueRecovery.h:31,
                 from ./Source/JavaScriptCore/bytecode/CodeOrigin.h:31,
                 from ./Source/JavaScriptCore/bytecode/CodeBlock.h:39,
                 from Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:29:
./Source/JavaScriptCore/assembler/MacroAssembler.h: At global scope:
./Source/JavaScriptCore/assembler/MacroAssembler.h:67: error: expected class-name before '{' token
./Source/JavaScriptCore/assembler/MacroAssembler.h:70: error: 'MacroAssemblerBase' has not been declared
./Source/JavaScriptCore/assembler/MacroAssembler.h:71: error: 'MacroAssemblerBase' has not been declared
./Source/JavaScriptCore/assembler/MacroAssembler.h:72: error: 'MacroAssemblerBase' has not been declared
./Source/JavaScriptCore/assembler/MacroAssembler.h:73: error: 'MacroAssemblerBase' has not been declared
./Source/JavaScriptCore/assembler/MacroAssembler.h:161: error: 'RegisterID' has not been declared
./Source/JavaScriptCore/assembler/MacroAssembler.h:166: error: 'Address' does not name a type
./Source/JavaScriptCore/assembler/MacroAssembler.h:171: error: 'RegisterID' has not been declared
./Source/JavaScriptCore/assembler/MacroAssembler.h:176: error: 'TrustedImm32' has not been declared

etc etc etc..

If i force-disable assembler/yarr jit with JSC_CPPFLAGS="-DENABLE_YARR_JIT=0 -DENABLE_ASSEMBLER=0" in the build env, it fails with :

./Source/WTF/wtf/MathExtras.h: In function 'bool std::signbit(double)':
./Source/WTF/wtf/MathExtras.h:112: warning: dereferencing type-punned pointer will break strict-aliasing rules
In file included from Source/JavaScriptCore/llint/LowLevelInterpreter.cpp:406:
./DerivedSources/JavaScriptCore/LLIntAssembly.h: In static member function 'static JSC::JSValue JSC::LLInt::CLoop::execute(JSC:
:CallFrame*, JSC::OpcodeID, bool)':
./DerivedSources/JavaScriptCore/LLIntAssembly.h:2545: error: 'isnan' was not declared in this scope
./DerivedSources/JavaScriptCore/LLIntAssembly.h:2548: error: 'Double2Ints' was not declared in this scope
./DerivedSources/JavaScriptCore/LLIntAssembly.h:2834: error: 'isnan' was not declared in this scope
./DerivedSources/JavaScriptCore/LLIntAssembly.h:4736: error: 'isnan' was not declared in this scope


Help welcome. I suppose the logic for ENABLE_ASSEMBLER in Source/WTF/wtf/Platform.h is somewhat broken for those archs.
Comment 1 Landry Breuil 2013-03-30 07:33:54 PDT
Some more notes on this - the first problem of ENABLE_ASSEMBLER left out, the second issue can be worked around this way :

Backport http://trac.webkit.org/changeset/145551 -> Fixes the 'error: 'Double2Ints' was not declared in this scope'
Fix  Source/JavaScriptCore/offlineasm/cloop.rb so that it only spits std::isnan and not std::isnan || isnan fixes the 'error: 'isnan' was not declared in this scope'

--- Source/JavaScriptCore/offlineasm/cloop.rb.orig      Tue Feb 19 08:44:37 2013
+++ Source/JavaScriptCore/offlineasm/cloop.rb   Sat Mar 30 13:06:32 2013
@@ -398,7 +398,7 @@ def cloopEmitUnaryOperation(operands, type, operator)
 end
 
 def cloopEmitCompareDoubleWithNaNCheckAndBranch(operands, condition)
-    $asm.putc "if (std::isnan(#{operands[0].clValue(:double)}) || isnan(#{operands[1].clValue(:double)})"
+    $asm.putc "if (std::isnan(#{operands[0].clValue(:double)})"
     $asm.putc "    || (#{operands[0].clValue(:double)} #{condition} #{operands[1].clValue(:double)}))"
     $asm.putc "    goto #{operands[2].cLabel};"
 end


On OpenBSD (don't know for the others), including <cmath> to reach std::isnan() #undefs isnan, and because of multiple inclusion protection including math.h again afterwards doesn't get isnan() defined back, so both cant be used at the same time.
Comment 2 Landry Breuil 2013-03-31 01:41:46 PDT
Using all the aforementioned changes (disable asm/yarr in env, backport r145551, fix cloop.rb wrt isnan) , i managed to get webkitgtk 1.11.91 to build on OpenBSD/ppc. Will try 2.0.0.

Unfortunately runtime seems broken: GtkLauncher just spits '** Message: console message: undefined @0: RangeError: Maximum call stack size exceeded.', and midori crashes with what seems an infinite recursion in CLoop::execute :

(gdb) bt
#0  0x8e95a0d4 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0
#1  0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0
#2  0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0
#3  0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0

Any guidance in where to look; which commits to backport, or what 'sort-of-related bug report' to see is welcome.
Comment 3 Landry Breuil 2013-03-31 02:01:46 PDT
Thinking out loud, maybe  #103128 would fix ppc 32 bits ?
Comment 4 Filip Pizlo 2013-03-31 21:58:38 PDT
(In reply to comment #2)
> Using all the aforementioned changes (disable asm/yarr in env, backport r145551, fix cloop.rb wrt isnan) , i managed to get webkitgtk 1.11.91 to build on OpenBSD/ppc. Will try 2.0.0.
> 
> Unfortunately runtime seems broken: GtkLauncher just spits '** Message: console message: undefined @0: RangeError: Maximum call stack size exceeded.', and midori crashes with what seems an infinite recursion in CLoop::execute :
> 
> (gdb) bt
> #0  0x8e95a0d4 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0
> #1  0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0
> #2  0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0
> #3  0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0
> 
> Any guidance in where to look; which commits to backport, or what 'sort-of-related bug report' to see is welcome.

I would love to help but I don't have a big-endian 64-bit machine.

Can you enable LLINT_EXECUTION_TRACING (LLIntCommon.h) and try to run some of the basic tests?  Like run-javascriptcore-tests?  Or attempt to run GtkLauncher and see what happens?
Comment 5 Landry Breuil 2013-04-01 12:48:17 PDT
as i said in #103128 ( sorry for being on both sides.. ), using a modified patchset from that bug 'fixes' the infinite loop, but runtime still seems broken. I'll try LLINT_EXECUTION_TRACING.

Some questions : am i right that ENABLE_ASSEMBLER and ENABLE_YARR_JIT should _not_ be set on ppc/mips64el/sparc64 ? Is there a way to only build the js shell from a webkitgtk-2.0.0 src tarball, without spending 24h building the whole thing ? gmake jsc-1 should do the trick ?
Comment 6 Dan Horák 2013-04-02 04:21:39 PDT
(In reply to comment #4)
> (In reply to comment #2)
> > Using all the aforementioned changes (disable asm/yarr in env, backport r145551, fix cloop.rb wrt isnan) , i managed to get webkitgtk 1.11.91 to build on OpenBSD/ppc. Will try 2.0.0.
> > 
> > Unfortunately runtime seems broken: GtkLauncher just spits '** Message: console message: undefined @0: RangeError: Maximum call stack size exceeded.', and midori crashes with what seems an infinite recursion in CLoop::execute :
> > 
> > (gdb) bt
> > #0  0x8e95a0d4 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0
> > #1  0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0
> > #2  0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0
> > #3  0x8e95a1c8 in JSC::LLInt::CLoop::execute () from /usr/local/lib/libjavascriptcoregtk-1.0.so.3.0
> > 
> > Any guidance in where to look; which commits to backport, or what 'sort-of-related bug report' to see is welcome.
> 
> I would love to help but I don't have a big-endian 64-bit machine.

this problem can most likely be solved, I'll come to you with the details when I'll have them
Comment 7 Landry Breuil 2013-04-02 09:22:22 PDT
Building with LLINT_EXECUTION_TRACING defined to 1 in LLIntCommon.h doesnt seem to make jsc more verbose. Maybe i'm missing something ?
Comment 8 Emilio Pozuelo Monfort 2013-08-31 04:31:07 PDT
(In reply to comment #0)
> If i force-disable assembler/yarr jit with JSC_CPPFLAGS="-DENABLE_YARR_JIT=0 -DENABLE_ASSEMBLER=0" in the build env, it fails with :

This is no longer possible in 2.1.x after the change from bug #119445. CPPFLAGS should be fine though.

The arches that don't support this stuff should define ENABLE_JIT, ENABLE_YARR_JIT and ENABLE_ASSEMBLER to 0 in Source/WTF/wtf/Platform.h

The problem seems to be that YARR_JIT and ASSEMBLER are enabled if one of JIT or LLINT_C_LOOP are enabled:

/* Yet Another Regex Runtime - turned on by default for JIT enabled ports. */
#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) || ENABLE(LLINT_C_LOOP)) && !(OS(QNX) && PLATFORM(QT))
#define ENABLE_YARR_JIT 1

But LLINT_C_LOOP is enabled if JIT is disabled, so the above check is always true:

/* If the jit is not available, enable the LLInt C Loop: */
#if !ENABLE(JIT)
#undef ENABLE_LLINT        /* Undef so that we can redefine it. */
#undef ENABLE_LLINT_C_LOOP /* Undef so that we can redefine it. */
#undef ENABLE_DFG_JIT      /* Undef so that we can redefine it. */
#define ENABLE_LLINT 1
#define ENABLE_LLINT_C_LOOP 1
#define ENABLE_DFG_JIT 0
#endif
Comment 9 Landry Breuil 2013-10-06 05:39:41 PDT
(In reply to comment #8)
> (In reply to comment #0)
> > If i force-disable assembler/yarr jit with JSC_CPPFLAGS="-DENABLE_YARR_JIT=0 -DENABLE_ASSEMBLER=0" in the build env, it fails with :
> 
> This is no longer possible in 2.1.x after the change from bug #119445. CPPFLAGS should be fine though.
> 
> The arches that don't support this stuff should define ENABLE_JIT, ENABLE_YARR_JIT and ENABLE_ASSEMBLER to 0 in Source/WTF/wtf/Platform.h
> 
> The problem seems to be that YARR_JIT and ASSEMBLER are enabled if one of JIT or LLINT_C_LOOP are enabled:
> 
> /* Yet Another Regex Runtime - turned on by default for JIT enabled ports. */
> #if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) || ENABLE(LLINT_C_LOOP)) && !(OS(QNX) && PLATFORM(QT))
> #define ENABLE_YARR_JIT 1
> 
> But LLINT_C_LOOP is enabled if JIT is disabled, so the above check is always true:
> 
> /* If the jit is not available, enable the LLInt C Loop: */
> #if !ENABLE(JIT)
> #undef ENABLE_LLINT        /* Undef so that we can redefine it. */
> #undef ENABLE_LLINT_C_LOOP /* Undef so that we can redefine it. */
> #undef ENABLE_DFG_JIT      /* Undef so that we can redefine it. */
> #define ENABLE_LLINT 1
> #define ENABLE_LLINT_C_LOOP 1
> #define ENABLE_DFG_JIT 0
> #endif

Fwiw, here's what i've ended up to fix the build :

 /* Yet Another Regex Runtime - turned on by default for JIT enabled ports. */
-#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) || ENABLE(LLINT_C_LOOP)) && !(OS(QNX) && PLATFORM(QT))
+#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT)) && !(OS(QNX) && PLATFORM(QT))
 #define ENABLE_YARR_JIT 1
 
 /* Setting this flag compares JIT results with interpreter results. */
@@ -863,7 +874,7 @@
 
 /* If either the JIT or the RegExp JIT is enabled, then the Assembler must be
    enabled as well: */
-#if ENABLE(JIT) || ENABLE(YARR_JIT)
+#if ENABLE(JIT)
 #if defined(ENABLE_ASSEMBLER) && !ENABLE_ASSEMBLER
 #error "Cannot enable the JIT or RegExp JIT without enabling the Assembler"
 #else
Comment 10 Thomas De Schampheleire 2013-11-13 08:16:46 PST
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #0)
[..]
> 
> Fwiw, here's what i've ended up to fix the build :
> 
>  /* Yet Another Regex Runtime - turned on by default for JIT enabled ports. */
> -#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) || ENABLE(LLINT_C_LOOP)) && !(OS(QNX) && PLATFORM(QT))
> +#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT)) && !(OS(QNX) && PLATFORM(QT))
>  #define ENABLE_YARR_JIT 1

For most cases this will still set YARR_JIT to 1, because the last clause is almost always true: not QNX and QT. Instead, I have been trying the following change (on a different version):

-#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) || ENABLE(LLINT_C_LOOP)) && !(OS(QNX) && PLATFORM(QT))
+#if !defined(ENABLE_YARR_JIT) && (ENABLE(JIT) && !(OS(QNX) && PLATFORM(QT)))

(so moving the platform check together with JIT, meaning that if JIT is not enabled, YARR JIT won't be either).

I'm not 100% sure if this is correct, as I'm in no way a webkit expert.

> 
>  /* Setting this flag compares JIT results with interpreter results. */
> @@ -863,7 +874,7 @@
> 
>  /* If either the JIT or the RegExp JIT is enabled, then the Assembler must be
>     enabled as well: */
> -#if ENABLE(JIT) || ENABLE(YARR_JIT)
> +#if ENABLE(JIT)
>  #if defined(ENABLE_ASSEMBLER) && !ENABLE_ASSEMBLER
>  #error "Cannot enable the JIT or RegExp JIT without enabling the Assembler"
>  #else

This does not seem correct. It makes sense that you need the assembler for all types of JIT (both JIT as YARR_JIT).


With the mentioned change in Platform.h, and the Double2Ints fix from comment #1, I can compile much further (I'm building webkit 1.11.5 for a 32-bit powerpc target).
However, eventually I get a link problem, but I don't know if it's related to the above problem:

./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::tag() const'
./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::decode(long long)'
./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::payload() const'
./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::asCell() const'
./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::JSValue(int, int)'
./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::JSValue()'
collect2: ld returned 1 exit status
./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::tag() const'
./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::decode(long long)'
./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::payload() const'
./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::asCell() const'
./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::JSValue(int, int)'
./.libs/libjavascriptcoregtk-1.0.so: undefined reference to `JSC::JSValue::JSValue()'
collect2: ld returned 1 exit status
make[2]: *** [Programs/jsc-1] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [Programs/minidom] Error 1
make[2]: Leaving directory `/home/tdescham/repo/contrib/buildroot-webkit/output/build/webkit-1.11.5'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/tdescham/repo/contrib/buildroot-webkit/output/build/webkit-1.11.5'
Comment 11 YunQiang Su 2013-11-14 05:17:16 PST
Created attachment 216925 [details]
patches for mips64el build, workable for Debian GNU/Linux

With this patch, I can build webkitgtk 2.2.0 on Debian for MIPS64EL/Linux
Comment 12 Landry Breuil 2013-11-14 05:33:26 PST
(In reply to comment #11)
> Created an attachment (id=216925) [details]
> patches for mips64el build, workable for Debian GNU/Linux
> 
> With this patch, I can build webkitgtk 2.2.0 on Debian for MIPS64EL/Linux

But does it actually run ?
Comment 13 Emilio Pozuelo Monfort 2013-11-14 07:09:05 PST
(In reply to comment #11)
> Created an attachment (id=216925) [details]
> patches for mips64el build, workable for Debian GNU/Linux
> 
> With this patch, I can build webkitgtk 2.2.0 on Debian for MIPS64EL/Linux

That's unrelated, please open a new bug to add MIPS64 support.
Comment 14 Thomas De Schampheleire 2013-11-19 04:26:49 PST
(In reply to comment #10)

Any feedback on these findings?
Comment 15 Aaron Bamberger 2015-08-20 10:41:58 PDT
(In reply to comment #14)
> (In reply to comment #10)
> 
> Any feedback on these findings?

I realize this is years later, but I've run into the same problem and was able to get webkitgtk to build with the JIT disabled by using both the patch from comment #1, and by using the patch in comment #56 on this bug: https://bugs.webkit.org/show_bug.cgi?id=105696
Changeset: http://trac.webkit.org/changeset/142489

to fix the linker errors mentioned in comment #14