New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 611911 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
please use my google.com address
Closed: May 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Blocking:
issue 431177
issue 599950



Sign in to add a comment

//chrome is including //services/shell/public/cpp:init_commandline

Project Member Reported by rsesek@chromium.org, May 13 2016

Issue description

On Mac, there's a build step to verify the symbol table order of the chrome_framework target. When enabling that build step, I noticed the following is failing:

python ../../build/gn_run_binary.py ../../chrome/tools/build/mac/verify_order _ChromeMain Google\ Chrome\ Framework.framework/Google\ Chrome\ Framework
./../../chrome/tools/build/mac/verify_order: unordered symbols in Google Chrome Framework.framework/Google Chrome Framework:
_InitCommandLineArgs
_InitializeBase
ninja: build stopped: subcommand failed.

I tracked those symbols down to //services/shell/public/cpp:init_commandline. GYP does not have this problem, because the GYP targets do not have those files in their build.

I do notice that there is  //services/shell/public/cpp:cpp_for_chromium but I don't see many dependencies on that. I do see several on the :cpp target, which includes :init_commandline though.

Some sample paths:

//chrome:chrome --[private]-->
//chrome:chrome_app --[private]-->
//chrome:chrome_versioned_bundle_data --[public]-->
//chrome:verify_chrome_framework_order --[public]-->
//chrome:chrome_framework --[public]-->
//chrome:chrome_dll --[private]-->
//content/public/app:both --[private]-->
//content/public/common:common_sources --[private]-->
//services/shell/public/cpp:cpp --[public]-->
//services/shell/public/cpp:init_commandline

//chrome:chrome --[private]-->
//chrome:chrome_app --[private]-->
//chrome:chrome_versioned_bundle_data --[public]-->
//chrome:verify_chrome_framework_order --[public]-->
//chrome:chrome_framework --[public]-->
//chrome:chrome_dll --[private]-->
//content/public/app:both --[private]-->
//content/public/common:common_sources --[public]-->
//content/common:common --[private]-->
//services/shell/public/cpp:cpp --[public]-->
//services/shell/public/cpp:init_commandline

//chrome:chrome --[private]-->
//chrome:chrome_app --[private]-->
//chrome:chrome_versioned_bundle_data --[public]-->
//chrome:verify_chrome_framework_order --[public]-->
//chrome:chrome_framework --[public]-->
//chrome:chrome_dll --[private]-->
//content/public/app:both --[private]-->
//content/public/renderer:renderer_sources --[private]-->
//content/renderer:renderer --[private]-->
//services/shell/public/cpp:cpp --[public]-->
//services/shell/public/cpp:init_commandline

... etc. I'm not enough of a Mojo expert to know what the right solution is here.
 

Comment 1 by roc...@chromium.org, May 13 2016

Cc: -roc...@chromium.org
Owner: roc...@chromium.org
Status: Assigned (was: Untriaged)
I'll take a look at this soon. Can you help me understand what it means to have "unordered symbols?" I've never seen this before.

Comment 2 by rsesek@chromium.org, May 13 2016

Thanks.

The way the build step is currently written ensures that the only exported symbol is _ChromeMain. It tests that using this script: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/tools/build/mac/verify_order&q=verify_order&sq=package:chromium&type=cs

You can test it locally by building GN on Mac and running:

./chrome/tools/build/mac/verify_order _ChromeMain out/gn/Chromium\ Framework.framework/Chromium\ Framework 

I've locally fixed all the other issues the script reports, except for _InitCommandLineArgs and _InitializeBase (so if those disappear the rest will get fixed next week).

Comment 3 by roc...@chromium.org, May 13 2016

OK - as luck would have it I just got a nice new Mac build environment up
and running, so I should be able to figure this out before EOD Monday.
Project Member

Comment 4 by bugdroid1@chromium.org, May 15 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e98fa42ceeeb3b146186cf2676109190aece9881

commit e98fa42ceeeb3b146186cf2676109190aece9881
Author: rockot <rockot@chromium.org>
Date: Sun May 15 03:22:10 2016

Don't link application support into shell client library

We have some application support code stuffed in
services/shell/public/cpp which exports symbols to be
fixed up at runtime by the runner for early process
initialization. Any dependents will in turn export these
symbols, often unnecessarily.

This removes these sources from the public/cpp target
and introduces a new application_support target for
Mojo binaries to link against.

BUG= 611911 
R=ben@chromium.org

Review-Url: https://codereview.chromium.org/1978083004
Cr-Commit-Position: refs/heads/master@{#393765}

[modify] https://crrev.com/e98fa42ceeeb3b146186cf2676109190aece9881/content/browser/BUILD.gn
[modify] https://crrev.com/e98fa42ceeeb3b146186cf2676109190aece9881/content/test/BUILD.gn
[modify] https://crrev.com/e98fa42ceeeb3b146186cf2676109190aece9881/content/utility/BUILD.gn
[modify] https://crrev.com/e98fa42ceeeb3b146186cf2676109190aece9881/mojo/public/mojo_application.gni
[modify] https://crrev.com/e98fa42ceeeb3b146186cf2676109190aece9881/services/shell/public/cpp/BUILD.gn
[rename] https://crrev.com/e98fa42ceeeb3b146186cf2676109190aece9881/services/shell/public/cpp/lib/initialize_base_and_icu.cc
[modify] https://crrev.com/e98fa42ceeeb3b146186cf2676109190aece9881/services/shell/shell_public.gyp

Comment 5 by roc...@chromium.org, May 15 2016

Status: Fixed (was: Assigned)

Comment 6 by rsesek@chromium.org, May 16 2016

Blocking: 599950
Status: Verified (was: Fixed)
Thanks for the quick fix!

Sign in to add a comment