Remove dependency on --gc-sections for most Android debug targets.

chrome/chrome_android.gypi

Index: chrome/chrome_android.gypi
diff --git a/chrome/chrome_android.gypi b/chrome/chrome_android.gypi
index 48e8cdb08593cb8da12b1da5aaf9ae45a6136f23..f900f1c039b45454af897b6cb07ba1325a9209fb 100644
--- a/chrome/chrome_android.gypi
+++ b/chrome/chrome_android.gypi
@@ -44,6 +44,13 @@
           'dependencies': [
             '../base/allocator/allocator.gyp:allocator', ],
         }],
+        ['OS=="android"', {
+          'ldflags': [
+            # Some android targets depend on --gc-sections to link.
+            # Force --gc-sections also for Debug builds (see crbug.com/159847).
+            '-Wl,--gc-sections',

[Nico, 2014/04/11 20:36:59]

The idea is to remove this too eventually, right (if I get the CL description
right)? Say "TODO: remove" in front of the bug link

[Primiano Tucci (use gerrit), 2014/04/12 10:26:00]

Right. However the chrome layer on Android is damn more messy: there are several
hundreds linking errors (when disabling gc-sections) coming mostly from
extensions support code. That might take much more than a couple of days of
headaches, as it was in this case.
My priority at the moment is cleaning up at least the content layer at the other
targets, remove the global --gc-sections blanket and avoid future regressions,
at least on all-but-two targets.

FTR all this started as a consequence of the arm64 bringup. The linker in the
arm64 toolchain  still doesn't support --gc-sections.
In general the idea that we need the linker GC to build makes me extremely
grumpy. I find linker GC a great way to reduce binary size, but using it as a
precondition for building....brrrr)
 

+          ],
+        }],
       ],
     },
     {