Bug 58737 – [GTK] Undefined Symbol build error "_objc_registerThreadWithCollector" when building WebKit GTK Mac OS X on Snow Leopard

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

Created attachment 89935 [details]
Patch to avoid including os x specific threading code when bullding WebKit GTK

The following build error occurs when building WebKit GTK rev 84097 on Mac OS X Snow Leopard:

Undefined symbols:
  "_objc_registerThreadWithCollector", referenced from:
      WTF::initializeCurrentThreadInternal(char const*)in libJavaScriptCore.a(libJavaScriptCore_la-ThreadingPthreads.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [Programs/jsc] Error 1
make: *** [all] Error 2

Created attachment 89936 [details]
Patch to avoid including os x specific threading code when bullding WebKit GTK

[Jeremy Huddleston Sequoia]

That's not the right fix.

I think you actually want to change OS(MAC_OS_X) to PLATFORM(MAC).

[Jeremy Huddleston Sequoia]

Yeah, that patch is no longer valid, but it is fixed with:

sed -i "s:OS(MAC_OS_X):PLATFORM(MAC):" Source/WTF/wtf/ThreadingPthreads.cpp

[Alberto Garcia]

Is this still relevant?

[Jeremy Huddleston Sequoia]

Yes.  Please make the provided change.

[Alberto Garcia]

Created attachment 211348 [details]
Patch

[Darin Adler]

Comment on attachment 211348 [details]
Patch

Are you sure this is what Qt wants on Mac too?

[Darin Adler]

Comment on attachment 211348 [details]
Patch

If Qt doesn’t also want this code, then I think the original that specifically called out PLATFORM(GTK) might in fact be what we want.

[Alberto Garcia]

(In reply to comment #8)
> (From update of attachment 211348 [details])
> If Qt doesn’t also want this code, then I think the original that
> specifically called out PLATFORM(GTK) might in fact be what we want.

I guess this doesn't matter anymore and we can apply the patch as it
is?

[Alberto Garcia]

Jeremy, can you confirm if this is still working fine?

[Jeremy Huddleston Sequoia]

(In reply to comment #10)
> Jeremy, can you confirm if this is still working fine?

The issue still exists (at least in webkit-gtk 2.3.3).  We're still doing the following OS/Platform fixes:

    # https://bugs.webkit.org/show_bug.cgi?id=99683
    reinplace "s:PLATFORM(MAC):OS(DARWIN):g" \
        ${worksrcpath}/Source/JavaScriptCore/heap/VTableSpectrum.cpp \
        ${worksrcpath}/Source/JavaScriptCore/jit/ThunkGenerators.cpp \
        ${worksrcpath}/Source/JavaScriptCore/tools/CodeProfile.cpp

    # https://bugs.webkit.org/show_bug.cgi?id=58737
    reinplace "s:OS(MAC_OS_X):PLATFORM(MAC):" \
        ${worksrcpath}/Source/WTF/wtf/ThreadingPthreads.cpp

[Alberto Garcia]

(In reply to comment #11)
>     # https://bugs.webkit.org/show_bug.cgi?id=58737
>     reinplace "s:OS(MAC_OS_X):PLATFORM(MAC):" \
>         ${worksrcpath}/Source/WTF/wtf/ThreadingPthreads.cpp

Ok, this one is still fine, now it only needs to be reviewed.

[Gustavo Noronha (kov)]

Comment on attachment 211348 [details]
Patch

Is this change correct for iOS too? I'd r+, but I'd prefer someone who knows the apple ports to do it.

[Darin Adler]

Comment on attachment 211348 [details]
Patch

This does no harm on iOS, but our long term direction is to use PLATFORM directly as little as possible and use more specific #if statements so the platform configuration system works and is not tied to specific platforms. I guess the real issue here is that GTK is choosing not to support garbage collection, so ideally the condition would be #if USE(COCOA_GC) or something along those lines.

[Alberto Garcia]

(In reply to comment #14)
> ideally the condition would be #if USE(COCOA_GC) or something along
> those lines.

It looks like a good policy, but I guess it doesn't make sense to
define COCOA_GC just for this case.

[Alberto Garcia]

Committed r177023: <http://trac.webkit.org/changeset/177023>

[Darin Adler]

(In reply to comment #15)
> It looks like a good policy, but I guess it doesn't make sense to
> define COCOA_GC just for this case.

I believe there are a number of other places in the code that should use COCOA_GC. It's just that the other places don't simply fail to compile. One possible example is the code in the adoptNS function in RetainPtr.h. It uses "#if defined(OBJC_NO_GC)" and instead it should use "#if !USE(COCOA_GC)". This is a missed optimization opportunity.