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.
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.
- HAVE_RANDOM is not checked at all.
- HAVE_STRERROR is not checked in code built using the defines from the main
configure.
- HAVE_LCHOWN is only checked in nsinstall.c, which means the test is also wrong
since it's checking for the target instead of the host. Also, lchown is only
used of the -o and -g options of nsinstall, which, as far as I know, we don't
use (and if we were, that would fail with nsinstall.py, which explicitly rejects
them).
- HAVE_FCHMOD is only checked in nsinstall.c, so same as above about the
correctness of the check. If it's not available, nsinstall.c falls back to
chmod, which is fine enough for our use.
- HAVE_SNPRINTF is not checked.
- HAVE_MEMMOVE is checked in parser/expat/lib/xmlparse.c, but it's also
unconditionally defined in expat_config.h which is included from that file.
- HAVE_SETBUF is checked in a couple files, but setbuf is C89 and C99, I think
it's safe to assume all compilers we support are C89 and C99. Interestingly,
windows does have it, but since we skip this check on windows, we don't use it.
- HAVE_ISATTY, same as HAVE_SETBUF, except it's POSIX instead of C89/C99.
- HAVE_FLOCKFILE is not checked at all.
- HAVE_STRTOK_R is not checked.
- HAVE_FT_SELECT_SIZE is not checked.
- HAVE_DLADDR is not checked under js/src.
- HAVE_GETPAGESIZE is not checked under js/src (it is in libffi, but ffi uses
its own configure)
- HAVE_LSTAT64, HAVE_STAT64, HAVE_STATVFS, HAVE_STATVFS64, HAVE_TRUNCATE64 are
not checked under js/src.
- HAVE_SBRK is not checked under js/src. Moreover,
js/src/assembler/wtf/Platform.h defines it depending on the platform.
- HAVE_SNPRINTF is not checked under js/src.
- HAVE_HYPOT is not checked under js/src.
- HAVE__UNWIND_BACKTRACE is not checked under js/src.
With this patch, I've confirmed that we instantiate the SafeJSContext much later
in startup, during nsAppStartupNotifier::Observe (which ends up invoking an
XPCWrappedJS). As such, this should solve a number of our startup ordering woes.
The JS engine fires this callback when the request count drops to zero, and we
use it determine when we should hibernate the watchdog thread. But since the
request count never drops to zero for nested event loops, the watchdog never
runs in those cases. And since our xpcshell harness runs tests in a nested event
loop, this means we can't test watchdog hibernation from xpcshell. And we don't
want to test it in mochitests, because the non-determinism of timer CCs and GCs
are likely to be problematic.
Really, we should consider finding a way to integrate nested event loops into
the activity callback mechanism, and should probably get a bug on file. But such
a task is out of scope for this bug, so we just add a way to fake it.
