Bug 111271 – WebKit fails to build with MinGW compiler after changeset 144024

• Component: New Bugs
• Status: RESOLVED DUPLICATE

WebKit fails to build with MinGW compiler after changeset 144024

Build fails with the following error

                 from Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:31:
/usr/i686-w64-mingw32/sys-root/mingw/include/winsock2.h:15:2: warning: #warning Please include winsock2.h before windows.h [-Wcpp]
Source/WebCore/page/scrolling/ScrollingCoordinator.cpp: In static member function 'static WebCore::GraphicsLayer* WebCore::ScrollingCoordinator::scrollLayerForScrollableArea(WebCore::ScrollableArea*)':
Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:277:28: error: 'class WebCore::ScrollableArea' has no member named 'layerForScrolling'
Source/WebCore/page/scrolling/ScrollingCoordinator.cpp: In static member function 'static WebCore::GraphicsLayer* WebCore::ScrollingCoordinator::horizontalScrollbarLayerForScrollableArea(WebCore::ScrollableArea*)':
Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:282:28: error: 'class WebCore::ScrollableArea' has no member named 'layerForHorizontalScrollbar'
Source/WebCore/page/scrolling/ScrollingCoordinator.cpp: In static member function 'static WebCore::GraphicsLayer* WebCore::ScrollingCoordinator::verticalScrollbarLayerForScrollableArea(WebCore::ScrollableArea*)':
Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:287:28: error: 'class WebCore::ScrollableArea' has no member named 'layerForVerticalScrollbar'
Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:288:1: warning: control reaches end of non-void function [-Wreturn-type]
Source/WebCore/page/scrolling/ScrollingCoordinator.cpp: In static member function 'static WebCore::GraphicsLayer* WebCore::ScrollingCoordinator::horizontalScrollbarLayerForScrollableArea(WebCore::ScrollableArea*)':
Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:283:1: warning: control reaches end of non-void function [-Wreturn-type]
Source/WebCore/page/scrolling/ScrollingCoordinator.cpp: In static member function 'static WebCore::GraphicsLayer* WebCore::ScrollingCoordinator::scrollLayerForScrollableArea(WebCore::ScrollableArea*)':
Source/WebCore/page/scrolling/ScrollingCoordinator.cpp:278:1: warning: control reaches end of non-void function [-Wreturn-type]
make[1]: *** [Source/WebCore/page/scrolling/libWebCore_la-ScrollingCoordinator.lo] Błąd 1
make[1]: Opuszczenie katalogu `/home/pawel/src/webkit'
make: *** [all] Błąd 2

Created attachment 191136 [details]
Patch

[James Robinson]

Comment on attachment 191136 [details]
Patch

Seems like this is fixing the problem in the wrong place.  Can you just give ScrollableArea empty (inline return null) definitions in the !USE(ACCELERATED_COMPOSITING) case?  Then the callers wouldn't have to look so ugly.

[Gustavo Noronha (kov)]

Chromium seems to be the only user of these methods, I think not defining them at all if AC is off makes sense (as opposed to defining an empty version for the non-AC case).

Created attachment 191545 [details]
Patch

[Darin Adler]

Comment on attachment 191545 [details]
Patch

Not sure this has anything to do with the MinGW compiler.

[Darin Adler]

Comment on attachment 191545 [details]
Patch

I didn’t see James Robinson’s earlier comment; James, feel free to change to review- if you disagree with me.

It seems to me that GraphicsLayer should only exist when USE(ACCELERATED_COMPOSITING) is true. I’m surprised that is not the case!

[James Robinson]

(In reply to comment #7)
> (From update of attachment 191545 [details])
> I didn’t see James Robinson’s earlier comment; James, feel free to change to review- if you disagree with me.
> 
> It seems to me that GraphicsLayer should only exist when USE(ACCELERATED_COMPOSITING) is true. I’m surprised that is not the case!

There's another patch that fixes this - lemme find it.

[James Robinson]

I believe the patch in https://bugs.webkit.org/show_bug.cgi?id=111306 takes care of this.

The GraphicsLayer type's definition is guarded by USE(ACCELERATED_COMPOSITING) but there are declarations of the type outside the guard in various places.  I guess it's to keep the #ifdeffage down in interface definitions, but perhaps Simon knows the history more concretely here.

[James Robinson]

I think the more general issue is very few ports compile without USE(ACCELERATED_COMPOSITING) these days (for instance, none of the EWS bots do) so it's harder to keep this configuration compiling.

[James Robinson]

Nothing necessarily wrong with this patch, but it'll be handled by patch in bug 111306 just as well.

*** This bug has been marked as a duplicate of bug 111306 ***