Bug 88321

Summary: [Qt][Win] Fix broken QtWebKit5.lib linking
Product: WebKit Reporter: Csaba Osztrogonác <ossy>
Component: Tools / TestsAssignee: Jocelyn Turcotte <jturcotte>
Status: RESOLVED FIXED    
Severity: Blocker CC: abecsi, aroben, hausmann, joel.dillon, jturcotte, kbalazs, kevino, ossy, sfalken, vestbo, webkit.review.bot
Priority: P1 Keywords: Qt, QtTriaged
Version: 420+   
Hardware: All   
OS: All   
Bug Depends on: 90612    
Bug Blocks: 88300    
Attachments:
Description Flags
Use the defines that cause WTF and JavaScriptCore's headers to export, not import, their symbols
none
Make sure not to dllimport WTF/JavaScriptCore symbols
none
Patch
none
Patch
none
Patch
kevino: review-
Patch
vestbo: review+
Patch none

Csaba Osztrogonác
Reported 2012-06-05 04:29:26 PDT
It fails because of 36 unresolved externals: qwebframe.obj : error LNK2019: unresolved external symbol __imp__JSValueMakeUndefined referenced in function "struct OpaqueJSValue const * __cdecl qtSenderCallback(struct OpaqueJSContext const *,struct OpaqueJSValue *,struct OpaqueJSValue *,unsigned int,struct OpaqueJSValue const * const * const,struct OpaqueJSValue const * *)" (?qtSenderCallback@@YAPBUOpaqueJSValue@@PBUOpaqueJSContext@@PAU1@1IQBQBU1@PAPBU1@@Z) WebCore.lib(JSInjectedScriptManager.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) class JSC::JSValue __cdecl JSC::evaluate(class JSC::ExecState *,class JSC::ScopeChainNode *,class JSC::SourceCode const &,class JSC::JSValue,class JSC::JSValue *)" (__imp_?evaluate@JSC@@YA?AVJSValue@1@PAVExecState@1@PAVScopeChainNode@1@ABVSourceCode@1@V21@PAV21@@Z) qwebelement.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class JSC::JSValue __cdecl JSC::evaluate(class JSC::ExecState *,class JSC::ScopeChainNode *,class JSC::SourceCode const &,class JSC::JSValue,class JSC::JSValue *)" (__imp_?evaluate@JSC@@YA?AVJSValue@1@PAVExecState@1@PAVScopeChainNode@1@ABVSourceCode@1@V21@PAV21@@Z) referenced in function "public: class QVariant __thiscall QWebElement::evaluateJavaScript(class QString const &)" (?evaluateJavaScript@QWebElement@@QAE?AVQVariant@@ABVQString@@@Z) WebCore.lib(ScriptController.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) class JSC::JSValue __cdecl JSC::evaluate(class JSC::ExecState *,class JSC::ScopeChainNode *,class JSC::SourceCode const &,class JSC::JSValue,class JSC::JSValue *)" (__imp_?evaluate@JSC@@YA?AVJSValue@1@PAVExecState@1@PAVScopeChainNode@1@ABVSourceCode@1@V21@PAV21@@Z) WebCore.lib(NP_jsobject.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) class JSC::JSValue __cdecl JSC::evaluate(class JSC::ExecState *,class JSC::ScopeChainNode *,class JSC::SourceCode const &,class JSC::JSValue,class JSC::JSValue *)" (__imp_?evaluate@JSC@@YA?AVJSValue@1@PAVExecState@1@PAVScopeChainNode@1@ABVSourceCode@1@V21@PAV21@@Z) WebCore.lib(WorkerScriptController.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) class JSC::JSValue __cdecl JSC::evaluate(class JSC::ExecState *,class JSC::ScopeChainNode *,class JSC::SourceCode const &,class JSC::JSValue,class JSC::JSValue *)" (__imp_?evaluate@JSC@@YA?AVJSValue@1@PAVExecState@1@PAVScopeChainNode@1@ABVSourceCode@1@V21@PAV21@@Z) InitWebCoreQt.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl WTF::initializeMainThread(void)" (__imp_?initializeMainThread@WTF@@YAXXZ) referenced in function "void __cdecl WebCore::initializeWebCoreQt(void)" (?initializeWebCoreQt@WebCore@@YAXXZ) WebCore.lib(ScriptController.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl WTF::initializeMainThread(void)" (__imp_?initializeMainThread@WTF@@YAXXZ) InspectorServerQt.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::MD5::checksum(class WTF::Vector<unsigned char,16> &)" (__imp_?checksum@MD5@WTF@@QAEXAAV?$Vector@E$0BA@@2@@Z) referenced in function "void __cdecl WebCore::generateWebSocketChallengeResponse(unsigned int,unsigned int,unsigned char const * const,unsigned char * const)" (?generateWebSocketChallengeResponse@WebCore@@YAXIIQBEQAE@Z) WebCore.lib(WebSocketHandshake.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::MD5::checksum(class WTF::Vector<unsigned char,16> &)" (__imp_?checksum@MD5@WTF@@QAEXAAV?$Vector@E$0BA@@2@@Z) InspectorServerQt.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::MD5::addBytes(unsigned char const *,unsigned int)" (__imp_?addBytes@MD5@WTF@@QAEXPBEI@Z) referenced in function "void __cdecl WebCore::generateWebSocketChallengeResponse(unsigned int,unsigned int,unsigned char const * const,unsigned char * const)" (?generateWebSocketChallengeResponse@WebCore@@YAXIIQBEQAE@Z) WebCore.lib(WebSocketHandshake.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::MD5::addBytes(unsigned char const *,unsigned int)" (__imp_?addBytes@MD5@WTF@@QAEXPBEI@Z) InspectorServerQt.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall WTF::MD5::MD5(void)" (__imp_??0MD5@WTF@@QAE@XZ) referenced in function "void __cdecl WebCore::generateWebSocketChallengeResponse(unsigned int,unsigned int,unsigned char const * const,unsigned char * const)" (?generateWebSocketChallengeResponse@WebCore@@YAXIIQBEQAE@Z) WebCore.lib(WebSocketHandshake.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall WTF::MD5::MD5(void)" (__imp_??0MD5@WTF@@QAE@XZ) WebCore.lib(Document.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) bool __cdecl WTF::isMainThread(void)" (__imp_?isMainThread@WTF@@YA_NXZ) referenced in function "public: virtual bool __thiscall WebCore::Document::isContextThread(void)const " (?isContextThread@Document@WebCore@@UBE_NXZ) WebCore.lib(ThreadTimers.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) bool __cdecl WTF::isMainThread(void)" (__imp_?isMainThread@WTF@@YA_NXZ) WebCore.lib(ThreadableBlobRegistry.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) bool __cdecl WTF::isMainThread(void)" (__imp_?isMainThread@WTF@@YA_NXZ) WebCore.lib(StorageTracker.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) bool __cdecl WTF::isMainThread(void)" (__imp_?isMainThread@WTF@@YA_NXZ) WebCore.lib(ThreadableBlobRegistry.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl WTF::callOnMainThread(void (__cdecl*)(void *),void *)" (__imp_?callOnMainThread@WTF@@YAXP6AXPAX@Z0@Z) WebCore.lib(BlobResourceHandle.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl WTF::callOnMainThread(void (__cdecl*)(void *),void *)" (__imp_?callOnMainThread@WTF@@YAXP6AXPAX@Z0@Z) WebCore.lib(StorageTracker.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl WTF::callOnMainThread(void (__cdecl*)(void *),void *)" (__imp_?callOnMainThread@WTF@@YAXP6AXPAX@Z0@Z) WebCore.lib(Document.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl WTF::callOnMainThread(void (__cdecl*)(void *),void *)" (__imp_?callOnMainThread@WTF@@YAXP6AXPAX@Z0@Z) referenced in function "public: virtual void __thiscall WebCore::Document::postTask(class WTF::PassOwnPtr<class WebCore::ScriptExecutionContext::Task>)" (?postTask@Document@WebCore@@UAEXV?$PassOwnPtr@VTask@ScriptExecutionContext@WebCore@@@WTF@@@Z) WebCore.lib(IconDatabase.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl WTF::callOnMainThread(void (__cdecl*)(void *),void *)" (__imp_?callOnMainThread@WTF@@YAXP6AXPAX@Z0@Z) WebCore.lib(DatabaseTracker.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl WTF::callOnMainThread(void (__cdecl*)(void *),void *)" (__imp_?callOnMainThread@WTF@@YAXP6AXPAX@Z0@Z) WebCore.lib(PluginMainThreadScheduler.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl WTF::callOnMainThread(void (__cdecl*)(void *),void *)" (__imp_?callOnMainThread@WTF@@YAXP6AXPAX@Z0@Z) WebCore.lib(FEGaussianBlur.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSUint8Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSInt8Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(ImageData.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(FilterEffect.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSUint32Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSInt32Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSUint16Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSInt16Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSFloat64ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(DataView.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSFloat64Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSFloat32Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSUint16ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSInt32ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSUint32ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSFloat32ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSUint8ClampedArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSInt8ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSUint8ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSInt16ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(qt_runtime.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) referenced in function "public: virtual __thiscall WTF::TypedArrayBase<unsigned char>::~TypedArrayBase<unsigned char>(void)" (??1?$TypedArrayBase@E@WTF@@UAE@XZ) WebCore.lib(SerializedScriptValue.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(ImageBufferQt.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(JSUint8ClampedArray.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __thiscall WTF::ArrayBufferView::~ArrayBufferView(void)" (__imp_??1ArrayBufferView@WTF@@UAE@XZ) WebCore.lib(qt_runtime.obj) : error LNK2019: unresolved external symbol __imp__JSValueIsEqual referenced in function "public: bool __thiscall JSC::Bindings::QtConnectionObject::match(struct OpaqueJSContext const *,class QObject *,int,struct OpaqueJSValue *,struct OpaqueJSValue *)" (?match@QtConnectionObject@Bindings@JSC@@QAE_NPBUOpaqueJSContext@@PAVQObject@@HPAUOpaqueJSValue@@2@Z) WebCore.lib(ScriptValue.obj) : error LNK2001: unresolved external symbol __imp__JSValueIsEqual WebCore.lib(qt_runtime.obj) : error LNK2019: unresolved external symbol __imp__JSValueProtect referenced in function "public: __thiscall JSC::Bindings::QtConnectionObject::QtConnectionObject(struct OpaqueJSContext const *,class WTF::PassRefPtr<class JSC::Bindings::QtInstance>,int,struct OpaqueJSValue *,struct OpaqueJSValue *)" (??0QtConnectionObject@Bindings@JSC@@QAE@PBUOpaqueJSContext@@V?$PassRefPtr@VQtInstance@Bindings@JSC@@@WTF@@HPAUOpaqueJSValue@@2@Z) WebCore.lib(FEGaussianBlur.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSUint8Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSInt8Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(ImageData.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(FilterEffect.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSUint32Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSInt32Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSUint16Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSInt16Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSFloat64ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(DataView.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSFloat64Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSFloat32Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSUint16ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSInt32ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSUint32ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSFloat32ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSUint8ClampedArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSInt8ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSUint8ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSInt16ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(qt_runtime.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) referenced in function "protected: __thiscall WTF::TypedArrayBase<unsigned char>::TypedArrayBase<unsigned char>(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int,unsigned int)" (??0?$TypedArrayBase@E@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@II@Z) WebCore.lib(SerializedScriptValue.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(ImageBufferQt.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(JSUint8ClampedArray.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __thiscall WTF::ArrayBufferView::ArrayBufferView(class WTF::PassRefPtr<class WTF::ArrayBuffer>,unsigned int)" (__imp_??0ArrayBufferView@WTF@@IAE@V?$PassRefPtr@VArrayBuffer@WTF@@@1@I@Z) WebCore.lib(FEGaussianBlur.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSUint8Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSInt8Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(ImageData.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(FilterEffect.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSUint32Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSInt32Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSUint16Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSInt16Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSFloat64ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(DataView.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSFloat64Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSFloat32Array.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSUint16ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSInt32ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSUint32ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSFloat32ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSUint8ClampedArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSInt8ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSUint8ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSInt16ArrayCustom.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(qt_runtime.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) referenced in function "protected: virtual void __thiscall WTF::TypedArrayBase<unsigned char>::neuter(void)" (?neuter@?$TypedArrayBase@E@WTF@@MAEXXZ) WebCore.lib(SerializedScriptValue.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(ImageBufferQt.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(JSUint8ClampedArray.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: virtual void __thiscall WTF::ArrayBufferView::neuter(void)" (__imp_?neuter@ArrayBufferView@WTF@@MAEXXZ) WebCore.lib(qt_runtime.obj) : error LNK2019: unresolved external symbol __imp__JSValueUnprotect referenced in function "public: virtual __thiscall JSC::Bindings::QtConnectionObject::~QtConnectionObject(void)" (??1QtConnectionObject@Bindings@JSC@@UAE@XZ) WebCore.lib(qt_runtime.obj) : error LNK2019: unresolved external symbol __imp__JSValueToNumber referenced in function "public: void __thiscall JSC::Bindings::QtConnectionObject::execute(void * *)" (?execute@QtConnectionObject@Bindings@JSC@@QAEXPAPAX@Z) WebCore.lib(Color.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: unsigned int __thiscall WTF::DecimalNumber::toStringDecimal(wchar_t *,unsigned int)const " (__imp_?toStringDecimal@DecimalNumber@WTF@@QBEIPA_WI@Z) referenced in function "public: class WTF::String __thiscall WebCore::Color::serialized(void)const " (?serialized@Color@WebCore@@QBE?AVString@WTF@@XZ) WebCore.lib(CSSPrimitiveValue.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: unsigned int __thiscall WTF::DecimalNumber::toStringDecimal(wchar_t *,unsigned int)const " (__imp_?toStringDecimal@DecimalNumber@WTF@@QBEIPA_WI@Z) WebCore.lib(InspectorValues.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: unsigned int __thiscall WTF::DecimalNumber::toStringDecimal(wchar_t *,unsigned int)const " (__imp_?toStringDecimal@DecimalNumber@WTF@@QBEIPA_WI@Z) WebCore.lib(SerializedScriptValue.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: bool __thiscall WTF::ArrayBuffer::transfer(class WTF::ArrayBufferContents &,class WTF::Vector<class WTF::RefPtr<class WTF::ArrayBufferView>,0> &)" (__imp_?transfer@ArrayBuffer@WTF@@QAE_NAAVArrayBufferContents@2@AAV?$Vector@V?$RefPtr@VArrayBufferView@WTF@@@WTF@@$0A@@2@@Z) referenced in function "private: static class WTF::PassOwnPtr<class WTF::Vector<class WTF::ArrayBufferContents,0> > __cdecl WebCore::SerializedScriptValue::transferArrayBuffers(class WTF::Vector<class WTF::RefPtr<class WTF::ArrayBuffer>,1> &,enum WebCore::SerializationReturnCode &)" (?transferArrayBuffers@SerializedScriptValue@WebCore@@CA?AV?$PassOwnPtr@V?$Vector@VArrayBufferContents@WTF@@$0A@@WTF@@@WTF@@AAV?$Vector@V?$RefPtr@VArrayBuffer@WTF@@@WTF@@$00@4@AAW4SerializationReturnCode@2@@Z) WebCore.lib(FormDataBuilder.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) double __cdecl WTF::randomNumber(void)" (__imp_?randomNumber@WTF@@YANXZ) referenced in function "public: static class WTF::Vector<char,0> __cdecl WebCore::FormDataBuilder::generateUniqueBoundaryString(void)" (?generateUniqueBoundaryString@FormDataBuilder@WebCore@@SA?AV?$Vector@D$0A@@WTF@@XZ) WebCore.lib(JSDOMGlobalObject.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) double __cdecl WTF::randomNumber(void)" (__imp_?randomNumber@WTF@@YANXZ) WebCore.lib(JSDOMWindowShell.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) protected: void __thiscall JSC::JSGlobalThis::setUnwrappedObject(class JSC::JSGlobalData &,class JSC::JSGlobalObject *)" (__imp_?setUnwrappedObject@JSGlobalThis@JSC@@IAEXAAVJSGlobalData@2@PAVJSGlobalObject@2@@Z) referenced in function "public: void __thiscall WebCore::JSDOMWindowShell::setWindow(class JSC::JSGlobalData &,class WebCore::JSDOMWindow *)" (?setWindow@JSDOMWindowShell@WebCore@@QAEXAAVJSGlobalData@JSC@@PAVJSDOMWindow@2@@Z) WebCore.lib(ScriptCachedFrameData.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: void __thiscall JSC::JSGlobalThis::setUnwrappedObject(class JSC::JSGlobalData &,class JSC::JSGlobalObject *)" (__imp_?setUnwrappedObject@JSGlobalThis@JSC@@IAEXAAVJSGlobalData@2@PAVJSGlobalObject@2@@Z) WebCore.lib(JSDOMWindowShell.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) protected: static void __cdecl JSC::JSGlobalThis::visitChildren(class JSC::JSCell *,class JSC::SlotVisitor &)" (__imp_?visitChildren@JSGlobalThis@JSC@@KAXPAVJSCell@2@AAVSlotVisitor@2@@Z) referenced in function "void __cdecl `dynamic initializer for 'public: static struct JSC::ClassInfo const WebCore::JSDOMWindowShell::s_info''(void)" (??__E?s_info@JSDOMWindowShell@WebCore@@2UClassInfo@JSC@@B@@YAXXZ) WebCore.lib(JSDOMWindowShell.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static struct JSC::ClassInfo const JSC::JSGlobalThis::s_info" (__imp_?s_info@JSGlobalThis@JSC@@2UClassInfo@2@B) referenced in function "void __cdecl `dynamic initializer for 'public: static struct JSC::ClassInfo const WebCore::JSDOMWindowShell::s_info''(void)" (??__E?s_info@JSDOMWindowShell@WebCore@@2UClassInfo@JSC@@B@@YAXXZ) WebCore.lib(CSSPrimitiveValue.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: unsigned int __thiscall WTF::DecimalNumber::bufferLengthForStringDecimal(void)const " (__imp_?bufferLengthForStringDecimal@DecimalNumber@WTF@@QBEIXZ) referenced in function "class WTF::String __cdecl WebCore::formatNumber(double)" (?formatNumber@WebCore@@YA?AVString@WTF@@N@Z) WebCore.lib(InspectorValues.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: unsigned int __thiscall WTF::DecimalNumber::bufferLengthForStringDecimal(void)const " (__imp_?bufferLengthForStringDecimal@DecimalNumber@WTF@@QBEIXZ) WebCore.lib(PluginViewWin.obj) : error LNK2019: unresolved external symbol "public: struct HDC__ * __thiscall WebCore::GraphicsContext::getWindowsContext(class WebCore::IntRect const &,bool,bool)" (?getWindowsContext@GraphicsContext@WebCore@@QAEPAUHDC__@@ABVIntRect@2@_N1@Z) referenced in function "public: __thiscall WebCore::LocalWindowsContext::LocalWindowsContext(class WebCore::GraphicsContext *,class WebCore::IntRect const &,bool,bool)" (??0LocalWindowsContext@WebCore@@QAE@PAVGraphicsContext@1@ABVIntRect@1@_N2@Z) WebCore.lib(PluginViewWin.obj) : error LNK2019: unresolved external symbol "public: void __thiscall WebCore::GraphicsContext::releaseWindowsContext(struct HDC__ *,class WebCore::IntRect const &,bool,bool)" (?releaseWindowsContext@GraphicsContext@WebCore@@QAEXPAUHDC__@@ABVIntRect@2@_N2@Z) referenced in function "public: __thiscall WebCore::LocalWindowsContext::~LocalWindowsContext(void)" (??1LocalWindowsContext@WebCore@@QAE@XZ) WebCore.lib(InspectorValues.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: unsigned int __thiscall WTF::DecimalNumber::toStringExponential(wchar_t *,unsigned int)const " (__imp_?toStringExponential@DecimalNumber@WTF@@QBEIPA_WI@Z) referenced in function "public: virtual void __thiscall WebCore::InspectorBasicValue::writeJSON(class WTF::StringBuilder *)const " (?writeJSON@InspectorBasicValue@WebCore@@UBEXPAVStringBuilder@WTF@@@Z) WebCore.lib(InspectorValues.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: unsigned int __thiscall WTF::DecimalNumber::bufferLengthForStringExponential(void)const " (__imp_?bufferLengthForStringExponential@DecimalNumber@WTF@@QBEIXZ) referenced in function "public: virtual void __thiscall WebCore::InspectorBasicValue::writeJSON(class WTF::StringBuilder *)const " (?writeJSON@InspectorBasicValue@WebCore@@UBEXPAVStringBuilder@WTF@@@Z) WebCore.lib(FELighting.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::ParallelEnvironment::execute(void *)" (__imp_?execute@ParallelEnvironment@WTF@@QAEXPAX@Z) WebCore.lib(FEGaussianBlur.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::ParallelEnvironment::execute(void *)" (__imp_?execute@ParallelEnvironment@WTF@@QAEXPAX@Z) referenced in function "public: void __thiscall WTF::ParallelJobs<struct WebCore::FEGaussianBlur::PlatformApplyParameters>::execute(void)" (?execute@?$ParallelJobs@UPlatformApplyParameters@FEGaussianBlur@WebCore@@@WTF@@QAEXXZ) WebCore.lib(FEConvolveMatrix.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::ParallelEnvironment::execute(void *)" (__imp_?execute@ParallelEnvironment@WTF@@QAEXPAX@Z) WebCore.lib(FEMorphology.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::ParallelEnvironment::execute(void *)" (__imp_?execute@ParallelEnvironment@WTF@@QAEXPAX@Z) WebCore.lib(FETurbulence.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::ParallelEnvironment::execute(void *)" (__imp_?execute@ParallelEnvironment@WTF@@QAEXPAX@Z) WebCore.lib(FELighting.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall WTF::ParallelEnvironment::ParallelEnvironment(void (__cdecl*)(void *),unsigned int,int)" (__imp_??0ParallelEnvironment@WTF@@QAE@P6AXPAX@ZIH@Z) WebCore.lib(FEGaussianBlur.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall WTF::ParallelEnvironment::ParallelEnvironment(void (__cdecl*)(void *),unsigned int,int)" (__imp_??0ParallelEnvironment@WTF@@QAE@P6AXPAX@ZIH@Z) referenced in function "public: __thiscall WTF::ParallelJobs<struct WebCore::FEGaussianBlur::PlatformApplyParameters>::ParallelJobs<struct WebCore::FEGaussianBlur::PlatformApplyParameters>(void (__cdecl*)(struct WebCore::FEGaussianBlur::PlatformApplyParameters *),int)" (??0?$ParallelJobs@UPlatformApplyParameters@FEGaussianBlur@WebCore@@@WTF@@QAE@P6AXPAUPlatformApplyParameters@FEGaussianBlur@WebCore@@@ZH@Z) WebCore.lib(FEConvolveMatrix.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall WTF::ParallelEnvironment::ParallelEnvironment(void (__cdecl*)(void *),unsigned int,int)" (__imp_??0ParallelEnvironment@WTF@@QAE@P6AXPAX@ZIH@Z) WebCore.lib(FEMorphology.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall WTF::ParallelEnvironment::ParallelEnvironment(void (__cdecl*)(void *),unsigned int,int)" (__imp_??0ParallelEnvironment@WTF@@QAE@P6AXPAX@ZIH@Z) WebCore.lib(FETurbulence.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall WTF::ParallelEnvironment::ParallelEnvironment(void (__cdecl*)(void *),unsigned int,int)" (__imp_??0ParallelEnvironment@WTF@@QAE@P6AXPAX@ZIH@Z) WebCore.lib(DOMPatchSupport.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::SHA1::addBytes(unsigned char const *,unsigned int)" (__imp_?addBytes@SHA1@WTF@@QAEXPBEI@Z) referenced in function "void __cdecl WebCore::addStringToSHA1(class WTF::SHA1 &,class WTF::String const &)" (?addStringToSHA1@WebCore@@YAXAAVSHA1@WTF@@ABVString@3@@Z) WebCore.lib(WebSocketHandshake.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::SHA1::addBytes(unsigned char const *,unsigned int)" (__imp_?addBytes@SHA1@WTF@@QAEXPBEI@Z) WebCore.lib(DOMPatchSupport.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::SHA1::computeHash(class WTF::Vector<unsigned char,20> &)" (__imp_?computeHash@SHA1@WTF@@QAEXAAV?$Vector@E$0BE@@2@@Z) referenced in function "private: class WTF::PassOwnPtr<struct WebCore::DOMPatchSupport::Digest> __thiscall WebCore::DOMPatchSupport::createDigest(class WebCore::Node *,class WTF::HashMap<class WTF::String,struct WebCore::DOMPatchSupport::Digest *,struct WTF::StringHash,struct WTF::HashTraits<class WTF::String>,struct WTF::HashTraits<struct WebCore::DOMPatchSupport::Digest *> > *)" (?createDigest@DOMPatchSupport@WebCore@@AAE?AV?$PassOwnPtr@UDigest@DOMPatchSupport@WebCore@@@WTF@@PAVNode@2@PAV?$HashMap@VString@WTF@@PAUDigest@DOMPatchSupport@WebCore@@UStringHash@2@U?$HashTraits@VString@WTF@@@2@U?$HashTraits@PAUDigest@DOMPatchSupport@WebCore@@@2@@4@@Z) WebCore.lib(WebSocketHandshake.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __thiscall WTF::SHA1::computeHash(class WTF::Vector<unsigned char,20> &)" (__imp_?computeHash@SHA1@WTF@@QAEXAAV?$Vector@E$0BE@@2@@Z) WebCore.lib(DOMPatchSupport.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall WTF::SHA1::SHA1(void)" (__imp_??0SHA1@WTF@@QAE@XZ) referenced in function "private: class WTF::PassOwnPtr<struct WebCore::DOMPatchSupport::Digest> __thiscall WebCore::DOMPatchSupport::createDigest(class WebCore::Node *,class WTF::HashMap<class WTF::String,struct WebCore::DOMPatchSupport::Digest *,struct WTF::StringHash,struct WTF::HashTraits<class WTF::String>,struct WTF::HashTraits<struct WebCore::DOMPatchSupport::Digest *> > *)" (?createDigest@DOMPatchSupport@WebCore@@AAE?AV?$PassOwnPtr@UDigest@DOMPatchSupport@WebCore@@@WTF@@PAVNode@2@PAV?$HashMap@VString@WTF@@PAUDigest@DOMPatchSupport@WebCore@@UStringHash@2@U?$HashTraits@VString@WTF@@@2@U?$HashTraits@PAUDigest@DOMPatchSupport@WebCore@@@2@@4@@Z) WebCore.lib(WebSocketHandshake.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall WTF::SHA1::SHA1(void)" (__imp_??0SHA1@WTF@@QAE@XZ) WebCore.lib(PageScriptDebugServer.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl WTF::setMainThreadCallbacksPaused(bool)" (__imp_?setMainThreadCallbacksPaused@WTF@@YAX_N@Z) referenced in function "private: void __thiscall WebCore::PageScriptDebugServer::setJavaScriptPaused(class WebCore::PageGroup const &,bool)" (?setJavaScriptPaused@PageScriptDebugServer@WebCore@@AAEXABVPageGroup@2@_N@Z) WebCore.lib(JavaScriptCallFrame.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: enum JSC::DebuggerCallFrame::Type __thiscall JSC::DebuggerCallFrame::type(void)const " (__imp_?type@DebuggerCallFrame@JSC@@QBE?AW4Type@12@XZ) referenced in function "public: enum JSC::DebuggerCallFrame::Type __thiscall WebCore::JavaScriptCallFrame::type(void)const " (?type@JavaScriptCallFrame@WebCore@@QBE?AW4Type@DebuggerCallFrame@JSC@@XZ) WebCore.lib(JavaScriptCallFrame.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class JSC::JSObject * __thiscall JSC::DebuggerCallFrame::thisObject(void)const " (__imp_?thisObject@DebuggerCallFrame@JSC@@QBEPAVJSObject@2@XZ) referenced in function "public: class JSC::JSObject * __thiscall WebCore::JavaScriptCallFrame::thisObject(void)const " (?thisObject@JavaScriptCallFrame@WebCore@@QBEPAVJSObject@JSC@@XZ) WebCore.lib(JavaScriptCallFrame.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class JSC::JSValue __thiscall JSC::DebuggerCallFrame::evaluate(class JSC::UString const &,class JSC::JSValue &)const " (__imp_?evaluate@DebuggerCallFrame@JSC@@QBE?AVJSValue@2@ABVUString@2@AAV32@@Z) referenced in function "public: class JSC::JSValue __thiscall WebCore::JavaScriptCallFrame::evaluate(class JSC::UString const &,class JSC::JSValue &)const " (?evaluate@JavaScriptCallFrame@WebCore@@QBE?AVJSValue@JSC@@ABVUString@4@AAV34@@Z) WebCore.lib(JavaScriptCallFrame.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class JSC::UString __thiscall JSC::DebuggerCallFrame::calculatedFunctionName(void)const " (__imp_?calculatedFunctionName@DebuggerCallFrame@JSC@@QBE?AVUString@2@XZ) referenced in function "public: class WTF::String __thiscall WebCore::JavaScriptCallFrame::functionName(void)const " (?functionName@JavaScriptCallFrame@WebCore@@QBE?AVString@WTF@@XZ) ..\lib\QtWebKit5.dll : fatal error LNK1120: 36 unresolved externals
Attachments
Use the defines that cause WTF and JavaScriptCore's headers to export, not import, their symbols (641 bytes, patch)
2012-06-11 08:09 PDT, Joel Dillon 		no flags
DetailsFormatted DiffDiff
Make sure not to dllimport WTF/JavaScriptCore symbols (797 bytes, patch)
2012-06-11 08:32 PDT, Joel Dillon 		no flags
DetailsFormatted DiffDiff
Patch (8.38 KB, patch)
2012-06-13 08:35 PDT, Jocelyn Turcotte 		no flags
DetailsFormatted DiffDiff
Patch (8.55 KB, patch)
2012-06-13 08:42 PDT, Jocelyn Turcotte 		no flags
DetailsFormatted DiffDiff
Patch (9.25 KB, patch)
2012-06-13 10:44 PDT, Jocelyn Turcotte 		kevino: review-
DetailsFormatted DiffDiff
Patch (11.34 KB, patch)
2012-06-27 09:53 PDT, Jocelyn Turcotte 		vestbo: review+
DetailsFormatted DiffDiff
Patch (10.30 KB, patch)
2012-06-29 08:15 PDT, Jocelyn Turcotte 		no flags
DetailsFormatted DiffDiff
Show Obsolete (6) View All Add attachment proposed patch, testcase, etc.
Csaba Osztrogonác
Comment 1 2012-06-05 04:34:02 PDT
It would be useful: http://trac.webkit.org/wiki/ExportingSymbols
Csaba Osztrogonác
Comment 2 2012-06-07 07:54:28 PDT
Any volunteer to fix it?
Balazs Kelemen
Comment 3 2012-06-08 10:22:42 PDT
I believe the problem is caused by cross-lib dependencies and culprit is this: functions.prf: defineTest(linkAgainstLibrary) mac { LIBS += -Wl,-force_load,$${path}$${QMAKE_DIR_SEP}lib$${target}.a } else:win32-msvc*|wince*|win32-icc { LIBS += /OPT:REF -l$$target } else { LIBS += -Wl,-whole-archive -l$$target -Wl,-no-whole-archive } Seems to me that for win we don't specify that we need the whole static library. I guess the force_static_libs_as_shared CONFIG switch would fix the build, but it's not for production builds. We need the appropriate linker option for MSVC.
Balazs Kelemen
Comment 4 2012-06-08 10:27:29 PDT
According to http://msdn.microsoft.com/en-US/library/bxwfs976%28v=VS.80%29.aspx /OPT:NOREF instead of /OPT:REF may solve this.
Simon Hausmann
Comment 5 2012-06-10 02:27:43 PDT
(In reply to comment #4) > According to http://msdn.microsoft.com/en-US/library/bxwfs976%28v=VS.80%29.aspx /OPT:NOREF instead of /OPT:REF may solve this. You're right. I got it wrong when I added this, NOREF is the right switch to use.
Csaba Osztrogonác
Comment 6 2012-06-11 06:03:58 PDT
I tried s/OPT:REF/OPT:NOREF , but it didn't help for me.
Csaba Osztrogonác
Comment 7 2012-06-11 07:49:43 PDT
~ArrayBufferView and neuter fails are related to this change - http://trac.webkit.org/changeset/112558
Joel Dillon
Comment 8 2012-06-11 08:09:38 PDT
Created attachment 146857 [details] Use the defines that cause WTF and JavaScriptCore's headers to export, not import, their symbols
Joel Dillon
Comment 9 2012-06-11 08:11:34 PDT
(In reply to comment #8) > Created an attachment (id=146857) [details] > Use the defines that cause WTF and JavaScriptCore's headers to export, not import, their symbols This is how I fixed it. It's probably not as nice a solution, though.
Csaba Osztrogonác
Comment 10 2012-06-11 08:27:32 PDT
(In reply to comment #9) > (In reply to comment #8) > > Created an attachment (id=146857) [details] [details] > > Use the defines that cause WTF and JavaScriptCore's headers to export, not import, their symbols > > This is how I fixed it. It's probably not as nice a solution, though. Nothing changed for me with this workaroud, I still get the attached fails. :(
Joel Dillon
Comment 11 2012-06-11 08:32:38 PDT
Created attachment 146860 [details] Make sure not to dllimport WTF/JavaScriptCore symbols Sorry, this patch, though I did need the other one too.
Csaba Osztrogonác
Comment 12 2012-06-12 00:44:48 PDT
I tried these patches, but unfortunately nothing changed for me. But I started to understand import/export macros and how QtWebKit libraries linking work on Windows. If I'm correct, we have JavaScriptcore.lib, WTF.lib and WebCore.lib as static libraries. And then we try to link QtWebKit5.dll from API objects and from theses static libraries. In this case we shouldn't use export macros during building JavaScriptCore, WTF and WebCore _and_ we shouldn't use import macros during linking QtWebKit5.dll. (As far as I know export/import macros are only useable for creating/using dlls) I tried to add "DEFINES += WTF_USE_EXPORT_MACROS=0" to JavaScriptCore.pri, WebCore.pri and WTF.pri and then I got only 8 unresolved external instead of 36: qwebframe.obj : error LNK2019: unresolved external symbol __imp__JSValueMakeUndefined referenced in function "struct OpaqueJSValue const * __cdecl qtSenderCallback(struct OpaqueJSContext const *,struct OpaqueJSValue *,struct OpaqueJSValue *,unsigned int,struct OpaqueJSValue const * const * const,struct OpaqueJSValue const * *)" (?qtSenderCallback@@YAPBUOpaqueJSValue@@PBUOpaqueJSContext@@PAU1@1IQBQBU1@PAPBU1@@Z) WebCore.lib(qt_runtime.obj) : error LNK2019: unresolved external symbol __imp__JSValueIsEqual referenced in function "public: bool __thiscall JSC::Bindings::QtConnectionObject::match(struct OpaqueJSContext const *,class QObject *,int,struct OpaqueJSValue *,struct OpaqueJSValue *)" (?match@QtConnectionObject@Bindings@JSC@@QAE_NPBUOpaqueJSContext@@PAVQObject@@HPAUOpaqueJSValue@@2@Z) WebCore.lib(ScriptValue.obj) : error LNK2001: unresolved external symbol __imp__JSValueIsEqual WebCore.lib(qt_runtime.obj) : error LNK2019: unresolved external symbol __imp__JSValueProtect referenced in function "public: __thiscall JSC::Bindings::QtConnectionObject::QtConnectionObject(struct OpaqueJSContext const *,class WTF::PassRefPtr<class JSC::Bindings::QtInstance>,int,struct OpaqueJSValue *,struct OpaqueJSValue *)" (??0QtConnectionObject@Bindings@JSC@@QAE@PBUOpaqueJSContext@@V?$PassRefPtr@VQtInstance@Bindings@JSC@@@WTF@@HPAUOpaqueJSValue@@2@Z) WebCore.lib(qt_runtime.obj) : error LNK2019: unresolved external symbol __imp__JSValueUnprotect referenced in function "public: virtual __thiscall JSC::Bindings::QtConnectionObject::~QtConnectionObject(void)" (??1QtConnectionObject@Bindings@JSC@@UAE@XZ) WebCore.lib(qt_runtime.obj) : error LNK2019: unresolved external symbol __imp__JSValueToNumber referenced in function "public: void __thiscall JSC::Bindings::QtConnectionObject::execute(void * *)" (?execute@QtConnectionObject@Bindings@JSC@@QAEXPAPAX@Z) WebCore.lib(ImageQt.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) class QPixmap __cdecl WebCore::qt_pixmapFromWinHBITMAP(struct HBITMAP__ *,int)" (__imp_?qt_pixmapFromWinHBITMAP@WebCore@@YA?AVQPixmap@@PAUHBITMAP__@@H@Z) referenced in function "public: static class WTF::PassRefPtr<class WebCore::BitmapImage> __cdecl WebCore::BitmapImage::create(struct HBITMAP__ *)" (?create@BitmapImage@WebCore@@SA?AV?$PassRefPtr@VBitmapImage@WebCore@@@WTF@@PAUHBITMAP__@@@Z) WebCore.lib(PluginViewWin.obj) : error LNK2019: unresolved external symbol "public: struct HDC__ * __thiscall WebCore::GraphicsContext::getWindowsContext(class WebCore::IntRect const &,bool,bool)" (?getWindowsContext@GraphicsContext@WebCore@@QAEPAUHDC__@@ABVIntRect@2@_N1@Z) referenced in function "public: __thiscall WebCore::LocalWindowsContext::LocalWindowsContext(class WebCore::GraphicsContext *,class WebCore::IntRect const &,bool,bool)" (??0LocalWindowsContext@WebCore@@QAE@PAVGraphicsContext@1@ABVIntRect@1@_N2@Z) WebCore.lib(PluginViewWin.obj) : error LNK2019: unresolved external symbol "public: void __thiscall WebCore::GraphicsContext::releaseWindowsContext(struct HDC__ *,class WebCore::IntRect const &,bool,bool)" (?releaseWindowsContext@GraphicsContext@WebCore@@QAEXPAUHDC__@@ABVIntRect@2@_N2@Z) referenced in function "public: __thiscall WebCore::LocalWindowsContext::~LocalWindowsContext(void)" (??1LocalWindowsContext@WebCore@@QAE@XZ) And then I found the reason of JSValue* related unresolved symbols: JSC uses USE_EXPORT_MACROS instead of WTF_USE_EXPORT_MACROS as export/import macros. Now I'm trying disable this one too. PS: I found an old patch (by Simon, r=Tor Arne) enabled import/export macros on Qt - http://trac.webkit.org/changeset/106650 . Could you check it, please? I think we should enable import/export macros during linking QtWebKit5.dll only, don't we?
Csaba Osztrogonác
Comment 13 2012-06-12 01:33:55 PDT
Now I have only 3 unresolved external: WebCore.lib(ImageQt.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) class QPixmap __cdecl WebCore::qt_pixmapFromWinHBITMAP(struct HBITMAP__ *,int)" (__imp_?qt_pixmapFromWinHBITMAP@WebCore@@YA?AVQPixmap@@PAUHBITMAP__@@H@Z) referenced in function "public: static class WTF::PassRefPtr<class WebCore::BitmapImage> __cdecl WebCore::BitmapImage::create(struct HBITMAP__ *)" (?create@BitmapImage@WebCore@@SA?AV?$PassRefPtr@VBitmapImage@WebCore@@@WTF@@PAUHBITMAP__@@@Z) WebCore.lib(PluginViewWin.obj) : error LNK2019: unresolved external symbol "public: struct HDC__ * __thiscall WebCore::GraphicsContext::getWindowsContext(class WebCore::IntRect const &,bool,bool)" (?getWindowsContext@GraphicsContext@WebCore@@QAEPAUHDC__@@ABVIntRect@2@_N1@Z) referenced in function "public: __thiscall WebCore::LocalWindowsContext::LocalWindowsContext(class WebCore::GraphicsContext *,class WebCore::IntRect const &,bool,bool)" (??0LocalWindowsContext@WebCore@@QAE@PAVGraphicsContext@1@ABVIntRect@1@_N2@Z) WebCore.lib(PluginViewWin.obj) : error LNK2019: unresolved external symbol "public: void __thiscall WebCore::GraphicsContext::releaseWindowsContext(struct HDC__ *,class WebCore::IntRect const &,bool,bool)" (?releaseWindowsContext@GraphicsContext@WebCore@@QAEXPAUHDC__@@ABVIntRect@2@_N2@Z) referenced in function "public: __thiscall WebCore::LocalWindowsContext::~LocalWindowsContext(void)" (??1LocalWindowsContext@WebCore@@QAE@XZ) . I'm digging them ...
Csaba Osztrogonác
Comment 14 2012-06-12 01:42:03 PDT
ImageQt.obj problem is come from this change - http://trac.webkit.org/changeset/119924/trunk/Source/WebCore/platform/graphics/qt/ImageQt.cpp Is this function exported to QtXXXX.dll?
Joel Dillon
Comment 15 2012-06-12 01:52:41 PDT
(In reply to comment #14) > ImageQt.obj problem is come from this change - http://trac.webkit.org/changeset/119924/trunk/Source/WebCore/platform/graphics/qt/ImageQt.cpp > > Is this function exported to QtXXXX.dll? My recollection is that it wasn't exported (looked like a private API), so I copied the code into webkit instead. Might be better to change qtbase to export it, though? I'm not sure what the rationale was for removing the functionality in the first place, it's useful to Windows developers...
Balazs Kelemen
Comment 16 2012-06-12 01:56:49 PDT
(In reply to comment #15) > (In reply to comment #14) > > ImageQt.obj problem is come from this change - http://trac.webkit.org/changeset/119924/trunk/Source/WebCore/platform/graphics/qt/ImageQt.cpp > > > > Is this function exported to QtXXXX.dll? > > My recollection is that it wasn't exported (looked like a private API), so I copied the code into webkit instead. Might be better to change qtbase to export it, though? I'm not sure what the rationale was for removing the functionality in the first place, it's useful to Windows developers... It should be exported. qtbase/src/gui/image/qpixmap_win.cpp: Q_GUI_EXPORT QPixmap qt_pixmapFromWinHBITMAP(HBITMAP bitmap, int hbitmapFormat = 0) and it is used is several places (printsupport and platform plugin) in the same way as I did. Btw, I don't understand how the hell the Q_GUI_EXPORT declaration turned into __dllspec(dllimport)??? However, if we can't do better than let's copy the code.
Balazs Kelemen
Comment 17 2012-06-12 02:01:35 PDT
(In reply to comment #12) > I tried these patches, but unfortunately nothing changed for me. > > But I started to understand import/export macros and how > QtWebKit libraries linking work on Windows. > > If I'm correct, we have JavaScriptcore.lib, WTF.lib and WebCore.lib as static > libraries. And then we try to link QtWebKit5.dll from API objects and from > theses static libraries. In this case we shouldn't use export macros during > building JavaScriptCore, WTF and WebCore _and_ we shouldn't use import macros > during linking QtWebKit5.dll. (As far as I know export/import macros are only > useable for creating/using dlls) If we don't expose the relevant symbols from jsc, wtf, WebCore, than we can't build WebKitTestRunner (and DRT?). But it can be ok for a beta release :) The question is: is that true that __dllspec(dllexport) can not be used for a static lib?
Csaba Osztrogonác
Comment 18 2012-06-12 02:04:03 PDT
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > ImageQt.obj problem is come from this change - http://trac.webkit.org/changeset/119924/trunk/Source/WebCore/platform/graphics/qt/ImageQt.cpp > > > > > > Is this function exported to QtXXXX.dll? > > > > My recollection is that it wasn't exported (looked like a private API), so I copied the code into webkit instead. Might be better to change qtbase to export it, though? I'm not sure what the rationale was for removing the functionality in the first place, it's useful to Windows developers... > > It should be exported. > qtbase/src/gui/image/qpixmap_win.cpp: > Q_GUI_EXPORT QPixmap qt_pixmapFromWinHBITMAP(HBITMAP bitmap, int hbitmapFormat = 0) > > and it is used is several places (printsupport and platform plugin) in the same way as I did. Btw, I don't understand how the hell the Q_GUI_EXPORT declaration turned into __dllspec(dllimport)??? However, if we can't do better than let's copy the code. It is normal Q_GUI_EXPORT is __declspec(dllexport) when you build the lib and it is __declspec(dllimport) if you use the lib. # define Q_DECL_EXPORT __declspec(dllexport) # define Q_DECL_IMPORT __declspec(dllimport) ... # if defined(QT_BUILD_GUI_LIB) # define Q_GUI_EXPORT Q_DECL_EXPORT # else # define Q_GUI_EXPORT Q_DECL_IMPORT # endif
Csaba Osztrogonác
Comment 19 2012-06-12 04:24:15 PDT
(In reply to comment #18) > (In reply to comment #16) > > (In reply to comment #15) > > > (In reply to comment #14) > > > > ImageQt.obj problem is come from this change - http://trac.webkit.org/changeset/119924/trunk/Source/WebCore/platform/graphics/qt/ImageQt.cpp > > > > > > > > Is this function exported to QtXXXX.dll? > > > > > > My recollection is that it wasn't exported (looked like a private API), so I copied the code into webkit instead. Might be better to change qtbase to export it, though? I'm not sure what the rationale was for removing the functionality in the first place, it's useful to Windows developers... > > > > It should be exported. > > qtbase/src/gui/image/qpixmap_win.cpp: > > Q_GUI_EXPORT QPixmap qt_pixmapFromWinHBITMAP(HBITMAP bitmap, int hbitmapFormat = 0) > > > > and it is used is several places (printsupport and platform plugin) in the same way as I did. Btw, I don't understand how the hell the Q_GUI_EXPORT declaration turned into __dllspec(dllimport)??? However, if we can't do better than let's copy the code. > > It is normal Q_GUI_EXPORT is __declspec(dllexport) when you build > the lib and it is __declspec(dllimport) if you use the lib. > > # define Q_DECL_EXPORT __declspec(dllexport) > # define Q_DECL_IMPORT __declspec(dllimport) > > ... > > # if defined(QT_BUILD_GUI_LIB) > # define Q_GUI_EXPORT Q_DECL_EXPORT > # else > # define Q_GUI_EXPORT Q_DECL_IMPORT > # endif I checked QtQui5.dll with "dumpbin /exports" and it said this symbol is exported: 4565 11D4 0005AE30 ?qt_pixmapFromWinHBITMAP@@YA?AVQPixmap@@PAUHBITMAP__@@H@Z
Andras Becsi
Comment 20 2012-06-12 04:48:22 PDT
Isn't the basic issue that for _each_ sublibrary we do DEFINES += BUILDING_WEBKIT in Tools/qmake/mkspecs/features/default_post.prf, whereas BUILDING_WEBKIT should only be defined in the final linking phase of the dll? At least I remember having similar issues with the old build system which were caused by the wrongly defined BUILDING_WEBKIT.
Tor Arne Vestbø
Comment 21 2012-06-12 05:47:19 PDT
(In reply to comment #20) > Isn't the basic issue that for _each_ sublibrary we do > > DEFINES += BUILDING_WEBKIT > > in Tools/qmake/mkspecs/features/default_post.prf, whereas BUILDING_WEBKIT should only be defined in the final linking phase of the dll? > > At least I remember having similar issues with the old build system which were caused by the wrongly defined BUILDING_WEBKIT. BUILDING_WEBKIT controls the exports for the final QtWebKit library (QWEBKIT_EXPORT), which we have spread out in multiple static libs, and we might use between static libs. So defining BUILDING_WEBKIT for all the static libs is correct AFAICT, so that they are all dllexport.
Andras Becsi
Comment 22 2012-06-12 06:18:07 PDT
(In reply to comment #21) > (In reply to comment #20) > > Isn't the basic issue that for _each_ sublibrary we do > > > > DEFINES += BUILDING_WEBKIT > > > > in Tools/qmake/mkspecs/features/default_post.prf, whereas BUILDING_WEBKIT should only be defined in the final linking phase of the dll? > > > > At least I remember having similar issues with the old build system which were caused by the wrongly defined BUILDING_WEBKIT. > > > BUILDING_WEBKIT controls the exports for the final QtWebKit library (QWEBKIT_EXPORT), which we have spread out in multiple static libs, and we might use between static libs. So defining BUILDING_WEBKIT for all the static libs is correct AFAICT, so that they are all dllexport. But in Source/WebKit/qt/Api/qwebkitglobal.h the "if defined(BUILDING_WEBKIT)" check is guarded by QT_MAKEDLL which is not defined when building a static lib, so we seem to always end up with "define QWEBKIT_EXPORT Q_DECL_IMPORT" when building the static libraries.
Andras Becsi
Comment 23 2012-06-12 06:32:49 PDT
(In reply to comment #22) [snip] > we seem to always end up with "define QWEBKIT_EXPORT Q_DECL_IMPORT" when building the static libraries. Or rather with an empty QWEBKIT_EXPORT, since the other part is guarded with QT_DLL which I suppose is not defined either when building a static sub library. What is the role of QT_SHARED in contrast to QT_MAKEDLL / QT_DLL in this case, and when is it defined?
Jocelyn Turcotte
Comment 24 2012-06-13 08:06:08 PDT
*** Bug 88301 has been marked as a duplicate of this bug. ***
Jocelyn Turcotte
Comment 25 2012-06-13 08:35:10 PDT
Created attachment 147324 [details] Patch
Jocelyn Turcotte
Comment 26 2012-06-13 08:42:05 PDT
Created attachment 147328 [details] Patch Fixing with proper credits.
Simon Hausmann
Comment 27 2012-06-13 08:49:09 PDT
Comment on attachment 147328 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=147328&action=review > Source/JavaScriptCore/API/JSBase.h:74 > -#if defined(BUILDING_JavaScriptCore) || defined(BUILDING_WTF) > +#if defined(BUILDING_JavaScriptCore) || defined(STATICALLY_LINKED_WITH_JavaScriptCore) Isn't this going to break other non-Qt ports that do not set STATICALLY_LINKED_WITH_JavaScriptCore but BUILDING_WTF instead?
Tor Arne Vestbø
Comment 28 2012-06-13 08:54:28 PDT
Comment on attachment 147328 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=147328&action=review > Source/WebCore/platform/PlatformExportMacros.h:38 > +#if defined(BUILDING_WebCore) || defined(BUILDING_WebKit) || \ Isn't this the same pattern as in JSC/WTF, that it should be defined(BUILDING_WebCore) || defined(STATICALLY_LINKED_WITH_WebCore)?
Jocelyn Turcotte
Comment 29 2012-06-13 08:59:47 PDT
(In reply to comment #27) > (From update of attachment 147328 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=147328&action=review > > > Source/JavaScriptCore/API/JSBase.h:74 > > -#if defined(BUILDING_JavaScriptCore) || defined(BUILDING_WTF) > > +#if defined(BUILDING_JavaScriptCore) || defined(STATICALLY_LINKED_WITH_JavaScriptCore) > > Isn't this going to break other non-Qt ports that do not set STATICALLY_LINKED_WITH_JavaScriptCore but BUILDING_WTF instead? Ah damn, my webkit-patch comment didn't make it. Yes this isn't for landing as long as we don't fix the other ports (at least Wx). (In reply to comment #28) > (From update of attachment 147328 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=147328&action=review > > > Source/WebCore/platform/PlatformExportMacros.h:38 > > +#if defined(BUILDING_WebCore) || defined(BUILDING_WebKit) || \ > > Isn't this the same pattern as in JSC/WTF, that it should be defined(BUILDING_WebCore) || defined(STATICALLY_LINKED_WITH_WebCore)? Yes, isn't it on the next line?
Tor Arne Vestbø
Comment 30 2012-06-13 09:06:05 PDT
Comment on attachment 147328 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=147328&action=review >>> Source/WebCore/platform/PlatformExportMacros.h:38 >>> +#if defined(BUILDING_WebCore) || defined(BUILDING_WebKit) || \ >> >> Isn't this the same pattern as in JSC/WTF, that it should be defined(BUILDING_WebCore) || defined(STATICALLY_LINKED_WITH_WebCore)? > > Yes, isn't it on the next line? I was referring to the original defined(BUILDING_WebKit) part, why is it there? Is it the same workaround as #if defined(BUILDING_WTF) || defined(BUILDING_JavaScriptCore) ?
Jocelyn Turcotte
Comment 31 2012-06-13 09:25:56 PDT
(In reply to comment #30) > (From update of attachment 147328 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=147328&action=review > > >>> Source/WebCore/platform/PlatformExportMacros.h:38 > >>> +#if defined(BUILDING_WebCore) || defined(BUILDING_WebKit) || \ > >> > >> Isn't this the same pattern as in JSC/WTF, that it should be defined(BUILDING_WebCore) || defined(STATICALLY_LINKED_WITH_WebCore)? > > > > Yes, isn't it on the next line? > > I was referring to the original defined(BUILDING_WebKit) part, why is it there? Is it the same workaround as #if defined(BUILDING_WTF) || defined(BUILDING_JavaScriptCore) ? I assume it isn't since it's called WEBKIT_EXPORTDATA, but it's hard to tell since this seems to be used only in JSDOMGlobalObject.h.
Jocelyn Turcotte
Comment 32 2012-06-13 10:44:29 PDT
Created attachment 147360 [details] Patch Updated the Wx build to follow the new defines. I couldn't find any other port defining BUILDING_JavaScriptCore that way.
Kevin Ollivier
Comment 33 2012-06-18 23:20:38 PDT
Comment on attachment 147360 [details] Patch I'm not sure about the QT side of the build, but I do not think these macros are correct for wx. The WTF/JS_EXPORT macros are for dynamic libraries only, not static, so macros with names like STATICALLY_LINKED_WITH_WTF are confusing. On the wx port, we simply use export macros when building JSCore and WTF, which is what the defines for our port indicate and does not need changed. I don't know enough about the QT build to say what precisely is going wrong, but it sounds like either the .dll is not importing all symbols from the static library, or there are both static and dynamic build configs for QTWebKit and the scripts are not adjusting the build configurations accordingly.
Jocelyn Turcotte
Comment 34 2012-06-19 03:07:48 PDT
(In reply to comment #33) > (From update of attachment 147360 [details]) > I'm not sure about the QT side of the build, but I do not think these macros are correct for wx. Sorry, I think that the actual problem wasn't properly explained here. The problem is only on Windows, since the import/export status of a symbol is part of its signature. So in our case what we had is that JavaScriptCore, WTF and WebCore are all compiled as static libraries and linked in the final QtWebKit.dll. All of them only define their own BUILDING_*** What happened is that JavaScriptCore defines a symbol, something like: _export_JavaScriptCoreSomething And then WebCore includes its header but since BUILDING_JavaScriptCore isn't defined, the symbol is referred as: _import_JavaScriptCoreSomething And this raise an undefined symbol error when the linking occurs. Both of them should be defined as _export_... In wx it seems like you have fixed this issue between JavaScriptCore and WTF by saying in the WTF header: "Define as an export symbol if I'm building WTF OR JavaScriptCore" So this patch fixes the same issue, but by specifying it explicitly with STATICALLY_LINKED_WITH_WTF instead of relying on WTF headers knowing internally that it is going to be statically linked with JavaScriptCore (plus with WebCore for Qt). If you have any idea on how to improve it please let me know, but I'd like if there were only one solution. Stretching like this in WTF and JavaScriptCore would be pretty nasty and I'd like to avoid it too: #if defined(BUILDING_WTF) || defined(BUILDING_JavaScriptCore) || (PLATFORM(QT) && defined(BUILDING_WebCore)
Kevin Ollivier
Comment 35 2012-06-19 09:05:22 PDT
(In reply to comment #34) > (In reply to comment #33) > > (From update of attachment 147360 [details] [details]) > > I'm not sure about the QT side of the build, but I do not think these macros are correct for wx. > > Sorry, I think that the actual problem wasn't properly explained here. > The problem is only on Windows, since the import/export status of a symbol is part of its signature. The problem is not Windows-only, it sounds like you guys are simply exporting all symbols for gcc (the default behavior there), so you only see the problem on Windows. > So in our case what we had is that JavaScriptCore, WTF and WebCore are all compiled as static libraries and linked in the final QtWebKit.dll. All of them only define their own BUILDING_*** > What happened is that JavaScriptCore defines a symbol, something like: > _export_JavaScriptCoreSomething > And then WebCore includes its header but since BUILDING_JavaScriptCore isn't defined, the symbol is referred as: > _import_JavaScriptCoreSomething > And this raise an undefined symbol error when the linking occurs. Both of them should be defined as _export_... > > In wx it seems like you have fixed this issue between JavaScriptCore and WTF by saying in the WTF header: "Define as an export symbol if I'm building WTF OR JavaScriptCore" The macros are built to assume that you are building JSCore as a dll and statically linking WTF into it. This is how all the other ports that I'm aware of work. Since you instead statically link all of JSCore and WTF into QTWebKit5.dll, you will need to find a solution that only affects the QT build, or, switch the QT build to match what the other ports are doing, which is usually the best approach as it keeps problems like this from cropping up. However, I'm still rather apprehensive that this is really the issue here because QT turned on the use of export macros 5 months ago in r106650. The builds should have immediately failed at that time if QT was building everything statically into QTWebKit5.dll and was not addressing the BUILDING_XYZ defines issue. So why are builds only failing now? Has something recently changed about how QT builds the WebKit dll? Perhaps a change was made recently by someone who was unaware of the export macros issue and only tested the change under Unix platforms? > So this patch fixes the same issue, but by specifying it explicitly with STATICALLY_LINKED_WITH_WTF instead of relying on WTF headers knowing internally that it is going to be statically linked with JavaScriptCore (plus with WebCore for Qt). > > If you have any idea on how to improve it please let me know, but I'd like if there were only one solution. > Stretching like this in WTF and JavaScriptCore would be pretty nasty and I'd like to avoid it too: > #if defined(BUILDING_WTF) || defined(BUILDING_JavaScriptCore) || (PLATFORM(QT) && defined(BUILDING_WebCore)
Jocelyn Turcotte
Comment 36 2012-06-20 06:45:54 PDT
(In reply to comment #35) > The problem is not Windows-only, it sounds like you guys are simply exporting all symbols for gcc (the default behavior there), so you only see the problem on Windows. > The problem I meant is that we have unmatched symbols breakage at linking. Symbols were and are still correctly exported with this patch, both on Linux and Windows. > The macros are built to assume that you are building JSCore as a dll and statically linking WTF into it. This is how all the other ports that I'm aware of work. Since you instead statically link all of JSCore and WTF into QTWebKit5.dll, you will need to find a solution that only affects the QT build, or, switch the QT build to match what the other ports are doing, which is usually the best approach as it keeps problems like this from cropping up. > I'm trying to prevent the headers from assuming anything that the build system knows best, to make it cleaner and flexible enough for Qt's case. I still don't understand why you don't like it, for wx the only thing it changes is removing "#if ...defined(BUILDING_JavaScriptCore)..." from WTF and ask the build system to define STATICALLY_LINKED_WITH_WTF instead and keep the exact same semantic. If you see any issue with it please let me know. > However, I'm still rather apprehensive that this is really the issue here because QT turned on the use of export macros 5 months ago in r106650. The builds should have immediately failed at that time if QT was building everything statically into QTWebKit5.dll and was not addressing the BUILDING_XYZ defines issue. So why are builds only failing now? Has something recently changed about how QT builds the WebKit dll? Perhaps a change was made recently by someone who was unaware of the export macros issue and only tested the change under Unix platforms? > We didn't have anybody working on Windows since the last release, there were other issues in the way following re-architecturing that we had to fix before encountering this one. I see your concern and I can upload a patch with #if PLATFORM(QT) scattered around to see how it looks if you think that would be better, but I'd like us to agree on technical terms before I do, since I think it would make those headers even more complex.
Kevin Ollivier
Comment 37 2012-06-20 09:02:34 PDT
(In reply to comment #36) > (In reply to comment #35) > I'm trying to prevent the headers from assuming anything that the build system knows best, to make it cleaner and flexible enough for Qt's case. I still don't understand why you don't like it, for wx the only thing it changes is removing "#if ...defined(BUILDING_JavaScriptCore)..." from WTF and ask the build system to define STATICALLY_LINKED_WITH_WTF instead and keep the exact same semantic. If you see any issue with it please let me know. Yes, I see an issue with it. When I read STATICALLY_LINKED_WITH_WTF, I think the project being built is being statically linked with WTF, but that is not accurate. When you're building WebCore, it is incorrect to say it is statically linked with WTF, because you're building WebCore as an independent static library and you're not linking it with any other libraries. QtWebKit is what is statically links in WTF, not WebCore or in your case even JavaScriptCore. The thing about the QT-specific define is that it lets non-QT developers know that QT needs to export, not import, symbols when building WebCore and QtWebKit. This is valuable information, and it's something I did not know nor would ever guess. > > However, I'm still rather apprehensive that this is really the issue here because QT turned on the use of export macros 5 months ago in r106650. The builds should have immediately failed at that time if QT was building everything statically into QTWebKit5.dll and was not addressing the BUILDING_XYZ defines issue. So why are builds only failing now? Has something recently changed about how QT builds the WebKit dll? Perhaps a change was made recently by someone who was unaware of the export macros issue and only tested the change under Unix platforms? > > > We didn't have anybody working on Windows since the last release, there were other issues in the way following re-architecturing that we had to fix before encountering this one. You guys should really consider setting gcc symbol visibility to private by default then so you will catch these issues sooner. It is really strange for a port to turn on the export macros and only test on platforms where the macros aren't even being used. > I see your concern and I can upload a patch with #if PLATFORM(QT) scattered around to see how it looks if you think that would be better, but I'd like us to agree on technical terms before I do, since I think it would make those headers even more complex. I'm not sure what you mean by technical terms, but I think clarity in code is paramount. Especially when one port diverts from the approach other ports take, having that indicated as clearly as possible will lead to the least amount of maintenance issues in the future.
Balazs Kelemen
Comment 38 2012-06-20 15:20:32 PDT
> You guys should really consider setting gcc symbol visibility to private by default then so you will catch these issues sooner. It is really strange for a port to turn on the export macros and only test on platforms where the macros aren't even being used. It is private by default. The reason why this issue did not show up earlier is that export and import is the same on Unix (default visibility), it only differs on Windows.
Kevin Ollivier
Comment 39 2012-06-21 19:58:37 PDT
(In reply to comment #38) > > You guys should really consider setting gcc symbol visibility to private by default then so you will catch these issues sooner. It is really strange for a port to turn on the export macros and only test on platforms where the macros aren't even being used. > > It is private by default. The reason why this issue did not show up earlier is that export and import is the same on Unix (default visibility), it only differs on Windows. Oops, sorry, I had forgotten they don't differ under gcc.
Jocelyn Turcotte
Comment 40 2012-06-25 03:34:36 PDT
(In reply to comment #37) > Yes, I see an issue with it. When I read STATICALLY_LINKED_WITH_WTF, I think the project being built is being statically linked with WTF, but that is not accurate. When you're building WebCore, it is incorrect to say it is statically linked with WTF, because you're building WebCore as an independent static library and you're not linking it with any other libraries. QtWebKit is what is statically links in WTF, not WebCore or in your case even JavaScriptCore. > At first we had it named STATIC_LINKING_WTF and we renamed it to STATICALLY_LINKED_WITH_WTF exactly for that reason. When QtWebKit is linking, both WTF and WebCore are statically linked in it, so WebCore is statically linked with WTF inside QtWebKit. In other words, if an .obj file is compiled with -DSTATICALLY_LINKED_WITH_WTF it means that this .obj will end up in the same .dll as WTF and that it should refer to its exported symbols the same way. The macro name might still not be completely clear but I couldn't find much better naming, FORCE_EXPORT_WTF? ASSUME_BUILDING_WTF? Those sound more lame and don't give any hint on the purpose. If you have any idea let me know. > I'm not sure what you mean by technical terms, but I think clarity in code is paramount. Especially when one port diverts from the approach other ports take, having that indicated as clearly as possible will lead to the least amount of maintenance issues in the future. My take on this one is a bit more modular and is to let the code expose mechanisms and make sure that the code is as clear as possible regarding the contract on those mechanisms. Then the build system needs to use those mechanisms and be as clear as possible on how and why it uses them.
Simon Hausmann
Comment 41 2012-06-25 04:41:38 PDT
After having had another look at the patch in a more quiet moment I now also agree with Jocelyn and think this is a good way forward.
Kevin Ollivier
Comment 42 2012-06-25 15:51:32 PDT
(In reply to comment #40) > (In reply to comment #37) > > Yes, I see an issue with it. When I read STATICALLY_LINKED_WITH_WTF, I think the project being built is being statically linked with WTF, but that is not accurate. When you're building WebCore, it is incorrect to say it is statically linked with WTF, because you're building WebCore as an independent static library and you're not linking it with any other libraries. QtWebKit is what is statically links in WTF, not WebCore or in your case even JavaScriptCore. > > > At first we had it named STATIC_LINKING_WTF and we renamed it to STATICALLY_LINKED_WITH_WTF exactly for that reason. When QtWebKit is linking, both WTF and WebCore are statically linked in it, so WebCore is statically linked with WTF inside QtWebKit. In other words, if an .obj file is compiled with -DSTATICALLY_LINKED_WITH_WTF it means that this .obj will end up in the same .dll as WTF and that it should refer to its exported symbols the same way. > The macro name might still not be completely clear but I couldn't find much better naming, FORCE_EXPORT_WTF? ASSUME_BUILDING_WTF? Those sound more lame and don't give any hint on the purpose. If you have any idea let me know. My point is that I don't think any name will be clear, because what causes that define to be set is build system dependent. The fact that we continue to use BUILDING_XYZ for other ports is also a point of confusion, as why are different ports using different defines to express the same condition? For both those reasons, I think this approach makes things more confusing and hard to understand rather than clears things up. > > I'm not sure what you mean by technical terms, but I think clarity in code is paramount. Especially when one port diverts from the approach other ports take, having that indicated as clearly as possible will lead to the least amount of maintenance issues in the future. > > My take on this one is a bit more modular and is to let the code expose mechanisms and make sure that the code is as clear as possible regarding the contract on those mechanisms. Then the build system needs to use those mechanisms and be as clear as possible on how and why it uses them. So what is even a bit unclear about adding `|| (PLATFORM(QT) && (defined(BUILDING_WEBCORE) || defined(BUILDING_WEBKIT))` to those checks? You could even make this a lot shorter by just defining BUILDING_QTWEBKIT for all projects that are a part of QTWebKit and doing `|| defined(BUILDING_QTWEBKIT)`, which I think might be the best solution.
Jocelyn Turcotte
Comment 43 2012-06-26 02:49:27 PDT
(In reply to comment #42) > My point is that I don't think any name will be clear, because what causes that define to be set is build system dependent. The fact that we continue to use BUILDING_XYZ for other ports is also a point of confusion, as why are different ports using different defines to express the same condition? For both those reasons, I think this approach makes things more confusing and hard to understand rather than clears things up. > After all it's the responsibility of the build system to decide how will the code be packaged. And we also continue using the BUILDING_ macros. I didn't want to replace all of them with something like EXPORT_SYMBOLS_WTF as the BUILDING_ macros are used for other purposes, but it could be worth doing the extra effort. > So what is even a bit unclear about adding `|| (PLATFORM(QT) && (defined(BUILDING_WEBCORE) || defined(BUILDING_WEBKIT))` to those checks? You could even make this a lot shorter by just defining BUILDING_QTWEBKIT for all projects that are a part of QTWebKit and doing `|| defined(BUILDING_QTWEBKIT)`, which I think might be the best solution. It's clear but it's a violation of layers and requires changing those macros everywhere as well as in the build system if the code packaging needs to be changed. We also need to statically link JavaScriptCore inside the jsc.exe binary and adding a BUILDING_JSC define, even though clear, is wrong. WTF shouldn't need to know about some test tool. BUILDING_QTWEBKIT would also be a problem for jsc.exe as it would need to define BUILDING_QTWEBKIT, which is false. You're right, this makes it a bit more difficult to understand the whole picture, but the goal here is to clearly separate layers and remove the assumptions that have a flexibility cost. It also allows somebody reading the code not having to worry about how the build system works.
Tor Arne Vestbø
Comment 44 2012-06-26 05:23:59 PDT
(In reply to comment #42) > So what is even a bit unclear about adding `|| (PLATFORM(QT) && (defined(BUILDING_WEBCORE) || defined(BUILDING_WEBKIT))` to those checks? You could even make this a lot shorter by just defining BUILDING_QTWEBKIT for all projects that are a part of QTWebKit and doing `|| defined(BUILDING_QTWEBKIT)`, which I think might be the best solution. That's the worst solution of them all, as it makes it completely opaque on the place where the macro is used _why_ things are like that, which in turn makes it harder for people to refactor or tweak the code. The result is ifdef mess like: #if PLATFORM(QT) // the old way #else // the new way #endif because people can't be bothered to figure out why exactly PLATFORM(QT) would warrant some behavior. In this case Jocelyn investigated the hard-coded magic in ExportMacros.h, described by the following comment: // Currently WTF is embedded statically in JSCore, which exports // WTF symbols in the JSCore shared library. // Because of this, we need to make sure that we use WTF_EXPORT // when building JavaScriptCore as well as WTF. and determined that the generalization of this issue is that a header is included when building an object that will be at some point linked statically with the relevant module: #if defined(BUILDING_WTF) || defined(BUILDING_SOMETHING_THAT_WILL_AT_SOME_POINT_BE_LINKED_STATICALLY_WITH_WTF) Which applies to JSC for wx (and others), but also applies to WeCore and WebKit(1/2) for the Qt port. Instead of an ifdefs explosion in ExportMacros.h, the proposed solution leave it up to build system of each port to make sure BUILDING_SOMETHING_THAT_WILL_AT_SOME_POINT_BE_LINKED_STATICALLY_WITH_WTF is defined for the relevant modules, and makes the code in ExportMacros.h clearer as you can tell _why_ the ifdefs are like that.
Kevin Ollivier
Comment 45 2012-06-26 08:46:14 PDT
(In reply to comment #43) > (In reply to comment #42) > > My point is that I don't think any name will be clear, because what causes that define to be set is build system dependent. The fact that we continue to use BUILDING_XYZ for other ports is also a point of confusion, as why are different ports using different defines to express the same condition? For both those reasons, I think this approach makes things more confusing and hard to understand rather than clears things up. > > > After all it's the responsibility of the build system to decide how will the code be packaged. And we also continue using the BUILDING_ macros. I didn't want to replace all of them with something like EXPORT_SYMBOLS_WTF as the BUILDING_ macros are used for other purposes, but it could be worth doing the extra effort. No, they aren't used for other purposes, both macros are used to define when to annotate the symbol with export or import macros... > > So what is even a bit unclear about adding `|| (PLATFORM(QT) && (defined(BUILDING_WEBCORE) || defined(BUILDING_WEBKIT))` to those checks? You could even make this a lot shorter by just defining BUILDING_QTWEBKIT for all projects that are a part of QTWebKit and doing `|| defined(BUILDING_QTWEBKIT)`, which I think might be the best solution. > > It's clear but it's a violation of layers and requires changing those macros everywhere as well as in the build system if the code packaging needs to be changed. Platform-specific macros are used all throughout the code, including WTF and JSCore. There is no "layer" of code where they're not to be used. > We also need to statically link JavaScriptCore inside the jsc.exe binary and adding a BUILDING_JSC define, even though clear, is wrong. WTF shouldn't need to know about some test tool. Well, if that bothers you, you could just build a JSCore shared library like everyone else and not have to deal with any of this. :) > BUILDING_QTWEBKIT would also be a problem for jsc.exe as it would need to define BUILDING_QTWEBKIT, which is false. > > You're right, this makes it a bit more difficult to understand the whole picture, but the goal here is to clearly separate layers and remove the assumptions that have a flexibility cost. It also allows somebody reading the code not having to worry about how the build system works. I totally disagree. If I don't know why a macro is set, and I need to make a change in that area of code, I have no idea what I need to do with that macro without reading up on all the build systems that use it. Used to be, the build system itself was 100% responsible for specifying the export symbols, and as we tried to change that, it seemed every change would break one port or another. We'd post a patch 10 times on the EWS as we took stabs trying to fix each build system, with tons of patch spam accumulating in the ticket. (Which, BTW, made people hesitant to do reviews...) I don't really want to go back to those days of just writing up a patch, seeing what ports break, then trying to figure out why by scrounging through several build systems whose syntax I don't even know. Anyway, at this point we're simply re-iterating arguments we've already made. If you can get someone else to approve this, then go ahead as you need to fix the build somehow and this is apparently the one and only way you'll accept, but please do not have the wx port using these macros. It doesn't need them. There are PLATFORM(XYZ) blocks in many places throughout the code, a mechanism designed precisely for whenever a port diverts from the standard approach, and as QT is diverting from the standard approach of building JScore as its own shared library (but still wants to use the export macros defined for that case), I think that is the appropriate fix to be used here.
Jocelyn Turcotte
Comment 46 2012-06-27 09:53:02 PDT
Created attachment 149768 [details] Patch
Jocelyn Turcotte
Comment 47 2012-06-27 09:57:00 PDT
Keep the old way for the Wx port and added the define for the Safari Windows port. I need to test the testapiCommon.vsprops change before pushing but here is the patch for review anyway.
Jocelyn Turcotte
Comment 48 2012-06-29 08:15:24 PDT
Created attachment 150181 [details] Patch Tested the Win port and it builds as expected. Remove the testapi project change, it isn't needed.
WebKit Review Bot
Comment 49 2012-07-03 06:43:30 PDT
Comment on attachment 150181 [details] Patch Clearing flags on attachment: 150181 Committed r121762: <http://trac.webkit.org/changeset/121762>
WebKit Review Bot
Comment 50 2012-07-03 06:43:37 PDT
All reviewed patches have been landed. Closing bug.
Csaba Osztrogonác
Comment 51 2012-07-03 09:42:56 PDT
Reopen, because it broke the Qt 4.8 cross debug linking of DRT.exe: i486-mingw32-g++ -mthreads -Wl,-subsystem,console -o ../../../bin/DumpRenderTree.exe object_script.DumpRenderTree.Debug -L'/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/WebKitBuild/Debug/lib' -L'/usr/local/Trolltech/Qt-4.8.0-rc1-mingw/lib' -lQtWebKitd4 -lQtTestd4 -lQtSqld4 -lQtXmlPatternsd4 -lQtGuid4 -lQtNetworkd4 -lQtCored4 ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:58: undefined reference to `_WTFReportAssertionFailure' ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:58: undefined reference to `_WTFReportBacktrace' ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:58: undefined reference to `_WTFInvokeCrashHook' ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:59: undefined reference to `_WTFReportAssertionFailure' ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:59: undefined reference to `_WTFReportBacktrace' ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:59: undefined reference to `_WTFInvokeCrashHook' ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:71: undefined reference to `_WTFReportAssertionFailure' ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:71: undefined reference to `_WTFReportBacktrace' ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:71: undefined reference to `_WTFInvokeCrashHook' ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:101: undefined reference to `_WTFReportAssertionFailure' ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:101: undefined reference to `_WTFReportBacktrace' ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:101: undefined reference to `_WTFInvokeCrashHook' collect2: ld returned 1 exit status Could you check it, please?
Csaba Osztrogonác
Comment 52 2012-07-04 03:17:41 PDT
(In reply to comment #51) > Reopen, because it broke the Qt 4.8 cross debug linking of DRT.exe: > > i486-mingw32-g++ -mthreads -Wl,-subsystem,console -o ../../../bin/DumpRenderTree.exe object_script.DumpRenderTree.Debug -L'/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/WebKitBuild/Debug/lib' -L'/usr/local/Trolltech/Qt-4.8.0-rc1-mingw/lib' -lQtWebKitd4 -lQtTestd4 -lQtSqld4 -lQtXmlPatternsd4 -lQtGuid4 -lQtNetworkd4 -lQtCored4 > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:58: undefined reference to `_WTFReportAssertionFailure' > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:58: undefined reference to `_WTFReportBacktrace' > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:58: undefined reference to `_WTFInvokeCrashHook' > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:59: undefined reference to `_WTFReportAssertionFailure' > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:59: undefined reference to `_WTFReportBacktrace' > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:59: undefined reference to `_WTFInvokeCrashHook' > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:71: undefined reference to `_WTFReportAssertionFailure' > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:71: undefined reference to `_WTFReportBacktrace' > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:71: undefined reference to `_WTFInvokeCrashHook' > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:101: undefined reference to `_WTFReportAssertionFailure' > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:101: undefined reference to `_WTFReportBacktrace' > ./obj/debug/WorkQueue.o:/home/webkitbuildbot/slaves/windowsCrossDebug/buildslave/qt-windows-32bit-debug/build/Tools/DumpRenderTree/WorkQueue.cpp:101: undefined reference to `_WTFInvokeCrashHook' > collect2: ld returned 1 exit status > > > Could you check it, please? Balázs, what do you think, is this new failure related to https://bugs.webkit.org/show_bug.cgi?id=90346 somehow? Here DRT would like to use assertion functions from WTF.
Jocelyn Turcotte
Comment 53 2012-07-04 03:41:48 PDT
(In reply to comment #51) > collect2: ld returned 1 exit status > > > Could you check it, please? It fails with this patch since I removed Assertions.cpp from the DRT build to fix duplicate symbols with MSVC. I assumed that they should be exported anyway but what happens is that there should be special handling of the import macro for MinGW. If I can get a working MinGW environment I'll try to find a proper fix, but it's pretty broken right now and can't get it to build on Windows.
Csaba Osztrogonác
Comment 54 2012-07-04 04:45:24 PDT
Crazy idea ... but what if we add Assertions.cpp back for mingw builds only until proper fix? :)
Jocelyn Turcotte
Comment 55 2012-07-05 08:32:25 PDT
The MinGW problem with DRT is tracked in bug #90612. Closing this one.
Note You need to log in before you can comment on or make changes to this bug.