mirror of
https://github.com/mozilla/gecko-dev.git
synced 2025-03-04 07:40:42 +00:00

In some cases, we can end up linking some things with --static-libstdc++. The notable (only?) example of that is for the clang-plugin, and that happens because it gets some of its flags from llvm-config, which contains --static-libstdc++ because clang itself is built that way. When that happens, the combination of --static-libstdc++ and stdc++compat breaks the build because they have conflicting symbols, which is very much by design. There are two ways out of this: - avoiding either -static-libstdc++ or stdc++compat - work around the symbol conflicts The former is not totally reliable ; we'd have to accurately determine if we're in a potentially conflicting case, and remove one of the two in that case, and while we can do that for the cases we explicitly know about, that's not future-proof, and might fail just as much in the future. So we go with the latter. The way we do this is by defining all the std++compat symbols weak, such that at link time, they're overridden by any symbol with the same name. When building with -static-libstdc++, libstdc++.a provides those symbols so the linker eliminates the weak ones. When not building with -static-libstdc++, the linker keeps the symbols from stdc++compat. That last assertion is validated by the long-standing CHECK_STDCXX test that we run when linking shared libraries and programs. That still leaves the symbols weak in the final shared libraries/programs, which is a change from the current setup, but shouldn't cause problems because when using versions of libstdc++.so that do provide those symbols, it's fine to use the libstdc++.so version anyways.
…
…
servo: Merge #17922 - stylo: Support layout.css.prefixes.device-pixel-ratio-webkit pref (from upsuper:wk-dpr); r=heycam
…
…
…
…
…
An explanation of the Mozilla Source Code Directory Structure and links to project pages with documentation can be found at: https://developer.mozilla.org/en/Mozilla_Source_Code_Directory_Structure For information on how to build Mozilla from the source code, see: https://developer.mozilla.org/en/docs/Build_Documentation To have your bug fix / feature added to Mozilla, you should create a patch and submit it to Bugzilla (https://bugzilla.mozilla.org). Instructions are at: https://developer.mozilla.org/en/docs/Creating_a_patch https://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree If you have a question about developing Mozilla, and can't find the solution on https://developer.mozilla.org, you can try asking your question in a mozilla.* Usenet group, or on IRC at irc.mozilla.org. [The Mozilla news groups are accessible on Google Groups, or news.mozilla.org with a NNTP reader.] You can download nightly development builds from the Mozilla FTP server. Keep in mind that nightly builds, which are used by Mozilla developers for testing, may be buggy. Firefox nightlies, for example, can be found at: https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/ - or - https://nightly.mozilla.org/
Description
Read-only Git mirror of the Mercurial gecko repositories at https://hg.mozilla.org. How to contribute: https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
Languages
JavaScript
32.3%
C++
25.4%
HTML
21.1%
C
10.8%
Python
2.8%
Other
7.1%