Here's the error: ../Source/JavaScriptCore/interpreter/Interpreter.cpp: In member function 'JSC::JSValue JSC::Interpreter::executeCall(JSC::CallFrame*, JSC::JSObject*, JSC::CallType, const JSC::CallData&, JSC::JSValue, const JSC::ArgList&)': ../Source/JavaScriptCore/interpreter/Interpreter.cpp:973:168: error: 'callToNativeFunction' was not declared in this scope result = JSValue::decode(callToNativeFunction(reinterpret_cast<void*>(callData.native.function), &vm.topCallFrame, &protoCallFrame, m_stack.getTopOfStack())); ^ ../Source/JavaScriptCore/interpreter/Interpreter.cpp: In member function 'JSC::JSObject* JSC::Interpreter::executeConstruct(JSC::CallFrame*, JSC::JSObject*, JSC::ConstructType, const JSC::ConstructData&, const JSC::ArgList&)': ../Source/JavaScriptCore/interpreter/Interpreter.cpp:1041:173: error: 'callToNativeFunction' was not declared in this scope result = JSValue::decode(callToNativeFunction(reinterpret_cast<void*>(constructData.native.function), &vm.topCallFrame, &protoCallFrame, m_stack.getTopOfStack())); Complete build output here: https://buildd.debian.org/status/fetch.php?pkg=webkitgtk&arch=kfreebsd-amd64&ver=2.3.3-1&stamp=1388886358
ENABLE_LLINT is not being enabled on FreeBSD. http://trac.webkit.org/browser/trunk/Source/WTF/wtf/Platform.h#L726
(In reply to comment #1) > ENABLE_LLINT is not being enabled on FreeBSD. > http://trac.webkit.org/browser/trunk/Source/WTF/wtf/Platform.h#L726 Yeah, but JSC should anyway build without it, shouldn't it? We can also enable LLINT in FreeBSD, is there any reason why it wouldn't work? It seems to built fine at least...
And it looks like this broke after r160186, adding Mark Lam to Cc.
(In reply to comment #2) > (In reply to comment #1) > > ENABLE_LLINT is not being enabled on FreeBSD. > > http://trac.webkit.org/browser/trunk/Source/WTF/wtf/Platform.h#L726 > > Yeah, but JSC should anyway build without it, shouldn't it? > > We can also enable LLINT in FreeBSD, is there any reason why it > wouldn't work? It seems to built fine at least... Sorry about the breakage, but going forward, the LLINT will be an essential part of the JSC build. This (breakage) wasn’t by design, but it came out of a natural progression in the development of the JSC JIT. If you build with the JIT, the LLINT is needed to provide glue trampoline (e.g. callToJavaScript and callToNativeFunction). If you build without the JIT, the LLINT is needed to provide the C loop interpreter. Either way, you will need the LLINT. The only alternative to this is to build with JIT only and provide your own glue trampoline. For example, see jit/JITStubsX86.h and jit/JITStubsMSVC64.asm. This is no recommended because the LLINT assembly will be undergoing continual development over time, and these one off bits of ASM code can easily bit rot. I recommend you add LLINT support to the FreeBSD port. Thanks.
(In reply to comment #4) > I recommend you add LLINT support to the FreeBSD port. Thanks. Thanks for the answer. I wonder, instead of adding FREEBSD to the list, can I just replace (OS(DARWIN) || OS(LINUX)) with OS(UNIX) or is there any reason why it wouldn't work in some Unix system?
(In reply to comment #5) > (In reply to comment #4) > > I recommend you add LLINT support to the FreeBSD port. Thanks. > > Thanks for the answer. > > I wonder, instead of adding FREEBSD to the list, can I just replace > (OS(DARWIN) || OS(LINUX)) with OS(UNIX) or is there any reason why it > wouldn't work in some Unix system? The LLINT requires an extra build phase to generate LLIntAssembly.h. It is not guaranteed that all platforms support this build phase.
Created attachment 221276 [details] Patch (In reply to comment #6) > The LLINT requires an extra build phase to generate LLIntAssembly.h. > It is not guaranteed that all platforms support this build phase. I see. Here's the patch with FreeBSD only then. Thanks again!
Comment on attachment 221276 [details] Patch r=me assuming you’ve tested it and confirmed that it resolves the issue.
(In reply to comment #8) > (From update of attachment 221276 [details]) > r=me assuming you’ve tested it and confirmed that it resolves the issue. Yeah, I'll anyway do a full rebuild again later to double check before committing the change.
Committed r162086: <http://trac.webkit.org/changeset/162086>