Bug 79102
| Summary: | [Qt] Incremental build problem revealed by r108345 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Csaba Osztrogonác <ossy> |
| Component: | Tools / Tests | Assignee: | 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
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 | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Csaba Osztrogonác
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
I think it is qmake bug near GNUMake option.
Tor Arne Vestbø
(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
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ø
(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ø
(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
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
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
(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ø
(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.