Bug 80524 – [Qt] [WK2] Webkit fails to link when compiled with force_static_libs_as_shared

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Viatcheslav Ostapenko]

/home/sl/work/webkit2/WebKitBuild/Debug/lib/libWTF.so: undefined reference to `JSC::IdentifierTable::~IdentifierTable()'
collect2: ld returned 1 exit status
make[4]: *** [MIMESniffing] Error 1
make[4]: Leaving directory `/home/sl/work/webkit2/WebKitBuild/Debug/Source/WebKit/qt/tests/MIMESniffing'
make[3]: *** [sub--home-sl-work-webkit2-Source-WebKit-qt-tests-MIMESniffing-make_default-ordered] Error 2
make[3]: Leaving directory `/home/sl/work/webkit2/WebKitBuild/Debug/Source'
make[2]: *** [sub-tests-pri-make_default-ordered] Error 2
make[2]: Leaving directory `/home/sl/work/webkit2/WebKitBuild/Debug/Source'
make[1]: *** [sub-Source-QtWebKit-pro-make_default-ordered] Error 2
make[1]: Leaving directory `/home/sl/work/webkit2/WebKitBuild/Debug'
make: *** [incremental] Error 2

[Viatcheslav Ostapenko]

Created attachment 130665 [details]
Patch

[Simon Hausmann]

I see this problem only when the toolchain includes -Wl,z,defs, which isn't a default.

I'll check with Tor Arne tomorrow, but I'd prefer to remove the offending flags from CFLAGS instead of doing the move. This kind of build configuration isn't supported by the project yet I think.

[WebKit Review Bot]

Comment on attachment 130665 [details]
Patch

Attachment 130665 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/11851264

[Simon Hausmann]

Comment on attachment 130665 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=130665&action=review

One second thought, this seems to make sense. The class is declared in WTFThreadData.h, why not define it in the .cpp. But there's the Chromium build issue :)

> Source/JavaScriptCore/wtf/WTFThreadData.cpp:70
> +namespace JSC {
> +
> +IdentifierTable::~IdentifierTable()
> +{
> +    HashSet<StringImpl*>::iterator end = m_table.end();
> +    for (HashSet<StringImpl*>::iterator iter = m_table.begin(); iter != end; ++iter)
> +        (*iter)->setIsIdentifier(false);
> +}
> +
> +std::pair<HashSet<StringImpl*>::iterator, bool> IdentifierTable::add(StringImpl* value)
> +{
> +    std::pair<HashSet<StringImpl*>::iterator, bool> result = m_table.add(value);
> +    (*result.first)->setIsIdentifier(true);
> +    return result;
>  }

This should be surrounded by #if USE(JSC) to fix the Chromium build.

[Viatcheslav Ostapenko]

Created attachment 130707 [details]
Updated patch.

[WebKit Review Bot]

Comment on attachment 130707 [details]
Updated patch.

Clearing flags on attachment: 130707

Committed r110158: <http://trac.webkit.org/changeset/110158>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Eric Seidel (no email)]

Huh?  This seems like a layering violation.  WTF shouldn't need to know about JSC...

[Simon Hausmann]

(In reply to comment #8)
> Huh?  This seems like a layering violation.  WTF shouldn't need to know about JSC...

It was a bit the other way around, I think. WTF used stuff from JSC, i.e. WTFThreadData.h declared IdentifierTable but it was _implemented_ in JSC.

But yeah, with or without this patch the identifier stuff is the reason for the remaining #if USE(JSC) in WTF I think.