This reverts commit c778945806.
I believe this is exactly what brings the staging branch into
the right shape after the last merge from master (through staging-next);
otherwise part of staging changes would be lost
(due to being already reachable from master but reverted).
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
(cherry picked from commit ba52ae5048)
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
The icu4c cross-build process requires access to a full buildRoot of a
native build, so we add a variant of the build that just does the
buildPhase and copies the buildRoot to $out for access by the cross
compile.
Firefox requires new version of the icu to build:
```
checking for icu-i18n >= 58.1... Requested 'icu-i18n >= 58.1' but version of icu-i18n is 57.1
configure: error: Library requirements (icu-i18n >= 58.1) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.
```
Only zoom-us depends on icu4c-54.1. Since we know that version has some vulnerabilities, and zoom-us appears to work with icu4c-57.1, I remove the icu/54.1.nix file, remove icu_54_1 from all-packages.nix, and have zoom-us depend on icu (i.e., icu4c-57.1)
This reverts commit d393c6c538.
The commit removed C++11 compatibility on darwin by overriding the
--std=c++0x flag in CXXFLAGS. Which lead to a failing build of mapnik,
which depends on the move constructors being available in the icu-lib.
Since it builds fine without the headerpad_max_install_names flag, we
simply undo the change that introduced this flag.
Mario Rodas