Similarly to the considerations about glibc, the Linux compatibility matrix
(https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix)
tells us no distro with Gtk+3 3.4 has a version of libstdc++ older than
4.6.
The data in the matrix doesn't go to that level of detail, but Ubuntu
12.04 LTS, being the only one with version 4.6 (others have at least
4.7), it's worth noting it has version 4.6.3. Which means we can safely
require libstdc++ symbols version 3.4.16 (which were added in 4.6.1).
This will allow us to remove a lot of the stdc++ compatibility hacks.
The requirement for glibc has been set to version 2.7 for a long while.
Spidermonkey uses the pthread_setname_np symbol, which is only available
since glibc 2.12. So far, we've been fortunate that the symbol doesn't
end up in libxul, or tests that link to js directly, because the symbol
is eliminated as being called by effectively dead code.
There are multiple reasons why this is going to change, one of which
being changes to the way things are linked, that will make the linker
not eliminate that code in some cases. Another is that eventually, the
separation of build systems between js and top-level is going to fade,
and the glibc checks, which apply to all gecko binaries, will also apply
to js binaries. They currently are not happening, and would fail because
of pthread_setname_np if they were.
Taking a step back, as of version 46, the mozilla.org builds require at
least Gtk+3 3.4. Which means the requirements for the underlying system
have received a dramatic bump, and it's time to revisit the requirements
for binary compatibility.
I went through all my notes from all the recent times binary compatibility
has been considered, and put together a compatibility matrix on MDN from
that data as well as more recent data that I could find here and there,
about the major non-rolling-release distros (RHEL, Fedora, SuSE, Debian,
Ubuntu)
https://developer.mozilla.org/en-US/Firefox/Linux_compatibility_matrix
Considering the data there, none of the distros that have at least Gtk+3
3.4 have a glibc older than 2.13. The list of symbols that 2.13 provides
that 2.12 doesn't have is not large enough, though, to really care about
depending on 2.13.
They were behind WANT_MOZILLA_CONFIG_OS_VERSION, which nothing has been
setting ever since the ifdef was changed from
MOZILLA_CONFIG_IGNORE_OS_VERSION... in 2000. Not that anything was
setting MOZILLA_CONFIG_IGNORE_OS_VERSION either... well, at least not in
Gecko.
We can just generate xpidllex.py/xpidlyacc.py in the current directory
rather than one directory higher, and specify this directory as an
include path to xpidl-process.py
MozReview-Commit-ID: KLoGjudc4Y8
--HG--
extra : rebase_source : 8dda268c6490cdfb8b896de9da5b789208584193
-Zi is already set through MOZ_DEBUG_FLAGS, which is set from
--enable-debug-symbols, which is the default, and if someone goes all
the way to explicitly disable them, we might as well not silently
override their decision.
-Od disables optimization, and the given reason was for sane stack
traces, but the fact is we're currently building debug builds, which
have been optimized by default for a while, and are the only ones with
DMD enabled by default, without overriding with -Od and are apparently
happy with it.
-DNDEBUG is already set through MOZ_DEBUG_DEFINES, and -UDEBUG is not
doing anything useful, since nothing is setting DEBUG on the command
line, nor does the compiler by default.
The flag is used to create .sbr files, which bscmake subsequently uses to
create .bsc files. These files and related tools are, aiui, the ancestors
of Intellisense.
The -FR C*FLAGS are added to the build if MOZ_BROWSE_INFO or MOZ_BSCFILE
are set in the recursive make backend. While the former has an AC_SUBST,
the latter does not, so in practice, only the former can be set by
supported methods, and would need to be set in a mozconfig. At that
rate, people who do want those flags can add them in the C*FLAGS on
their own.
Developers are probably better served by the VisualStudio backend
anyways.
We don't really care to set those in js/src/configure because the JS
engine doesn't use ObjC. We also don't care to preserve the += behavior
because there were no AC_SUBST in the first place, so it's unlikely
anyone has an override in their mozconfig and expects it to work.
Limit ourselves to include paths for now, because there are tricky things
involved in making this globally.
While here, use shell_quote instead of manual quoting for those paths.
This might seem like going in the opposite direction of what we tend to do
to move to moz.build land, but those flags are irrelevant in many situations
and are better separated out.
MOZ_DEBUG_DEFINES are essentially defines used everywhere. So treat them as
feeding the initial value for DEFINES in each moz.build sandbox. This allows
the kind overrides that was done in the past by resetting MOZ_DEBUG_DEFINES
in Makefiles.
This patch moves the logic for selecting MOZ_WINCONSOLE out of individual
Makefile.in files and into configure. It also changes config.mk to only
pass -SUBSYSTEM:CONSOLE if MOZ_WINCONSOLE=1. The MSDN docs state that
in the absence of -SUBSYSTEM, the linker will select the proper subsystem
based on whether the program contains [w]main or [w]WinMain, so let it
do that.
One program (windbgdlg) needed a tweak to add a wmain for when MOZ_WINCONSOLE
is defined.
This patch leaves one instance in security/sandbox/win/wow_helper/Makefile.in,
that Makefile has its own separate bug.
--HG--
extra : commitid : 8acDjmfKivj
extra : rebase_source : 03b4fa4c8ae077a894b08f3762ef93541e34ac1a
The configure option has explicitly thrown an error for more than a year now,
and it happens that the remaining way to still forcefully use it has been
broken for more than 8 months.
The flags added in toolkit/locales/Makefile.in turn out not to be actually
used, so just remove that.
The remaining uses of XULPPFLAGS are to set debug flags depending on whether
MOZ_DEBUG is set or not. Just set a dedicated variable with the right value
from configure.
At the same time, make the test for libstdc++ more comprehensible.
--HG--
extra : commitid : FY4SOJob69k
extra : rebase_source : 15778a2080423666edeae78adb7a5b80925f6871
Its only purpose is to disable PGO. Where that was not already explicitly done,
or irrelevant (because the directory only contains python), I disabled it in
moz.build.
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
Optimised Rust compilation is enabled on passing --enable-optimize to
the configure script. This sets the RUSTFLAGS output variable that gets
picked up by the compile targets RSOBJS and RSSRCS and passed to rustc.
r=glandium
--HG--
extra : commitid : 8thSkfLFXSY
extra : rebase_source : 5ec79b76a187bcbb0f09ad374cf9f763f0adb0d7
These definitions appear to have been added to support generating Java
interfaces from xpidl interface files. Since we don't support doing
that anymore, we don't need these definitions, either.
See the revisions a few steps prior for more fine-grained information. This just
needs to be relanded because our automation doesn't like non-ASCII commit
messages.
--HG--
extra : amend_source : 0ee4e0da1ea9ada815abfe989c51030db24aac56
CLOSED TREE
Backed out changeset 28abb8af2d62 (bug 1099430)
Backed out changeset 358aa39360d5 (bug 1099430)
Backed out changeset 3313e545f4f6 (bug 1099430)
With these substitutions, it is possible to have comm-central's versions of
these files merely include the mozilla-central versions and avoid having to port
small changes to these files.
win_srcdir is used as the Windows path for the srcdir, and so it needs to use
comm-central's topsrcdir to work properly. In contrast, WIN_TOP_SRC is really
only used to define BUILD_TOOLS, which refers to files in mozilla-central/build,
and so that can and should remain the mozilla-central topsrcdir.
This used to be necessary to avoid the conflicting names between import
libraries and static libraries, but that's now prevented by the whole
moz.build machinery.
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.
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.
As a first step, this moves PYTHON_UNIT_TESTS to moz.build as a passthru
variable. In the future, we could hook it up to |mach test|.
The __init__.py files may not need to be in the list, but I don't want to
change the list here.
OS_LIBS for libraries that are not part of the gecko tree, EXTRA_LIBS for
libraries, such as NSPR, that are in the tree, but are not handled by
moz.build just yet. Those EXTRA_LIBS may also come from a system library.
However, in cases where the expanded variables are always empty for the
in-tree case, OS_LIBS is used (as for, e.g. MOZ_ZLIB_LIBS). OS_LDFLAGS is
used exclusively for non-library linker flags.
Always pass EXTRA_LIBS before OS_LIBS on linker command lines.
Forbid EXTRA_DSO_LDOPTS, SHARED_LIBRARY_LIBS and LIBS in Makefiles.
It's just as easy to directly set the preprocessor macro in the moz.build
files. Using this variable doesn't really buy us anything.
This patch also removes unused code from rdf/tests/dsds.
Every directory with a jar.mn now has JAR_MANIFESTS defined in its
moz.build file.
We also removed the may_skip special consideration of jar.mn files
because this information is now available during tier traversal by the
reader courtesy of the variables being present in moz.build files.
--HG--
extra : rebase_source : 21049b15e6bd9cf65b0805ccaccc4ba5aae93c98
extra : amend_source : 0b1ea866d725beef92d37c6f6d475369ac002e19
This also moves the LIBXUL_LIBRARY implies FORCE_STATIC_LIB test in the emitter
instead of config.mk, since both variables are defined in moz.build exclusively.
backend.mk can end up with both LIBXUL_LIBRARY and FORCE_STATIC_LIB defined, but
it's just fine.
However, since we don't generate depfiles when compiling assembly, explicitly exclude those.
Also, fix a few issues with included depfiles:
- The tools tier need them because it (sadly) links binaries.
- depfiles for TARGETS use the full path, whereas the depfiles for OBJS and others don't.
Mike Hommey
Ralph Giles
Chris Manchester
Ted Mielczarek
Mike Shal
Ms2ger
Phil Ringnalda
David Major
Nicholas Nethercote
Nathan Froyd
Andreas Tolfsen
Ryan VanderMeulen
Brian O'Keefe
Axel Hecht
Joshua Cranmer
Ehsan Akhgari
Mukilan Thiyagarajan
Gregory Szorc
Brian R. Bondy
Wes Kocher
Jacek Caban
ABE Hiroki (hATrayflood)
Masatoshi Kimura
Catalin Iacob
Nick Alexander
Martin Stransky
Carsten "Tomcat" Book
Cykesiopka