Bug 1580996 cleaned up handling of `{application,platform}.ini` but
inadvertently populated `.ini` files from test archives into the
object directory. That causes issues, especially on try. Test INI
files should come from the local artifact build and not from the
upstream test archives.
Rather than re-instate the test at the time when processed test
archives are _unpacked_, the test is done as test archives are
packed/processed.
Differential Revision: https://phabricator.services.mozilla.com/D46862
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Depends on D43156
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
The `freestanding` library is built with specific compiler flags to signify
that it is indeed freestanding code. That is, it does not depend on a
standard library.
One of the requirements of freestanding code is that the toolchain still
expects implementations of `memcpy`, `memmove`, `memcmp`, and `memset`.
I did briefly implement my own naive versions of these functions, but that
solution is less than ideal since the implementations must be `extern` and are
thus picked up by the entire `firefox.exe` binary. This denies the rest of
`firefox.exe` the benefit of optimized implementations. On Windows, the
sandbox is linked into `firefox.exe`, so we cannot just shrug and
assume that naive implementations will not have any effect on anything.
There are, however, optimized implementations of these functions that are
exported by `ntdll.dll`. They are not included in the `ntdll.lib` that is
included in the Windows SDK. Using `llvm-dlltool`, we can build an import
library containing the missing entries and then add that library to `OS_LIBS`.
Differential Revision: https://phabricator.services.mozilla.com/D43157
--HG--
extra : moz-landing-system : lando
It was added in bug 1575760 and turns out to be causing a lot more
problems than anticipated.
However, the previous status quo is also not ideal, so we do
auto-generate .cargo/config.in instead, with a little trick that allows
to just copy it to .cargo/config instead of how individual scripts would
previously manually preprocess it.
Differential Revision: https://phabricator.services.mozilla.com/D46138
--HG--
extra : moz-landing-system : lando
New releases of the `adler32-rs` crate have this license, and we already
incorporate zlib into Firefox, so crates using this license should be allowed.
..and since `adler32-rs` now has an obviously acceptable license, we can
remove it from the list of build-time exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D46283
--HG--
extra : moz-landing-system : lando
The underlying native libraries are identical between Fennec and
GeckoView example. This paves the way for removing Fennec entirely.
At the same, remove the `.ini` extraction, which is no longer required.
Differential Revision: https://phabricator.services.mozilla.com/D45769
--HG--
extra : moz-landing-system : lando
