RESOLVED FIXED Bug 77280
Add JSCore symbol exports needed by wx port
https://bugs.webkit.org/show_bug.cgi?id=77280
Summary Add JSCore symbol exports needed by wx port
Kevin Ollivier
Reported 2012-01-28 10:30:25 PST
Adds a few JSCore symbol exports that the wx port needs access.
Attachments
Patch (2.59 KB, patch)
2012-01-28 10:34 PST, Kevin Ollivier
no flags
Patch (1.75 KB, patch)
2012-02-01 14:23 PST, Kevin Ollivier
morrita: review+
Kevin Ollivier
Comment 1 2012-01-28 10:34:06 PST
Kevin Ollivier
Comment 2 2012-01-28 10:43:43 PST
Also, wanted to note that wxWebKit needs to have RTTI enabled since wx itself does. I wasn't sure if we wanted to actually introduce some WTF_RTTI_EXPORT macro since it's only this one case so far and I'm not sure which, if any, other ports are turning on RTTI.
Hajime Morrita
Comment 3 2012-01-29 20:20:46 PST
Besides RTTI, I'm curious why wx port requires extra, C++ level API to be exported. Can these be part of C API ideally? Or is there any reason preventing it?
Kevin Ollivier
Comment 4 2012-01-30 12:50:53 PST
(In reply to comment #3) > Besides RTTI, I'm curious why wx port requires extra, C++ level API to be exported. > Can these be part of C API ideally? Or is there any reason preventing it? While the unresolved symbols do trigger for the wx port, they are not found anywhere in the wx layer. All the references to these symbols appear to be in the jsc test harness and the WebCore JS bindings. I am posting the exact linker output for the jsc and libwxwebkit.dylib targets below to show what source files are referencing those symbols. It's certainly possible this could be related to configuration differences, like with the RTTI problem, but I would actually think allocateSlowCase and toStringSlowCase would be pretty obvious targets for exporting, so I'm more curious as to how it is that the other ports do not need to export these symbols. (All other to<Whatever>SlowCase methods in JSString are exported, for example.) I also, as a sanity check, checked that the Apple Mac port's JSArrayBufferView.cpp and the wx Mac port's JSArrayBufferView.cpp were identical, so I don't think it's that the wx port's DerivedSources are somehow different. Anyway, here's the linker output for wx without the added symbol exports: linker errors for jsc: Undefined symbols for architecture i386: "JSC::MarkedSpace::allocateSlowCase(JSC::MarkedSpace::SizeClass&)", referenced from: JSC::MarkedSpace::allocate(JSC::MarkedSpace::SizeClass&)in jsc_2.o "JSC::JSValue::toStringSlowCase(JSC::ExecState*) const", referenced from: JSC::JSValue::toString(JSC::ExecState*) constin jsc_2.o ld: symbol(s) not found for architecture i386 collect2: ld returned 1 exit status linker errors for libwxwebkit.dylib: Undefined symbols for architecture i386: "JSC::MarkedSpace::allocateSlowCase(JSC::MarkedSpace::SizeClass&)", referenced from: JSC::MarkedSpace::allocate(JSC::MarkedSpace::SizeClass&)in JSArrayBuffer_1.o JSC::MarkedSpace::allocate(JSC::MarkedSpace::SizeClass&)in JSArrayBufferView_1.o JSC::MarkedSpace::allocate(JSC::MarkedSpace::SizeClass&)in JSAttr_1.o JSC::MarkedSpace::allocate(JSC::MarkedSpace::SizeClass&)in JSBarInfo_1.o JSC::MarkedSpace::allocate(JSC::MarkedSpace::SizeClass&)in JSBeforeLoadEvent_1.o JSC::MarkedSpace::allocate(JSC::MarkedSpace::SizeClass&)in JSBlob_1.o JSC::MarkedSpace::allocate(JSC::MarkedSpace::SizeClass&)in JSCDATASection_1.o ... "JSC::JSValue::toStringSlowCase(JSC::ExecState*) const", referenced from: JSC::JSValue::toString(JSC::ExecState*) constin JSBeforeLoadEvent_1.o JSC::JSValue::toString(JSC::ExecState*) constin JSCSSMediaRule_1.o JSC::JSValue::toString(JSC::ExecState*) constin JSCSSPrimitiveValue_1.o JSC::JSValue::toString(JSC::ExecState*) constin JSCSSStyleDeclaration_1.o JSC::JSValue::toString(JSC::ExecState*) constin JSCSSStyleSheet_1.o JSC::JSValue::toString(JSC::ExecState*) constin JSCanvasGradient_1.o JSC::JSValue::toString(JSC::ExecState*) constin JSCanvasRenderingContext2D_1.o ... "typeinfo for WTF::ArrayBufferView", referenced from: typeinfo for WTF::TypedArrayBase<float>in JSFloat32Array_1.o typeinfo for WTF::TypedArrayBase<double>in JSFloat64Array_1.o typeinfo for WTF::TypedArrayBase<short>in JSInt16Array_1.o typeinfo for WTF::TypedArrayBase<int>in JSInt32Array_1.o typeinfo for WTF::TypedArrayBase<signed char>in JSInt8Array_1.o typeinfo for WTF::TypedArrayBase<unsigned short>in JSUint16Array_1.o typeinfo for WTF::TypedArrayBase<unsigned int>in JSUint32Array_1.o ... ld: symbol(s) not found for architecture i386 collect2: ld returned 1 exit status
Kevin Ollivier
Comment 5 2012-01-31 22:19:20 PST
Comment on attachment 124441 [details] Patch I'll post an updated patch after the changes in Bug 77507 have landed.
Kevin Ollivier
Comment 6 2012-02-01 14:23:09 PST
Hajime Morrita
Comment 7 2012-02-06 15:57:30 PST
Comment on attachment 125014 [details] Patch Looks good. I'm sorry for my slow response...
Kevin Ollivier
Comment 8 2012-02-29 09:46:14 PST
It was a lot faster than mine! :) Sorry, I have been swamped recently. However, I did finally manage to land it in r109224, thanks! Next patch should be "flipping the switch" to use the macros for wx port!
Note You need to log in before you can comment on or make changes to this bug.