2017-06-15 06:06:45 +00:00
|
|
|
ac_add_options --disable-compile-environment
|
|
|
|
|
|
2017-07-20 02:07:53 +00:00
|
|
|
# In case mozconfig.cache was already included
|
|
|
|
|
unset CCACHE
|
2017-07-27 05:02:39 +00:00
|
|
|
unset SCCACHE_VERBOSE_STATS
|
2017-07-20 02:07:53 +00:00
|
|
|
# In case it wasn't
|
|
|
|
|
NO_CACHE=1
|
|
|
|
|
|
2017-06-15 06:06:45 +00:00
|
|
|
# Override any toolchain defines we've inherited from other mozconfigs.
|
|
|
|
|
unset CC
|
|
|
|
|
unset CXX
|
2024-07-17 23:45:25 +00:00
|
|
|
unset CPPFLAGS
|
|
|
|
|
unset CFLAGS
|
|
|
|
|
unset CXXFLAGS
|
|
|
|
|
unset LDFLAGS
|
2017-06-15 06:06:45 +00:00
|
|
|
unset HOST_CC
|
|
|
|
|
unset HOST_CXX
|
2024-07-03 19:50:07 +00:00
|
|
|
unset HOST_CPPFLAGS
|
2024-07-03 19:50:05 +00:00
|
|
|
unset HOST_CFLAGS
|
2024-07-03 19:50:05 +00:00
|
|
|
unset HOST_CXXFLAGS
|
2024-07-03 19:50:06 +00:00
|
|
|
unset HOST_LDFLAGS
|
2018-05-29 19:37:49 +00:00
|
|
|
unset LINKER
|
2019-04-12 22:47:52 +00:00
|
|
|
unset RUSTFLAGS
|
2017-06-15 06:06:45 +00:00
|
|
|
unset TOOLCHAIN_PREFIX
|
2017-07-11 20:39:08 +00:00
|
|
|
unset BINDGEN_CFLAGS
|
2018-08-24 13:16:28 +00:00
|
|
|
unset ENABLE_CLANG_PLUGIN
|
2018-12-20 18:50:04 +00:00
|
|
|
unset MACOS_SDK_DIR
|
|
|
|
|
unset MACOS_PRIVATE_FRAMEWORKS_DIR
|
2022-12-28 22:48:51 +00:00
|
|
|
unset WINSYSROOT
|
2019-03-06 22:47:08 +00:00
|
|
|
unset MOZ_LTO
|
2017-12-21 02:13:08 +00:00
|
|
|
|
|
|
|
|
unset MOZ_STDCXX_COMPAT
|
Bug 1079662 - Always enable PIE. r=froydnj
Last attempt, a few years ago, blatantly failed because nautilus (the
GNOME file manager) can't start PIE executables, which look like shared
libraries, and that it thus considers not being executables.
Downstreams don't actually have the problem, because users won't be
launching Firefox from a file manager, but for mozilla.org builds, it is
a problem because users would download, then extract, and then likely
try to run the Firefox executable from a file manager.
So for mozilla.org builds, we still need to find a way around the
nautilus problem.
A .desktop file could be a solution, but .desktop files have not
actually been designed for this use case, which leads to:
- having to use an awful one-liner shell wrapper to derive the path
to the executable from that of the .desktop file,
- not even being able to associate an icon,
- the .desktop file not being copiable to a location where .desktop
files would normally go, because it would then fail to find the
executable.
Another possibility is to go back to using a shell wrapper, but that's
not entirely appealing.
What we chose here is similar, where we have a small `firefox` wrapper
that launches the real `firefox-bin` (which is still leftover from those
old times where we had a shell wrapper, for reasons).
The small `firefox` wrapper is a minimalist C executable that just
finds the path to the `firefox-bin` executable and executes it with the
same args it was called with. The wrapper is only enabled when the
MOZ_NO_PIE_COMPAT environment variable is set, which we only take into
account on Linux. The variable is only really meant to be used for
mozilla.org builds, for the nautilus problem. Downstreams will just pick
the default, which is changed to build PIE.
On other platforms, PIE was already enabled by default, so we just
remove the --enable-pie configure flag.
Differential Revision: https://phabricator.services.mozilla.com/D5109
2018-09-06 04:27:49 +00:00
|
|
|
unset MOZ_NO_PIE_COMPAT
|
2019-01-05 14:34:01 +00:00
|
|
|
|
2020-01-10 19:56:56 +00:00
|
|
|
# Don't unset this on Linux artifact builds so the artifact builds correctly
|
2020-04-22 11:16:10 +00:00
|
|
|
# package any Wasm sandboxed shared libraries.
|
2020-01-10 19:56:56 +00:00
|
|
|
if test `uname -s` != Linux; then
|
|
|
|
|
unset WASM_SANDBOXED_LIBRARIES
|
|
|
|
|
fi
|