Ignore errors due to strict-overflow warnings; strip clang-only flag on
non-clang builds. Concerning the latter "fix", it's not entirely clear to me why
the -Wno-format-pedantic flag ends up being passed to gcc, the .gyp file appears
to already condition the inclusion of this flag on whether cc=clang.
(cherry picked from commit 72b5bfda97)
I think what's happening is that the linker automatically adds DT_NEEDED dependencies to some libraries because it finds these libraries are being used directly, but
because they're not linked explicitly with -lflags, the gcc wrapper does not add them to RUNPATH.
vcunat's review:
- let's not switch the default versions of llvm* for now
- the only changes I see is adding python to clang's buildInputs
and using the big so-file as discussed in #12759
(BUILD_SHARED_LIBS -> LLVM_LINK_LLVM_DYLIB)
- in future it will be nice to split libLLVM into a separate output
(cherry picked from commit f5fe051c71)
I originally wanted to do this a long time (a31301d) but IIRC back then
it didn't compile. Nowadays with the splitup of the gold linking flags
and the binutils integration, it's merely just a switch to flip, so
let's do that.
Only tested it by building against the current Chromium stable version
on 64bit, because right now builds on Hydra seem to time out (because of
this?) anyway so we have nothing to lose here.
The linking time was hereby reduced from >30 minutes (I didn't measure
it exactly but looked half an hour later to the build progress and it
was *still* linking) to about a few seconds, which I guess is even
though the measurement is quite bogus a tremendous improvement
nonetheless.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit f9fff51c2a)
First, The patch is outdated, I failed to find it anywhere in the mirror repos.
Second, the build fails, and while it may be "fixed" by ad-hoc patching (it
appears to simply need some missing includes), this would mean shipping a
potentially insecure software package. Given that the only reason to use
grsecurity is security, this is both misleading and exposes users to undue risk.
Finally, the build has been broken for quite a long time with no complaints,
leading me to believe that the number of actual users is quite low.
(cherry picked from commit dd16dcbba4)
Signed-off-by: Domen Kožar <domen@dev.si>
On linux 3.14, we get errors like
error: 'struct snd_soc_codec' has no member named 'name'
__string( name, codec->CODEC_NAME_FIELD )
indicating that the module is incompatible with the linux API
in this kernel version.
See https://hydra.nixos.org/build/33102405/nixlog/1/raw
(cherry picked from commit a452b43ee5)
Signed-off-by: Domen Kožar <domen@dev.si>
Fixes#13240. It's not really better than source-code comments it replaced,
but it's in a better accessible place.
(cherry picked from commit e3da83297f)
I noticed that almost all the Hydra build failures were on i686. Sure
enough, upstream says that you need an x86_64 machine to build the
kernel.
(cherry picked from commit bd9737cc3e)
All hydra builds against grsec kernels fail; seemingly because
the PaX hardening plugins are incompatible with lttng-modules
(the code writes to locations marked as read-only).
(cherry picked from commit 1939256550)
Sandboxed builds against linux 3.14 and 4.4 fail; 3.18.29 and 4.3
succeed. From this, I conclude that 4.3 is the latest supported
version, while the lower bound is set to the oldest kernel in
nixpkgs >3.14 (the changelog does not indicate otherwise).
It appears that openafs-client is simply incompatible with grsec;
all hydra builds of openafs-client on grsec fail; local sandboxed
builds against grsec with the most recent openafs-client also fail.
(cherry picked from commit b741198116)
