| Summary: | [Qt][Win] Fix broken QtWebKit5.lib linking | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Csaba Osztrogonác <ossy> | ||||||||||||||||
| Component: | Tools / Tests | Assignee: | 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
Csaba Osztrogonác
2012-06-05 04:29:26 PDT
It would be useful: http://trac.webkit.org/wiki/ExportingSymbols Any volunteer to fix it? 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.
According to http://msdn.microsoft.com/en-US/library/bxwfs976%28v=VS.80%29.aspx /OPT:NOREF instead of /OPT:REF may solve this. (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. I tried s/OPT:REF/OPT:NOREF , but it didn't help for me. ~ArrayBufferView and neuter fails are related to this change - http://trac.webkit.org/changeset/112558 Created attachment 146857 [details]
Use the defines that cause WTF and JavaScriptCore's headers to export, not import, their symbols
(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. (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. :( Created attachment 146860 [details]
Make sure not to dllimport WTF/JavaScriptCore symbols
Sorry, this patch, though I did need the other one too.
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? 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 ... 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? (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... (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. (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? (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 (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 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. (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. (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. (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? *** Bug 88301 has been marked as a duplicate of this bug. *** Created attachment 147324 [details]
Patch
Created attachment 147328 [details]
Patch
Fixing with proper credits.
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? 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)? (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? 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) ? (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. 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.
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.
(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) (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) (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. (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. > 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.
(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. (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. 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. (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. (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. (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. (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. Created attachment 149768 [details]
Patch
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. Created attachment 150181 [details]
Patch
Tested the Win port and it builds as expected.
Remove the testapi project change, it isn't needed.
Comment on attachment 150181 [details] Patch Clearing flags on attachment: 150181 Committed r121762: <http://trac.webkit.org/changeset/121762> All reviewed patches have been landed. Closing bug. 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? (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. (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. Crazy idea ... but what if we add Assertions.cpp back for mingw builds only until proper fix? :) The MinGW problem with DRT is tracked in bug #90612. Closing this one. |