It seems like it's coming from about_window_controller - I'm surprised
that's being pulled in by worker_uitest.cc, though.
I see some comments in the .gyp file around manually including
keystone_glue, which is why I was wondering if I have to do something
special for targets that need it. Just adding keystone_glue.h/m to the Mac
sources for that target didn't do the trick.
-atw
On Sun, Sep 20, 2009 at 8:19 PM, Thomas Van Lenten <thoma...@chromium.org>wrote:
> The unittest should be able to skip keystone, since it's part of the update
> system for official builds. Either we have a shim, or we're pulling in
> something we've been able to avoid in the past.
> TVL
>
>
> On Sun, Sep 20, 2009 at 12:47 PM, Drew Wilson <atwil...@chromium.org>wrote:
>
>> Hi all,
>> I'm trying to fix up some of the worker layout tests. worker_uitests is
>> currently disabled on the mac, and when I enable it in chrome.gyp (it's
>> currently added to the !sources line for the mac version of ui_tests due to
>> broken tests), I get the following link error:
>>
>> Undefined symbols:
>> ".objc_class_name_KeystoneGlue", referenced from:
>> literal-poin...@__objc@__cls_r...@keystoneglue in
>> libbrowser.a(about_window_controller.o)
>>
>> This used to work just fine before I synced with the recent chrome.gyp
>> refactoring - anyone have any insights about this before I launch a painful
>> hunt for missing dependencies?
>>
>> -atw
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
