We always define it to the same thing, and we're inconsistent in whether
we use `CPP_THROW_NEW` or `throw()`, so we might as well just use the
standard C++ thing and get rid of some baggage.
Differential Revision: https://phabricator.services.mozilla.com/D40425
--HG--
extra : moz-landing-system : lando
Since kernel32.lib is a defaultlib we do not need to explicitly include it
in the OS_LIBS list; the linker will implicitly add it to the end of the list.
In fact, its presence interferes with other explicitly added .lib files that
should take precedence.
Differential Revision: https://phabricator.services.mozilla.com/D41806
--HG--
extra : moz-landing-system : lando
We needed these rules and bits for the QT widget port, but there's no
longer a QT port in the tree, so we might as well remove them.
Differential Revision: https://phabricator.services.mozilla.com/D38886
--HG--
extra : moz-landing-system : lando
When we build mar, there is no reason not to build signmar as well. It
used to be optional because not all platforms were supported, but they
are now.
... except when building the newly added tools/update-packaging,
which builds the mar tool as a standalone thing, and building signmar
as well causes complications.
Differential Revision: https://phabricator.services.mozilla.com/D36992
--HG--
extra : moz-landing-system : lando
When we build mar, there is no reason not to build signmar as well. It
used to be optional because not all platforms were supported, but they
are now.
Differential Revision: https://phabricator.services.mozilla.com/D36992
--HG--
extra : moz-landing-system : lando
We've been relying on frame pointers being indirectly enabled via things
like --enable-profiling for some time, but this doesn't scale because
some things may want frame pointers while wanting --disable-profiling.
So we move MOZ_FRAMEPTR_FLAGS to python configure and add a new option
to decide whether to enable frame pointers or not.
Differential Revision: https://phabricator.services.mozilla.com/D34117
--HG--
extra : moz-landing-system : lando
There are ongoing lmdb issues we need to sort out before we can ship
cert_storage (see e.g. bug 1538541 and bug 1550174).
Differential Revision: https://phabricator.services.mozilla.com/D32885
--HG--
extra : moz-landing-system : lando
This also enables using cert_storage for OneCRL, since it and intermediate
preloading both use the same backend.
Differential Revision: https://phabricator.services.mozilla.com/D31345
--HG--
extra : moz-landing-system : lando
The definitions can't be entirely removed yet because NSS still needs them.
Differential Revision: https://phabricator.services.mozilla.com/D23454
--HG--
extra : moz-landing-system : lando
That will make it detected when we bump the MACOSX_DEPLOYMENT_TARGET
to a value >= 10.12.
Differential Revision: https://phabricator.services.mozilla.com/D18310
--HG--
extra : moz-landing-system : lando
Since ./mach bootstrap installs Android SDK into ~/.mozbuild, we should detect
this location as default SDK install path.
Also, --with-android-max-sdk and --with-android-min-sdk are still in android.m4
because confvars.sh sets MOZ_ANDROID_MIN_SDK_VERSION.
Differential Revision: https://phabricator.services.mozilla.com/D15463
--HG--
extra : moz-landing-system : lando
Those tests rely on the build not being a cross-compile, which is fine
most of the time, but more importantly, rely on the fact that the
version of sqlite that Firefox is being built against is the same as the
one it will be running against, which is not likely to be true.
So, all in all, it's better to do the checks at runtime.
And while they could be restricted to when building against system
sqlite, we still run them for in-tree sqlite, to ensure that we actually
built it with the expected options.
Differential Revision: https://phabricator.services.mozilla.com/D18057
--HG--
extra : moz-landing-system : lando
It relies on AC_TRY_RUN, which doesn't work on cross-compiles. What this
means is that the feature has been disabled on mac builds on automation
ever since we switched to cross-compiles. It's still enabled on local
mac builds because the test runs there, and returns "yes". It also means
it's disabled on Android, where it probably works (at least debug tests
on try don't complain).
It also doesn't currently run on Windows because it's in a skipped
section on Windows, but if moved out of that section, the test returns
"no".
So, we remove any configure test for the feature, in favor of
preprocessor checks in nsTraceRefcnt.cpp.
Depends on D18055
Differential Revision: https://phabricator.services.mozilla.com/D18056
--HG--
extra : moz-landing-system : lando
Autoconf 2.13 documentation says: "If the memcmp function is not
available, or does not work on 8-bit data (like the one on SunOS 4.1.3),
add `memcmp.o' to output variable LIBOBJS."
The documentation of more recent versions of autoconf also mention NeXT
x86 OpenStep, and say "This macro is obsolescent, as current systems
have a working memcmp. New programs need not use this macro."
We're also not using LIBOBJS, so, even if somehow some machine had the
test detect something weird going on, the result of the test wouldn't
have an effect on the build anyways.
Apart from that, it's also one of the few tests that relies on actually
running a compiled binary during configure, which requires some
autoconf-specific definition of cross-compilation (where --target=i686
--host=x86_64 is not cross-compilation), and we're better off getting
rid of such tests completely.
Depends on D18054
Differential Revision: https://phabricator.services.mozilla.com/D18055
--HG--
extra : moz-landing-system : lando
While not related, it turns out this test was opted in by ourselves,
while it's practically useless. Recent autoconf documentation says it's
obsolescent, and even autoconf 2.13 documentation said with "recent
versions of the GNU C compiler", the issue it's detecting "is becoming
a less prevalent problem". Recent as of 20 years ago.
Differential Revision: https://phabricator.services.mozilla.com/D18054
--HG--
extra : moz-landing-system : lando
We currently rely on WIN_DIA_SDK_BIN_DIR being passed, but we can
actually derive it from the DIA SDK directory. So we now do that, except
when it's given explicitly.
While in the vicinity, move the dia2.h check to python configure.
With WIN_DIA_SDK_BIN_DIR being derived and not set when dia2.h is not
found, we don't really need MSVC_HAS_DIA_SDK anymore, so we just check
for WIN_DIA_SDK_BIN_DIR to determine whether to build dump_syms or not.
One exception to the above is when WIN_DIA_SDK_BIN_DIR is passed in,
which we only keep for the in-tree mozconfigs for now. We'll remove that
possibility after bug 1523201.
Depends on D17892
Differential Revision: https://phabricator.services.mozilla.com/D17893
--HG--
extra : moz-landing-system : lando
Nathan Froyd
Tom Ritter
Mike Hommey
Aaron Klotz
rdalal
Makoto Kato
Ryan VanderMeulen
Bogdan Tara
J.C. Jones
Alvina Waseem
J.C. Jones
Dana Keeler
Matthew Finkel
Mike de Boer
Martin Stransky
Nicholas Nethercote
Andreea Pavel
Alex Gaynor
David Major
Cosmin Sabou
Gabriele Svelto
Jan Henning
Ciure Andrei