Bug 1081031 - Unbust xulrunner mac builds by not exporting all JS symbols (bug 920731). r=bsmedberg
Bug 1080994 - Build libclearkey without a dependency on mozalloc or mozglue. r=dkeeler,r=cpearce
Bug 1081000 - Build xpt tests without a dependency on xul, mozalloc and mozglue. r=bsmedberg
Bug 1081011 - Remove memory/replace/defs.mk. r=mshal
Bug 1077366 - Remove most symbol wrapping from Android builds. r=nfroyd

Since essentially everything is linked to libmozglue and libmozglue takes
precedence in symbol resolution in our dynamic linker, there is no need
to wrap most symbols. PR_GetEnv/PR_SetEnv still needs wrapping because
there's no other way to actually wrap the calls from NSPR itself and NSS,
as well as the symbols wrapped because our dynamic linker can't find them
in system libraries on some devices because they're weak.
Bug 1080341 - Remove --enable-wrap-malloc/--with-wrap-malloc. r=mshal

With bug 1077366, --enable-wrap-malloc is not abused anymore for android
linkage. Other than android linkage, the option has been of limited
usefulness since bug 804303 (replace-malloc), which allows runtime wrapping.

In fact, chances are --enable-wrap-malloc breaks things with jemalloc
integration.

This doesn't, however, remove those options from standalone js builds,
although it's not clear they're any useful there either.
Bug 1080342 - Change how the symbols the flash plugin uses are hooked on Android. r=snorp

With bug 1077366, the linker makes the library containing it a fake
LD_PRELOAD. As a consequence, instead of, in the linker itself,
explicitely special-casing the symbols that disappeared in Android 4.4
that the flash plugin uses, it is now possible to use normal symbol
resolution to stubs defined separately in libmozglue.
Bug 1080904 - Allow to pass an extra input file for folded-lib symbols through configure. r=mshal
Bug 1080319 - Remove the -remote option. r=bsmedberg

The -remote option has existed essentially forever, but its usefulness is
questionable:
- It requires a running instance to be any useful, so any script actually
  using it should first do -remote 'ping()' and handle the response properly.
- It is not cross-application. The remote service dispatches the -remote
  commands to the command line handler, and, for example, desktop b2g builds
  don't have handlers for -remote (although thunderbird and seamonkey do).
- It is not a cross-platform option, which leads to the following point:
- There are other command line ways to do the same thing (at least in
  Firefox), without having to jump through hoops with -remote 'ping()',
  because there are command line options to do those same things on non-X11
  platforms.

For the latter, in Firefox case:
- -remote 'openURL(url)' can be replaced with firefox url
- -remote 'openURL(url,new-tab)' can be replaced with firefox -new-tab url
- -remote 'openURL(url,new-window)' can be replaced with firefox -new-window
  url
- -remote 'openfile(file,...)' is the same as -remote 'openurl(file,...) so,
  can be replaced as above
- -remote 'xfedocommand(openbrowser)' is inherited from the mozilla suite and
   doesn't make much sense, but can be replaced with firefox -new-window

The interesting part is that without changing nsBrowserContentHandler.js,
-remote still works, meaning that if people really feel strongly about
-remote, they'll still be able to write an addon to bring it back. This also
means this patch actually doesn't remove -remote for applications other than
Firefox that do support it, although -remote 'ping()' doesn't work as
expected. However, other -remote commands will now work even without a
running instance.