Mojo interface libraries: set install name and search path properly on Mac.

build/common.gypi

 # Copyright (c) 2012 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 # IMPORTANT:
 # Please don't directly include this file if you are building via gyp_chromium,
 # since gyp_chromium is automatically forcing its inclusion.
 {
   # Variables expected to be overriden on the GYP command line (-D) or by
   # ~/.gyp/include.gypi.
@@ skipping 2127 matching lines @@
       ['OS=="linux" and clang==1 and host_arch=="ia32"', {
         # TODO(dmikurube): Remove -Wno-sentinel when Clang/LLVM is fixed.
         # See http://crbug.com/162818.
         'cflags+': ['-Wno-sentinel'],
       }],
       ['branding=="Chrome"', {
         'defines': ['GOOGLE_CHROME_BUILD'],
       }, {  # else: branding!="Chrome"
         'defines': ['CHROMIUM_BUILD'],
       }],
-      ['OS=="mac" and component=="shared_library"', {
+      ['OS=="mac"', {
         'xcode_settings': {
           'DYLIB_INSTALL_NAME_BASE': '@rpath',
           'LD_RUNPATH_SEARCH_PATHS': [
             # For unbundled binaries.
             '@loader_path/.',
             # For bundled binaries, to get back from Binary.app/Contents/MacOS.
             '@loader_path/../../..',

[Nico, 2014/03/06 19:10:56]

Huh, I'm pretty sure the vast majority of targets doesn't want this in a
non-component build. With this, you could put a Chromium Framework next to
Chromium.app, and Chromium would then load that framework instead of the one
inside its app package I think, right? Which sounds like potentially a security
thing?

Why is libmojo_system a dylib in static library builds?

[yzshen1, 2014/03/06 22:09:21]

(Forgive my ignorance. First time working on mac issue.)
Do you mean the other parts are okay in non-component build (line 2150-2153)?
libmojo_system is provided by the mojo host and used by mojo apps.
It exposes the API that the host allows the apps to use. At run time, the host
injects the real implementation of the API into this dynamic library. Therefore,
static-linking doesn't make sense.

           ],
         },
       }],
       ['enable_rlz==1', {
         'defines': ['ENABLE_RLZ'],
       }],
       ['component=="shared_library"', {
         'defines': ['COMPONENT_BUILD'],
       }],
       ['toolkit_views==1', {
@@ skipping 2867 matching lines @@
     # settings in target dicts.  SYMROOT is a special case, because many other
     # Xcode variables depend on it, including variables such as
     # PROJECT_DERIVED_FILE_DIR.  When a source group corresponding to something
     # like PROJECT_DERIVED_FILE_DIR is added to a project, in order for the
     # files to appear (when present) in the UI as actual files and not red
     # red "missing file" proxies, the correct path to PROJECT_DERIVED_FILE_DIR,
     # and therefore SYMROOT, needs to be set at the project level.
     'SYMROOT': '<(DEPTH)/xcodebuild',
   },
 }