Bug 58737 - [GTK] Undefined Symbol build error "_objc_registerThreadWithCollector" when building WebKit GTK Mac OS X on Snow Leopard
Summary: [GTK] Undefined Symbol build error "_objc_registerThreadWithCollector" when b...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh Intel OS X 10.6
: P2 Major
Assignee: Nobody
URL: N/A
Keywords:
Depends on:
Blocks: 126492
  Show dependency treegraph
 
Reported: 2011-04-16 18:08 PDT by devchan1
Modified: 2014-12-09 14:06 PST (History)
7 users (show)

See Also:


Attachments
Patch to avoid including os x specific threading code when bullding WebKit GTK (812 bytes, patch)
2011-04-16 18:08 PDT, devchan1
no flags Details | Formatted Diff | Diff
Patch to avoid including os x specific threading code when bullding WebKit GTK (812 bytes, patch)
2011-04-16 18:10 PDT, devchan1
no flags Details | Formatted Diff | Diff
Patch (1.47 KB, patch)
2013-09-11 14:05 PDT, Alberto Garcia
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description devchan1 2011-04-16 18:08:15 PDT
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
Comment 1 devchan1 2011-04-16 18:10:15 PDT
Created attachment 89936 [details]
Patch to avoid including os x specific threading code when bullding WebKit GTK
Comment 2 Jeremy Huddleston Sequoia 2012-11-04 11:55:27 PST
That's not the right fix.

I think you actually want to change OS(MAC_OS_X) to PLATFORM(MAC).
Comment 3 Jeremy Huddleston Sequoia 2012-11-04 12:02:36 PST
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
Comment 4 Alberto Garcia 2013-09-11 10:55:32 PDT
Is this still relevant?
Comment 5 Jeremy Huddleston Sequoia 2013-09-11 11:11:20 PDT
Yes.  Please make the provided change.
Comment 6 Alberto Garcia 2013-09-11 14:05:14 PDT
Created attachment 211348 [details]
Patch
Comment 7 Darin Adler 2013-09-11 15:14:21 PDT
Comment on attachment 211348 [details]
Patch

Are you sure this is what Qt wants on Mac too?
Comment 8 Darin Adler 2013-09-11 15:15:35 PDT
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.
Comment 9 Alberto Garcia 2013-12-04 08:02:25 PST
(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?
Comment 10 Alberto Garcia 2014-01-15 13:54:43 PST
Jeremy, can you confirm if this is still working fine?
Comment 11 Jeremy Huddleston Sequoia 2014-01-15 14:53:38 PST
(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
Comment 12 Alberto Garcia 2014-01-15 23:22:29 PST
(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.
Comment 13 Gustavo Noronha (kov) 2014-12-06 10:12:43 PST
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.
Comment 14 Darin Adler 2014-12-09 07:41:34 PST
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.
Comment 15 Alberto Garcia 2014-12-09 10:11:09 PST
(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.
Comment 16 Alberto Garcia 2014-12-09 10:20:46 PST
Committed r177023: <http://trac.webkit.org/changeset/177023>
Comment 17 Darin Adler 2014-12-09 14:06:16 PST
(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.