On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter
<[email protected]> wrote:
> On Tue, Oct 6, 2009 at 11:09 PM, Jacob Mandelson <[email protected]> wrote:
>> On Tue, Oct 06, 2009 at 09:19:49PM +0200, Craig Schlenter wrote:
>>> On Tue, Oct 6, 2009 at 8:14 PM, Craig Schlenter
>>> <[email protected]> wrote:
>>> > On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson <[email protected]> 
>>> > wrote:
>>> >> On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
>>> >>> On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin <[email protected]> wrote:
>>> >>> >
>>> >>> > On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson <[email protected]> 
>>> >>> > wrote:
>>> >>> >> I tried this, and it does indeed link far, far faster!
>>> >>> >> However, I got errors about RegisterInternalNaClPlugin():
>>> >>> >> /mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
>>> >>> >>  undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, 
>>> >>> >> int*))'
>>> >>> >> (Also one for libbrowser.so)
>>> >>> >
>>> >>> > In general, the shared link breaks frequently.  Whenever I work from a
>>> >>> > cafe or wherever from my laptop, I usually will do a TBR commit or two
>>> >>> > to fix the shared link.
>>> >>>
>>> >>> The shared build is working perfectly for me FWIW but that is on 32 bit.
>>> >>>
>>> >>> Are you on 64 bit or do you have any special gyp variables etc. set?
>>> >>
>>> >> I'm on 32-bit.  Only gyp changes from stock I have are:
>>> >> {'variables': {
>>> >>    'library': 'shared_library',
>>> >>    'remove_webcore_debug_symbols': 1,
>>> >> }}
>>> >
>>> > Ah, you're doing a debug build then? I have only tested release recently.
>>> >
>>> > I'll poke at a debug build tomorrow and try to sort it out ...
>>>
>>> Hmmmmm ... debug build is also fine for me and I'm building with the
>>> same gyp variables as you (except that I also have gcc_version=44).
>>>
>>> If you stick your build into verbose mode can you see if it is linking
>>> librenderer.so with libnpGoogleNaClPluginChrome.a? Maybe clobbering,
>>> regyping etc. will encourage it to do that.
>>>
>>> PS. I'm on r28124
>>
>> I switched to --mode=Release, got strict-aliasing warnings^Werrors, stuck
>> on -Wno-strict-aliasing, and it landed back in
>> /mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib/librenderer.so:
>>  undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
>> Running gclient runhooks had no effect here.
>>
>> Building with --verbose shows the very long link line attached, which
>> has [nN][aA][cC][lL] only in -lnacl.
>
> This problem only seems to happen with the scons shared build. The
> make build does not have this problem so there seems to be something
> different about how the dependencies are being generated with the make
> versus scons gyp backends.

So the executive summary of the current situation is this:

1. Both libbrowser.so and librenderer.so call RegisterInternalNaClPlugin
2. RegisterInternalNaClPlugin lives in libnpGoogleNaClPluginChrome.a
3. libnpGoogleNaClPluginChrome.a is listed as a dependency of
libnacl.so (but it doesn't actually seem to be)
4. librenderer depends on nacl but nacl doesn't export its own
"dependency" on libnpGoogleNaClPluginChrome either
5. libbrowser doesn't depend on nacl which doesn't really help either.

In order to fix this, we really want to say that anything that
actually uses 'RegisterInternalNaClPlugin' should be linked against
libnpGoogleNaClPluginChrome.a. It is preferable to link the final
executable target with that rather than other "intermediate"
libraries like libbrowser and librenderer  to avoid situations like
issue 5933.

One option (which works at least for the linux scons shared build
chrome target) is to remove
'../native_client/src/trusted/plugin/plugin_chrome.gyp:npGoogleNaClPluginChrome'
from the nacl dependencies and add it to the chrome dependencies in
chrome.gyp. It might also have to be specified manually for other
users of libbrowser and librenderer but that seems messy. I have only
tested this with the shared linux scons build btw.

Perhaps a gyp expert could suggest a better way?

Thanks!

PS. I haven't looked into why the make build gets this stuff "right".
I'd guess it is over-specifying dependencies versus what is actually
declared in the gyp files?

--Craig

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected] 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to