On OS X, there are currently Google Chrome Helper EH.app and
Google Chrome Helper NP.app, which are no longer used with the deprecation
of NPAPI. This changes removes the helpers, both from the build process,
and any code referring to them.
The make_more_helpers.sh is now a no-op, but is left in because it will
soon be needed for the Library Validation feature (to generate
Google Chrome Helper NLV.app).
BUG=520680
Review URL: https://codereview.chromium.org/1315163004
Cr-Original-Commit-Position: refs/heads/master@{#347235}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: f5ed554ef814418d64510aa18b43b69315e40814
W0105: 16,-1: String statement has no effect
C0323: 45,4:main: Operator not followed by a space
print >>sys.stderr, out
^
BUG=
Review URL: https://codereview.chromium.org/539843002
Cr-Original-Commit-Position: refs/heads/master@{#293294}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9520d408282a2a498ef6fc20f9abacfb899abbe7
full installer is desired.
Formerly, the tag identified only the channel that Chrome was on. The tag is
being enhanced to detect the CPU's bitness (adding "-32bit" for 32-bit-only,
non-64-bit-capable CPUs) and whether a full (as opposed to binary diff patch)
update is requested (adding "-full").
CPU bitness detection ought to be a feature of Keystone, but Keystone uses the
NXGetLocalArchInfo to determine the CPU type, and winds up always reporting
"i486". The "-32bit" tag suffix will be present whenever the
"hw.cpu64bit_capable" sysctl name is not found or has value 0. This enables
proper detection of users who are capable of running 64-bit Chrome on the
server side.
When a binary diff patch update application fails in dirpatcher, typically the
result of modifications made to existing installations, the "-full" tag suffix
will be set. On a subsequent update attempt, the server can detect this value
and provide the client with a full updater package, which does not depend on
the existing installation. The "-full" tag suffix is cleared on successful
update installation.
BUG=18323,54047,225352,303280,316916
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/102963007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@242964 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In Xcode 5, strip is no longer in SYSTEM_DEVELOPER_BIN_DIR. It is only in
DT_TOOLCHAIN_DIR. I also checked Xcode 4.6.1 and found that DT_TOOLCHAIN_DIR
was also set there, and strip is in both SYSTEM_DEVELOPER_BIN_DIR and
DT_TOOLCHAIN_DIR in that version.
Environment variables as set when Xcode is installed at /Applications/Xcode.app:
SYSTEM_DEVELOPER_BIN_DIR=/Applications/Xcode.app/Contents/Developer/usr/bin
DT_TOOLCHAIN_DIR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefa
ult.xctoolchain
xcrun should be able to find strip without having to resort to manual
environment interpretation.
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/24352006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@227787 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
When the SDK is set to something that Xcode doesn't know about (such as 10.6),
xcrun doesn't work correctly.
mark@cougar bash$ xcrun strip
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: no files specified
mark@cougar bash$ SDKROOT=/SDKs/MacOSX10.6.sdk xcrun strip
xcodebuild: error: SDK "/SDKs/MacOSX10.6.sdk" cannot be located.
xcrun: error: unable to find utility "strip", not a developer tool or in PATH
> Run strip via xcrun.
>
> In Xcode 5, strip is no longer in SYSTEM_DEVELOPER_BIN_DIR. It is only in
> DT_TOOLCHAIN_DIR. I also checked Xcode 4.6.1 and found that DT_TOOLCHAIN_DIR
> was also set there, and strip is in both SYSTEM_DEVELOPER_BIN_DIR and
> DT_TOOLCHAIN_DIR in that version.
>
> Environment variables as set when Xcode is installed at /Applications/Xcode.app:
>
> SYSTEM_DEVELOPER_BIN_DIR=/Applications/Xcode.app/Contents/Developer/usr/bin
> DT_TOOLCHAIN_DIR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefa
> ult.xctoolchain
>
> xcrun should be able to find strip without having to resort to manual
> environment interpretation.
>
> R=thakis@chromium.org
>
> Review URL: https://codereview.chromium.org/24352006TBR=mark@chromium.org
Review URL: https://codereview.chromium.org/26235007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@227524 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In Xcode 5, strip is no longer in SYSTEM_DEVELOPER_BIN_DIR. It is only in
DT_TOOLCHAIN_DIR. I also checked Xcode 4.6.1 and found that DT_TOOLCHAIN_DIR
was also set there, and strip is in both SYSTEM_DEVELOPER_BIN_DIR and
DT_TOOLCHAIN_DIR in that version.
Environment variables as set when Xcode is installed at /Applications/Xcode.app:
SYSTEM_DEVELOPER_BIN_DIR=/Applications/Xcode.app/Contents/Developer/usr/bin
DT_TOOLCHAIN_DIR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefa
ult.xctoolchain
xcrun should be able to find strip without having to resort to manual
environment interpretation.
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/24352006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@227347 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The action will copy the ASan dynamic runtime to the output dir and into every
bundled executable being built.
Unlike the previous change, this one does not touch build/all.gyp, since our target
doesn't need to be built when building 'All'.
BUG=170629
TBR=thakis,mark
Review URL: https://codereview.chromium.org/12685006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@187566 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
SDK to verify when an SDK path is set. The SDK path supersedes whatever
find_sdk is supposed to find.
Also: Reorganize the SDK and deployment target variables to be scoped more
appropriately. Add a mac_sdk_min variable to set the main argument to
find_sdk.
Review URL: https://chromiumcodereview.appspot.com/11068023
git-svn-id: http://src.chromium.org/svn/trunk/src/build@160536 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This allows the file_version_info_mac code to make sense for any SCM
(e.g., git). It also aligns the use of FetchVersionInfo to its
documented behavior, which is to return a (branch, revision) tuple
for "some appropriate revision control system".
BUG=None
Review URL: https://chromiumcodereview.appspot.com/10828228
git-svn-id: http://src.chromium.org/svn/trunk/src/build@153101 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Having to manually set mac_sdk was a FAQ when Xcode 4 was released. Now
we're using the 10.6 SDK by default, but Xcode 4.4 ships only with the
10.7 and 10.8 SDKs, so it'll likely become a FAQ again. Automatically
set mac_sdk to something sensible.
(People who explicitly say "mac_sdk=10.6" will have to stop doing so
when they switch to Xcode 4.4.)
BUG=121162
TEST=Build without mac_sdk in GYP_DEFINES. Something useful happens
with Xcode 3.2.6, Xcode 4, Xcode 4.4.
Review URL: https://chromiumcodereview.appspot.com/10824055
git-svn-id: http://src.chromium.org/svn/trunk/src/build@148817 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
without running install_name_tool on it.
This is necessary now that KeystoneRegistration.framework is signed.
install_name_tool would invalidate the signature. Since nothing is linked
against KeystoneRegistration.framework, its LC_ID_DYLIB is irrelevant and it
can be allowed to remain as-is.
BUG=131081
TEST=none
Review URL: https://chromiumcodereview.appspot.com/10535037
git-svn-id: http://src.chromium.org/svn/trunk/src/build@140818 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Client loader processes.
Some plug-ins depend on having an executable heap. They write code to data
pages and attempt to execute it without calling mprotect to mark this code
as executable.
Native Client needs to allocate a contiguous 1GB of address space. ASLR may
interfere with there being a "hole" this large in the address space by the
time NaCl makes its request.
Non-executable heaps are only available in 10.7 and later for 32-bit
processes.
PIE/ASLR was formerly disabled for all processes other than the browser
process. This change reenables it for all processes other than the NaCl
loader. PIE/ASLR is available on 10.5 and later, although the implementation
is stronger in 10.7 than in earlier releases.
This change results in two new helpers in addition to the existing
Chromium Helper.app: Chromium Helper EH.app (for executable heaps) and
Chromium Helper NP.app (for no PIE). libplugin_carbon_interpose.dylib moves
out of the helper .app and directly into the versioned directory. The
InfoPlist.strings have been removed from the helper app, but empty .lproj
directories remain.
BUG=90221, 93551
TEST=everything
Review URL: http://codereview.chromium.org/7714018
git-svn-id: http://src.chromium.org/svn/trunk/src/build@97984 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
kerrnel
sbc
yoz
thestig
ukai
rsesek@chromium.org
glider@chromium.org
mad@chromium.org
brettw@chromium.org
mark@chromium.org
mmoss@chromium.org
jeremy@chromium.org
thakis@chromium.org
jochen@chromium.org
stuartmorgan@chromium.org
avi@chromium.org
maruel@chromium.org
thomasvl@chromium.org
jrg@chromium.org
jhawkins@chromium.org
gregoryd@google.com