Bug 79102 – [Qt] Incremental build problem revealed by r108345

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[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()'

[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.