On some Android devices (e.g., Sony Xperia), package manager may
fail to extract native libraries when updating Chrome.
The change tries alleviate the situation by:
1) name libchrome with version number;
2) when failed to load library, try to extract native libraies
and load them.
BUG=311644
Review URL: https://codereview.chromium.org/200753002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@258546 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Changes:
1. Consolidate the logic of "ENABLE_MDNS or OS_MACOSX" into a single C++/grit/ninja define called "enable_service_discovery"
2. Move a bunch of files from being conditioned on enable_mdns to being conditioned on enable_service_discovery.
3. Create a separate, simplified PrivetHTTPAsynchronousFactory that synchronously returns a PrivetHTTPClient for the mDNS host and port
without resolving, since on OSX mDNS resolution is baked into the operating system.
BUG=352811
Review URL: https://codereview.chromium.org/195983023
git-svn-id: http://src.chromium.org/svn/trunk/src/build@258480 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The Android WebView uses the system ICU on target anyway, so this only
affects the host build of ICU used to build the host V8. This means the
flag is now enabled on all platforms by default and no longer needs to
be conditional.
BUG=
Review URL: https://codereview.chromium.org/204783003
git-svn-id: http://src.chromium.org/svn/trunk/src/build@258278 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Reason for revert:
Might be the cause for memory exhaustion during compilation on the Linux dbg build bot:
http://build.chromium.org/p/chromium.linux/buildstatus?builder=Linux%20Builder%20%28dbg%29%2832%29&number=21991
Original issue's description:
> Adding -g3 to get macro expansion support. (Default is -g2.)
> Adding -gdwarf-4 for macro expansion support.
>
> * gcc 4.6 outputs DWARF-2 by default
> * gcc 4.7 outputs DWARF-4 by default
> * clang <3.4 outputs DWARF-3 by default
> * clang >3.4 outputs DWARF-4 by default
>
> From http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> > -g3
> > Level 3 includes extra information, such as all the macro
> > definitions present in the program. Some debuggers support macro
> > expansion when you use -g3.
> >
> > -gdwarf-4
> > Produce debugging information in DWARF format (if that is
> > supported). The value of version may be either 2, 3 or 4; the
> > default version for most targets is 4. Note that with DWARF
> > Version 2, some ports require and always use some non-conflicting
> > DWARF 3 extensions in the unwind tables.
> >
> > Version 4 may require GDB 7.0 and -fvar-tracking-assignments for
> > maximum benefit.
>
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=257944TBR=stuartmorgan@chromium.org,erg@chromium.org,mark@chromium.org,mmoss@chromium.org,thestig@chromium.org,mmoss@google.com,mithro@mithis.com
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/203683007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257959 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Adding -gdwarf-4 for macro expansion support.
* gcc 4.6 outputs DWARF-2 by default
* gcc 4.7 outputs DWARF-4 by default
* clang <3.4 outputs DWARF-3 by default
* clang >3.4 outputs DWARF-4 by default
From http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> -g3
> Level 3 includes extra information, such as all the macro
> definitions present in the program. Some debuggers support macro
> expansion when you use -g3.
>
> -gdwarf-4
> Produce debugging information in DWARF format (if that is
> supported). The value of version may be either 2, 3 or 4; the
> default version for most targets is 4. Note that with DWARF
> Version 2, some ports require and always use some non-conflicting
> DWARF 3 extensions in the unwind tables.
>
> Version 4 may require GDB 7.0 and -fvar-tracking-assignments for
> maximum benefit.
Review URL: https://codereview.chromium.org/198363002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257944 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
A bunch of mac builder bots are still on 10.6 (http://crbug.com/353529)
> roll clang 198389:202554
>
> This change contains several big changes, many of the caused by upstream
> llvm enabling c++11 in their codebase and thus having higher minimum
> requirements for their toolchain and runtime environment:
>
> * clang on OS X now requires libc++, which means it'll only run on OS X 10.7+,
> so change the deployment target from 10.5 to 10.7 (we were planning on
> requiring 10.8 or 10.9, see bug 335325, but since several people are waiting
> on a new clang, let's go to 10.7 only for now and do more as a follow-up)
> * On OS X, the compiler is only usable with libc++ if libc++ is checked out
> and `make install` is run, so do that for the phase 1 compiler.
> (Chrome doesn't use libc++ yet, so we don't do that for the bootstrapped
> compiler.)
> * clang on linux now needs libstdc++ 4.7+ which isn't present on precise.
> So we now include a newer libstdc++ in the compiler bundle (meaning
> this clang should still run on precise).
> * clang is broken for android at r202554. To unblock oilpan, merge three
> later changes into this roll, llvm r202793, r203601, and r203635
>
> Regular, less tricky clang roll stuff:
> * Disable the new warning -Wabsolute-value for now (crbug.com/351479
> for turning it on)
> * Disable -Wno-tautological-pointer-compare for libxml where it now
> fires.
> * Since this bundles a new version of the oilpan plugin, bump its suffix to _3
> * Change plugin code to track upstream api change
> * Remove plugin flag check-url-directory as that's now always on
>
> Due to the c++11 stuff, it's likely that this change will get reverted a few times.
>
> BUG=351479, 287029,341352,333968,335325
> TBR=hans@chromium.org
>
> Review URL: https://codereview.chromium.org/195623002TBR=thakis@chromium.org
Review URL: https://codereview.chromium.org/203313004
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257620 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This change contains several big changes, many of the caused by upstream
llvm enabling c++11 in their codebase and thus having higher minimum
requirements for their toolchain and runtime environment:
* clang on OS X now requires libc++, which means it'll only run on OS X 10.7+,
so change the deployment target from 10.5 to 10.7 (we were planning on
requiring 10.8 or 10.9, see bug 335325, but since several people are waiting
on a new clang, let's go to 10.7 only for now and do more as a follow-up)
* On OS X, the compiler is only usable with libc++ if libc++ is checked out
and `make install` is run, so do that for the phase 1 compiler.
(Chrome doesn't use libc++ yet, so we don't do that for the bootstrapped
compiler.)
* clang on linux now needs libstdc++ 4.7+ which isn't present on precise.
So we now include a newer libstdc++ in the compiler bundle (meaning
this clang should still run on precise).
* clang is broken for android at r202554. To unblock oilpan, merge three
later changes into this roll, llvm r202793, r203601, and r203635
Regular, less tricky clang roll stuff:
* Disable the new warning -Wabsolute-value for now (crbug.com/351479
for turning it on)
* Disable -Wno-tautological-pointer-compare for libxml where it now
fires.
* Since this bundles a new version of the oilpan plugin, bump its suffix to _3
* Change plugin code to track upstream api change
* Remove plugin flag check-url-directory as that's now always on
Due to the c++11 stuff, it's likely that this change will get reverted a few times.
BUG=351479, 287029,341352,333968,335325
TBR=hans@chromium.org
Review URL: https://codereview.chromium.org/195623002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257618 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
builds,
* Slow link times.
* Slow gdb startup times.
Lots more detailed information at http://gcc.gnu.org/wiki/DebugFission
Overall, this improves linking speed of debug Chrome builds on Linux
by ~12% and speeds up gdb by around 30%.
This requires a objcopy with --extract-dwo object (binutils newer then
2.22.52.0.4 // 2.23). Ubuntu Precise only comes with 2.23
BUG=
Review URL: https://codereview.chromium.org/197013010
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257424 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This allows to do a PGO optimized build of Chrome with the following commands:
python build\gyp_chromium -Dchrome_pgo_phase=1
ninja -C out\Release chrome
run with '--no-sandbox' + pgosweep
python build\gyp_chromium -Dchrome_pgo_phase=2
ninja -C out\Release chrome
----- Approach that didn't worked -----
(see comment #13 to know why this didn't work)
Instead of having the following gyp dependency chain (for a regular build), here '->' means 'depends on':
'chrome'->|'chrome_main_dll'
----------|'chrome_child_dll'
we know have the following one (when chrome_pgo==1):
'chrome'->|'chrome_main_dll' |->'chrome_pgo_optimize'->|'chrome_main_dll_pgi'
----------|'chrome_child_dll'|-------------------------|'chrome_child_dll_pgi'
The '*_pgi' target correspond to the instrumented dll, the name of the DLLs produced by target will be terminated by '_pgi'.
During the 'chrome_pgo_optimize' step the instrumented DLLs will be renamed (the '_pgi' suffix will be removed) and Chrome will be run against a set of profile test cases, pgosweep.exe will also be invoked to collect the instrumentation data.
Then the main targets ('chrome_main_dll' and 'chrome_child_dll') will be linked with the flag /LTCG:PGOPTIMIZE, this will produce the optimized DLLs.
--------------------------------------------
R=scottmg@chromium.org
BUG=
Review URL: https://codereview.chromium.org/187813008
git-svn-id: http://src.chromium.org/svn/trunk/src/build@257133 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Xcode 5.1 ships with a clang that deprecates the register keyword by default.
This warning flag is needed in order to compile for iOS with Xcode 5.1.
However, the old version of Xcode (5.0) does not understand this flag. In order
to temporarily support compiling on both versions of Xcode, this CL also adds
-Wno-unknown-warning-option to suppress errors about unknown compiler flags.
This flag will be removed as soon as all of the bots have been updated with
Xcode 5.1, within a week.
BUG=255186,337611
TEST=None
Review URL: https://codereview.chromium.org/194803006
git-svn-id: http://src.chromium.org/svn/trunk/src/build@256592 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Previously, only 32-bit Google Chrome Linux was being built with x87 floating point math, which led to bugs caused by 80-to-{32,64}-bit rounding errors that weren't caught on the main Chromium builders. UMA data tells us there are ~0 Google Chrome Linux users without SSE2, making a strong case to require SSE2 across the board and align the Google Chrome build closer to the Chromium build.
As for disable_sse2 option, it was added in r45777 but it's unclear if anyone is using it outside of some other GYP code that flips it to 1 for ARM and MIPS architectures. Instead replace the few instances that don't support SSE2 with specific checks for the target architecture and remove the option entirely.
BUG=348761
R=jamesr@chromium.org
TBR=cpu
Review URL: https://codereview.chromium.org/187423002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@256366 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- Remove DCHECK in non-official-release build by default
- Gyp variable dcheck_always_on=1 (existing) forces to enable DCHECK
in release build
- Remove flag --enable-dcheck
Other effects/notes:
- Now allow "buildtype=Official dcheck_always_on=1" (which will
enable DCHECK in official build) combination.
- Gyp variable logging_like_official_build no longer has an effect
- Leave DCHECK_IS_ON() unchanged. May deal with it in a later change
if needed.
This won't affect bots which use dcheck_always_on=1.
BUG=350462
TEST=LoggingTest.Dcheck
R=thakis@chromium.org
TBR=darin,sehr (command line changes in components/nacl and mojo)
Review URL: https://codereview.chromium.org/189603007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@255987 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
0. Roll icu to r249466 to copy Android-specific icudtl.dat
1. Turn it in build/common.gypi by default except for android webview build. Move it inside L2 var dict and pull it up to the top level var dict to make 'Google Chrome' build on Android happy.
2. Add an entry for icudtl.dat to chrome/chrome_android_paks.gypi so that
it's copied to assets directory for Chrome and related targets.
3. Extract icudtl.dat from the asset and copy to DIR_ANDROID_APP_DATA and make it world-readable so that child processes (sandboxed with uid) can read it.
4. Add icudtl.dat to MANDATORY_PAKS list in various Android build targets
Google Chrome has #4 but in a separate CL ( https://chrome-internal-review.googlesource.com/#/c/155554/ ). That CL will land before this CL.
This also depends on a Blink change https://codereview.chromium.org/183013006/TBR=avi@chromium.org
BUG=72633
TEST=base_unittests:*Convers*, net_unittests:*IDN*, browser tests on all platforms.
TEST=On Android, 1. Layout tests
2. build/android/test_runner.py gtest -s webkit_unit_tests
--gtest_filter=WebFrameTest.SelectRange*
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=253938
Review URL: https://codereview.chromium.org/156333002
git-svn-id: http://src.chromium.org/svn/trunk/src/build@255762 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This will be used in Blink to protect the old implementation of hiDPI
filter scaling. Once CC has been taught how to apply hiDPI to filters,
the Blink implementation will be switched off at the same time by
removing this #define.
BUG=281516
Review URL: https://codereview.chromium.org/182863007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@255580 4ff67af0-8c30-449e-8e8b-ad334ec8d88c