Enables previously manually disabled stackprotector and stackguard
randomization.
From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511811:
If glibc is built with the --enable-stackguard-randomization option,
each application gets a random canary value (at runtime) from /dev/urandom.
If --enable-stackguard-randomization is absent, applications get a static
canary value of "0xff0a0000". This is very unfortunate, because the
attacker may be able to bypass the stack protection mechanism, by placing
those 4 bytes in the canary word, before the actual canary check is
performed (for example in memcpy-based buffer overflows).
The following parameters are now available:
* hardeningDisable
To disable specific hardening flags
* hardeningEnable
To enable specific hardening flags
Only the cc-wrapper supports this right now, but these may be reused by
other wrappers, builders or setup hooks.
cc-wrapper supports the following flags:
* fortify
* stackprotector
* pie (disabled by default)
* pic
* strictoverflow
* format
* relro
* bindnow
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.
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.
- 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.
* Removed substitute, it's part of the generic builder now.
* stdenv-initial (Linux): use the real generic builder script. This
does require that sed is in the path of the builder of the initial
stdenv.
svn path=/nixpkgs/trunk/; revision=7498
* GCC 3.4.5.
* Updated several other stdenv packages.
* Modified the builders of several packages to use the generic
builder.
svn path=/nixpkgs/trunk/; revision=4336
this contains mostly Armijn's pure stdenv-linux.
* After unpacking the statically linked GCC, patch all store paths to
/nix/store/ffffffffffffffffffffffffffffffff. Ugly hack to prevent
undeclared references but it works.
* We don't need Glib's dynamic libraries in the first bootstrap stage;
delete them. Actually the downloaded Glibc binary is only needed
for building Glibc, since GCC needs a C compiler to build some
programs in `configure'. So static linking is fine for that. Maybe
it would be better to patch `configure' so that we don't need a
pre-built Glibc at all.
* Set the svn:executable property on `cp' and `patchelf'.
* In Glibc, revert to LinuxThreads. Maybe NPTL will work, but TLS
support is a problem.
* Delete most Glibc patches; they're no longer needed since the branch
updated it to 20050110.
* Some cleanups.
svn path=/nixpkgs/trunk/; revision=2258
supported locales. This is very useful as those are the default
locales on Red Hat and SuSE (>= 9.2). (When LANG is set to an
unsupported locale, some applications fall back on the C locale;
others (like Subversion) just barf.)
svn path=/nixpkgs/trunk/; revision=1977
* Make builders unexecutable by removing the hash-bang line and
execute permission.
* Convert calls to `derivation' to `mkDerivation'.
* Remove `system' and `stdenv' attributes from calls to
`mkDerivation'. These transformations were all done automatically,
so it is quite possible I broke stuff.
* Put the `mkDerivation' function in stdenv/generic.
svn path=/nixpkgs/trunk/; revision=874
builders for typical Autoconf-style to be much shorten, e.g.,
. $stdenv/setup
genericBuild
The generic builder does lots of stuff automatically:
- Unpacks source archives specified by $src or $srcs (it knows about
gzip, bzip2, tar, zip, and unpacked source trees).
- Determines the source tree.
- Applies patches specified by $patches.
- Fixes libtool not to search for libraries in /lib etc.
- Runs `configure'.
- Runs `make'.
- Runs `make install'.
- Strips debug information from static libraries.
- Writes nested log information (in the format accepted by
`log2xml').
There are also lots of hooks and variables to customise the generic
builder. See `stdenv/generic/docs.txt'.
* Adapted the base packages (i.e., the ones used by stdenv) to use the
generic builder.
* We now use `curl' instead of `wget' to download files in `fetchurl'.
* Neither `curl' nor `wget' are part of stdenv. We shouldn't
encourage people to download stuff in builders (impure!).
* Updated some packages.
* `buildinputs' is now `buildInputs' (but the old name also works).
* `findInputs' in the setup script now prevents inputs from being
processed multiple times (which could happen, e.g., if an input was
a propagated input of several other inputs; this caused the size
variables like $PATH to blow up exponentially in the worst case).
* Patched GNU Make to write nested log information in the format
accepted by `log2xml'. Also, prior to writing the build command,
Make now writes a line `building X' to indicate what is being
built. This is unfortunately often obscured by the gigantic tool
invocations in many Makefiles. The actual build commands are marked
`unimportant' so that they don't clutter pages generated by
`log2html'.
svn path=/nixpkgs/trunk/; revision=845
