WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(1.75 KB, patch)
2012-02-01 14:23 PST
,
Kevin Ollivier
morrita
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Kevin Ollivier
Comment 1
2012-01-28 10:34:06 PST
Created
attachment 124441
[details]
Patch
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
Created
attachment 125014
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug