Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
MozReview-Commit-ID: 6G3zm2jrrMx
This patch needs to use different manifests depending on whether we are building
32-bit or 64-bit Firefox. In order to distinguish between them, I am using
checking for HAVE_64BIT_BUILD in the resource file and embedding the manifests
there.
--HG--
rename : browser/app/firefox.exe.manifest => browser/app/firefox.exe.32.manifest
rename : browser/app/firefox.exe.manifest => browser/app/firefox.exe.64.manifest
rename : ipc/app/plugin-container.exe.manifest => ipc/app/plugin-container.exe.32.manifest
rename : ipc/app/plugin-container.exe.manifest => ipc/app/plugin-container.exe.64.manifest
extra : rebase_source : 2d937f47c7b79a4f29a2c2001dec5ed8f00e54bc
The GMPLoader code was in plugin-container so that it was covered by
Adobe's voucher of plugin-container, but that's no longer necessary.
MozReview-Commit-ID: 3VRBAohRI9I
--HG--
extra : rebase_source : 58a30855ade14af4c4b1420edabd3abb398f232e
Preloading libmozsandbox allows the symbol interpositions used by
sandboxing to be defined there instead of statically linked into the
executable; this patch also does that.
MozReview-Commit-ID: FL1QWLSKA0S
--HG--
rename : security/sandbox/linux/interpose/SandboxHooks.cpp => security/sandbox/linux/SandboxHooks.cpp
This way they'll continue to be at the beginning of the symbol search
path after mozsandbox returns to being a shared library instead of
statically linked into plugin-container.
--HG--
rename : security/sandbox/linux/SandboxHooks.cpp => security/sandbox/linux/interpose/SandboxHooks.cpp
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Disabled on Mac (content processes need to use plugin-container.app for
UI reasons) and on Linux unless --disable-sandboxing (build issues).
Based on work by George Wright <george@mozilla.com>.
--HG--
extra : amend_source : 43986e25743de21e3ddfb7893e3ed550fe6eef76
I want the EME device binding/nodeId code to be callable from gtests, as well
as in plugin-container. I need this because I want to add a gtest that ensures
that we don't regress the EME/GMP device binding code. I want to call the GMP
device binding code in the gtest and in the GMP process, and compare the
result.
So we need to make it possible to link the device binding code into the gtests
as well as plugin-container. So move all code that device binding calls into
librlz, to make it easier to link against all the code required.
Note: the device binding code needs to be statically linked into
plugin-container so that it's covered by the Adobe CDM's voucher tool.
MozReview-Commit-ID: AvBAe1dh49Z
--HG--
rename : ipc/app/sha256.c => dom/media/gmp/rlz/sha256.c
rename : ipc/app/sha256.h => dom/media/gmp/rlz/sha256.h
extra : rebase_source : f60f1e68649fa90cbe1f2fe09f5f69948444b1df
The original changeset that is being backed out had comment:
Bug 1023941 - Part 2: Static-link the CRT into plugin-container.exe.
MozReview-Commit-ID: 1iPJghgd0t2
--HG--
extra : rebase_source : cbed4e43f51af8ea0c3adbfc150ed029fe0d0f57
We're going to change how e.g. CFLAGS are printed out in backend.mk, and
to fit that model, the data in the corresponding moz.build variables
need to be straightened up.
Having HASH_NODE_ID_WITH_DEVICE_ID #defined is enough for GMPLoader to start
using the Mac version of GetRawMachineId.
Note: The stack (that may contain information gathered during GetRawMachineId)
is not erased, so it could theoretically be possible for a compromised GMP to
find out some sensitive user information. Another bug will deal with this.
These are all conditional uses of ALLOW_COMPILER_WARNINGS=True that are no
longer necessary.
--HG--
extra : rebase_source : e654fa940aed18b1d5ef7b2bebb45bbef59cfd84
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
This means that B2G plugin-container must (dynamically) link against
libmozsandbox in order to call into it before initializing Binder.
(Desktop Linux plugin-container already contains the sandbox code.)
Specifically:
* SandboxCrash() uses internal Gecko interfaces, so stays in libxul.
* SandboxInfo moves to libxul from libmozsandbox, which no longer exists.
* Where libxul calls Set*Sandbox(), it uses weak symbols.
* Everything remains as it was on mobile.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
This is a little tricky only because MOZ_CHILD_PROCESS_NAME is
"lib/libplugin-container.so" on Android, which meant special handling
at multiple places in the tree. This patch reduces the number of such
places.
Aaron Klotz
Mike Hommey
Chris Pearce
Joel Maher
Jed Davis
Chris Peterson
Tom Tromey
Bob Owen
George Wright
Ehsan Akhgari
Gerald Squelart
Nicholas Nethercote
David Major
James Willcox
Nathan Froyd
Steven Michaud
Carsten "Tomcat" Book
Martin Liska
Nick Alexander