Bug 79102

Summary: [Qt] Incremental build problem revealed by r108345
Product: WebKit Reporter: Csaba Osztrogonác <ossy>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Critical CC: abecsi, allan.jensen, ossy, vestbo
Priority: P1 Keywords: Qt, QtTriaged
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   

Csaba Osztrogonác
Reported 2012-02-21 06:53:13 PST
It seems HTMLDataListElement.o should depends on Source/WebCore/dom/StyledElement.h, but it doesn't. /usr/bin/gold: /home/oszi/WebKit/WebKitBuild/Release/Source/WebCore/debug/libWebCore.a(HTMLDataListElement.o): in function vtable for WebCore::HTMLDataListElement:HTMLDataListElement.cpp(.data.rel.ro._ZTVN7WebCore19HTMLDataListElementE+0xf4): error: undefined reference to 'WebCore::StyledElement::insertedIntoDocument()' /usr/bin/gold: /home/oszi/WebKit/WebKitBuild/Release/Source/WebCore/debug/libWebCore.a(HTMLDataListElement.o): in function vtable for WebCore::HTMLDataListElement:HTMLDataListElement.cpp(.data.rel.ro._ZTVN7WebCore19HTMLDataListElementE+0xf8): error: undefined reference to 'WebCore::StyledElement::removedFromDocument()' /usr/bin/gold: /home/oszi/WebKit/WebKitBuild/Release/Source/WebCore/debug/libWebCore.a(InsertionPoint.o): in function vtable for WebCore::InsertionPoint:InsertionPoint.cpp(.data.rel.ro._ZTVN7WebCore14InsertionPointE+0xf4): error: undefined reference to 'WebCore::StyledElement::insertedIntoDocument()' /usr/bin/gold: /home/oszi/WebKit/WebKitBuild/Release/Source/WebCore/debug/libWebCore.a(InsertionPoint.o): in function vtable for WebCore::InsertionPoint:InsertionPoint.cpp(.data.rel.ro._ZTVN7WebCore14InsertionPointE+0xf8): error: undefined reference to 'WebCore::StyledElement::removedFromDocument()'
Attachments
Csaba Osztrogonác
Comment 1 2012-02-21 07:09:40 PST
There some serious bug in the new QtWebKit buildsystem: - dom/StyledElement.h is in WebCore/target.pri - /home/oszi/WebKit/Source/WebCore/dom/StyledElement.h is in /WebKitBuild/Release/Source/WebCore/HTMLDataListElement.d - _BUT_ WebKitBuild/Release/Source/WebCore/Makefile.WebCore.Target includes wrong dependecy files: "-include obj/debug/dom/StyledElement.d" Tor Arne, could you check what happened? I think we got _all_ incremental build bugs nowadays because of this. It means that now almost all dependency is missing. :S
Csaba Osztrogonác
Comment 2 2012-02-21 07:56:17 PST
I think it is qmake bug near GNUMake option.
Tor Arne Vestbø
Comment 3 2012-02-21 08:23:00 PST
(In reply to comment #1) > - /home/oszi/WebKit/Source/WebCore/dom/StyledElement.h is in /WebKitBuild/Release/Source/WebCore/HTMLDataListElement.d The location of this file is wrong. > - _BUT_ WebKitBuild/Release/Source/WebCore/Makefile.WebCore.Target > includes wrong dependecy files: "-include obj/debug/dom/StyledElement.d" That's correct. That's including the expected dependency file for StyledElement (not HTMLDataListElement), and in the right location.
Csaba Osztrogonác
Comment 4 2012-02-21 09:10:51 PST
OK. And how can we fix it? Or is it possible to disable GNUMake dependency generation on the bots until proper fix?
Tor Arne Vestbø
Comment 5 2012-02-21 09:15:42 PST
(In reply to comment #4) > OK. And how can we fix it? Or is it possible to disable GNUMake dependency generation on the bots until proper fix? I'm doing a local build to try to reproduce, let's compare my results with yours on IRC. For the bots you can do CONFIG-=GNUmake to force qmake to deal with all dependency tracking. Requires a clean build after changing the config.
Tor Arne Vestbø
Comment 6 2012-02-21 09:42:24 PST
(In reply to comment #4) > OK. And how can we fix it? It appears your .d files are not placed at the same path as the .o files, which should be the effect of passing -MD to gcc. Can you try this and verify that the .o and .d both end up in obj? mkdir -p obj && touch foo.cpp && gcc -c foo.cpp -o obj/foo.o -MD && ls obj
Csaba Osztrogonác
Comment 7 2012-02-21 13:05:59 PST
Very very strange ... I got different results on our similar servers. (Same distibution, same gcc, etc.) Tomorrow I'll check what happened.
Csaba Osztrogonác
Comment 8 2012-02-22 01:47:51 PST
We got it, unfortunately it is an icecc bug. original command: gcc -c -MD x/y.c -o x/y.o local preprocess: gcc -E -MD x/y.c --> It generates y.d into the current directory, because icecc consumed the "-o x/y.o" We need a nice workaround to make incremental build work again with icecream.
Allan Sandfeld Jensen
Comment 9 2012-02-22 12:33:27 PST
(In reply to comment #8) > We got it, unfortunately it is an icecc bug. > > original command: gcc -c -MD x/y.c -o x/y.o > local preprocess: gcc -E -MD x/y.c > --> It generates y.d into the current directory, > because icecc consumed the "-o x/y.o" > > We need a nice workaround to make incremental build work again with icecream. Remember to also file the bug to icecream.
Tor Arne Vestbø
Comment 10 2012-02-24 06:08:58 PST
(In reply to comment #9) > (In reply to comment #8) > > We got it, unfortunately it is an icecc bug. > > > > original command: gcc -c -MD x/y.c -o x/y.o > > local preprocess: gcc -E -MD x/y.c > > --> It generates y.d into the current directory, > > because icecc consumed the "-o x/y.o" > > > > We need a nice workaround to make incremental build work again with icecream. > > Remember to also file the bug to icecream. This issue was fixed in icecream 0.9.7, please upgrade.
Note You need to log in before you can comment on or make changes to this bug.