The importance of glibc makes it worthwhile to provide debug
symbols. However, this revealed an issue with separateDebugInfo: it
was indiscriminately adding --build-id to all ld invocations, while in
fact it should only do that for final links. Glibc also uses non-final
("relocatable") links, leading to subsequent failure to apply a build
ID ("Cannot create .note.gnu.build-id section, --build-id
ignored"). So now ld-wrapper.sh only passes --build-id for final
links.
The glibc DNS client side resolver is vulnerable to a stack-based buffer
overflow when the getaddrinfo() library function is used. Software using
this function may be exploited with attacker-controlled domain names,
attacker-controlled DNS servers, or through a man-in-the-middle attack.
https://googleonlinesecurity.blogspot.co.uk/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
Fixes CVE-2014-8121, CVE-2015-1781 and two unnumbered problems (apparently).
All these commits should be contained in the 2.22 release,
but we don't want that yet due to unresolved locale incompatibilites.
Until now, if e.g. the user passed "en_US.UTF-8" instead of "en_US.UTF-8/UTF-8",
the locales would be generated without failing but wouldn't work well.
Now we guard against such mistakes. Real life examples:
https://github.com/fish-shell/fish-shell/issues/1927
It used to be a symlink, but now it is a link script. It's crucial to get
proper linking, specially on amrv5tel, where libgcc contains lot of code
related to the limited instruction set of the platform.
Without this fix, g++ shared lib linking was broken, because a "-lgcc" was
not propagated wherever "-lgcc_s" was required. The g++ spec only mentions
"-lgcc_s" and the "-lgcc" is introduced with the libgcc_s.so link script,
only available in the glibc path after this fix.
As a reminder, we put libgcc* in the glibc output to avoid having a
runtime dependency on the gcc path only because of the everywhere linked
libgcc. This problem was specially visible in platforms like armv5tel,
where most programs end up linked to libgcc. Platforms with a more rich
instruction set may rarely end up requiring a link to libgcc.
Now development stuff is propagated from the first output,
and userEnvPkgs from the one with binaries.
Also don't move *.la files (yet). It causes problems, and they're small.
- there were many easy merge conflicts
- cc-wrapper needed nontrivial changes
Many other problems might've been created by interaction of the branches,
but stdenv and a few other packages build fine now.
This prevents failures like "libgcc_s.so.1 must be installed for
pthread_cancel to work" that occur because Glibc assumes libgcc_s.so.1
to be in Glibc's libdir.
This solution is pretty hacky, because the libgcc_s.so.1 from
bootstrap-tools might be too old. So if we update GCC, programs might
end up using an outdated libgcc_s.so.1. Ideally, we would build
libgcc_s.so.1 *before* Glibc, which might not be impossible...
Fixes#3548.
I don't know why they feel they need to check the compatibility by build date,
so I would keep check against $out, which is a better nix equivalent.
Also, expression refactoring (put comments out of hash-changing bash).
