зеркало из https://github.com/mozilla/gecko-dev.git
e0bbb4aa9e
Bug 1256642 introduced magic at the emitter level to determine whether a binary contains C++ sources and should be linked with the C compiler or the C++ compiler. Unfortunately, the Binary() moz.build template always adds C++ OS libraries on Android (through STLPORT_LIBS), and C++ libraries on Linux (stdc++compat). The latter only ends up forcing every Binary() to be linked with the C++ linker, which is unfortunate, but doesn't cause much problems. The former, however, involving OS libraries, the magic from bug 1256642 doesn't kick in, so we end up trying to link C++ OS libraries with the C linker. Which ends up failing, because the libraries in STLPORT_LIBS require -lm, which, while it's added by the C++ compiler when linking, is not when the linkage is driven by the C compiler. Because the fallible library, linked to all GeckoBinary()s is a C++ library, we still ended up linking with the C++ compiler on Android, so this wasn't actually causing any problem... until I tried to remove that fallible library in bug 1423803. Anyways, the core problem is that moz.build evaluation is happening too early to know whether any C++ sources are being linked together, so there is no way the Binary() template can do the right thing. So this change moves the logic to the emitter. This also changes the type of STLPORT_LIBS to a list. --HG-- extra : rebase_source : a70ddf7a132f94dc10e7e1db94ae80fb8d7a269f |
||
|---|---|---|
| .. | ||
| acwinpaths.m4 | ||
| alloc.m4 | ||
| altoptions.m4 | ||
| android.m4 | ||
| arch.m4 | ||
| clang-plugin.m4 | ||
| codeset.m4 | ||
| compiler-opts.m4 | ||
| config.guess | ||
| config.status.m4 | ||
| config.sub | ||
| expandlibs.m4 | ||
| frameptr.m4 | ||
| hooks.m4 | ||
| hotfixes.m4 | ||
| icu.m4 | ||
| install-sh | ||
| ios.m4 | ||
| lto.m4 | ||
| mozheader.m4 | ||
| mozprog.m4 | ||
| nspr-build.m4 | ||
| nspr.m4 | ||
| nss.m4 | ||
| pkg.m4 | ||
| sanitize.m4 | ||
| subconfigure.m4 | ||
| toolchain.m4 | ||
| zlib.m4 | ||