Граф коммитов

6 Коммитов

Автор SHA1 Сообщение Дата
Nick Alexander d56eb2a314 Bug 1489443 - Set GCC_USE_GNU_LD based on linker kind. r=froydnj
The desired outcome of this change is that we'll set
-Wl,--version-script based on linker kind and not on the output of
$LINKER -v.

This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system ld is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system ld doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system ld.

The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.

MinGW suffers somewhat from the opposite problem: the linker "is GNU
ld" (compatible), but the linker checks don't happen at all. We hard-code
for MinGW based on the C compiler instead.

Differential Revision: https://phabricator.services.mozilla.com/D8471

--HG--
extra : moz-landing-system : lando
2018-10-17 19:46:03 +00:00
Cosmin Sabou 9b6a537ec7 Backed out changeset 91300d29898b (bug 1489443) for MinGW build bustages. CLOSED TREE 2018-10-13 02:17:15 +03:00
Nick Alexander 3c83541616 Bug 1489443 - Set GCC_USE_GNU_LD based on linker kind. r=froydnj
The desired outcome of this change is that we'll set
`-Wl,--version-script` based on linker kind and not on the output of
`$LINKER -v`.

This is a cheap way to address a simple problem that has a complicated
ideal solution.  The underlying issue is that in some situations, when
targeting Android, a macOS system `ld` is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation.  The macOS system `ld` doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system `ld`.

The ideal solution is to test for linker capabilities dynamically.  We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure.  Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.

Differential Revision: https://phabricator.services.mozilla.com/D8471

--HG--
extra : moz-landing-system : lando
2018-10-12 22:38:44 +00:00
Tom Ritter 9d75725eb8 Bug 1350362 Fix NSS Build System for MinGW r=ted
MozReview-Commit-ID: 4QROlna5Cvg

--HG--
extra : rebase_source : a13c7080a6ee445bf3d10248305a6eb88405c173
2017-05-12 11:39:00 -05:00
Jan Beich 225a0afb78 Bug 1320690 - Re-enable bundled NSS on BSDs. r=ted
MozReview-Commit-ID: F9k21fzoZaT

--HG--
extra : rebase_source : d0f4ddf93ec82e6a4ec9406a9e0af85862d1dc36
2016-11-28 14:33:36 +00:00
Ted Mielczarek a449823a50 bug 1295937 - build NSS using gyp files. r=glandium
MozReview-Commit-ID: Gm1PLWSJwbD

--HG--
rename : config/external/nss/moz.build => security/moz.build
rename : config/external/nss/nss.symbols => security/nss.symbols
extra : rebase_source : bedd3b2f315f8504e1d0cb1ee94720e380466e5b
2016-11-09 12:37:09 -05:00