I removed cortex it is rather unmaintained. The last update (as of
writing) was 8 months ago, there was no release ever.
For a better alternative, have a look at `rtv`.
See previous commit for what was done to `binutils` to make this
possible.
There were some uses of `forcedNativePackages` added. The
combination of overrides with that attribute is highly spooky: it's
often important that if an overridden package comes from it, the
replaced arguments for that package come from it. Long term this
package set and all the spookiness should be gone and irrelevant:
"Move along, nothing to see here!"
No hashes should be changed with this commit
Use `buildPackages.binutils` to get build = host != target binutils,
i.e. the old `binutilsCross`, and use
`buildPackages.buildPackages.binutils` to get build = host = target
binutils, i.e. the old `binutils`.
`buildPackages` chains like this are supposed to remove the need for
all such `*Cross` derivations. We start with binutils because it's
comparatively easy.
No hashes of cross-tests should be changed
stdenv.cross is a silly attribute that needs to go leaving the well-defined hostPlatform and targetPlatform. This PR doesn't remove it, but changes its definition: before it tracked the target platform which is sometimes more useful for compilers, and now it tracks the host platform which is more useful for everything else. Most usages are libraries, falling in the "everything else" category, so changing the definition makes sense to appease the majority. The few compiler (gcc in particular) uses that exist I remove to use targetPlatform --- preserving correctness and becoming more explicit in the process.
I would also update the documentation aside mentioning stdenv.cross as deprecated, but the definition given actually erroneously assumes this PR is already merged!
The previous commit redefines `stdenv.cross` for the sake of normal
libaries, the most common use-case of that attribute. Some compilers
however relied on the old definition so we have them use
`targetPlatform` instead. This special casing is fine because we
eventually want to remove `stdenv.cross` and use either `hostPlatform`
or `targetPlatform` instead.
- `ccWrapperFun` can be used in a few more places instead of
duplicating its definition.
- `ccWrapper` parameter on `wrapCC` is always substituted with
`ccWrapperFun` so just get rid of that parameter.
3.14 is no longer supported upstream by kernel.org and thus no longer
receives security patches. The git commit mentioned in this .nix isn't
even available in the linked repository --
https://chromium.googlesource.com/chromiumos/third_party/kernel -- so I
think this .nix might be dead anyway. Finally, it specifies 3.14.0,
which is so ridiculously old (the latest was 3.14.79) that nobody
develops for it.
Fixes: #25145
Supports: #25127
This basically does something similar than the AUR build:
https://aur.archlinux.org/packages/vlc-qt5/
On our side, all there is to do is to force compiling using C++11 mode
and use a patch that the AUR package took from the following upstream
patchwork URL:
https://patches.videolan.org/patch/14061/
Instead of passing CXXFLAGS to the configure script, I'm using sed here
to make sure we don't override flags figured out by configure.
For example if ./configure is used with CXXFLAGS=-std=c++11 appended or
prepended, we have something like:
... -I../include -std=c++11 -Wall -Wextra -Wsign-compare ...
While if we don't do that at all, we have something like:
... -I../include -g -O2 -Wall -Wextra -Wsign-compare ...
Another way would be to use NIX_CFLAGS_COMPILE, but that would affect
even compilation of C code and thus resulting in a bunch of warnings
like this:
cc1: warning: command line option '-std=c++11' is valid for C++/ObjC++
but not for C
So with our approach the flags during build look much better:
... -I../include -std=c++11 -g -O2 -Wall -Wextra -Wsign-compare ...
Another thing I've changed is that the vlc_qt5 attribute in
all-packages.nix now uses the latest Qt 5 version, because the build for
Qt >= 5.7.0 is now no longer broken.
I've also ordered the preConfigure attribute before the configureFlags
attribute, because it makes more sense in terms of context (pre ->
configure -> post).
Tested by building on x86_64-linux with libsForQt56.vlc, libsForQt58.vlc
and vlc (the Qt 4 version, just to be sure I didn't accidentally break
it).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @ttuegel
