Newer versions of perf in Linux 5.1+ support disassembling and
annotating eBPF programs inside the kernel. In order to do this, it uses
libbfd's support for bpf disassembly. There are two parts: libopcodes
and libbfd.
The 'perf' build system seems to expect libopcodes/libbfd to go "hand in
hand" -- always together, if one or the other is installed. If the build
system detects libbfd is available, then an import of <dis-asm.h> is
performed, but this fails since it wasn't in the buildInput. Fixing this
should be an easy, backwards-compatible change.
Fixes #60891, allowing linuxPackages_testing.perf to build again
(currently kernel version 5.1.0-rc7).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This makes the command ‘nix-env -qa -f. --arg config '{skipAliases =
true;}'’ work in Nixpkgs.
Misc...
- qtikz: use libsForQt5.callPackage
This ensures we get the right poppler.
- rewrites:
docbook5_xsl -> docbook_xsl_ns
docbook_xml_xslt -> docbook_xsl
diffpdf: fixup
Otherwise the build system computes incorrect references and looks for
perf-core in /libexec. DESTDIR for normal buildsystems is never the
right choice for nixpkgs.
In the long run it looks like we may actually need a small set of patches to
Perf if that's more maintainable, in which case we would much rather check
NIX_DEBUG_INFO_DIRS.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Certain tools, e.g. compilers, are customarily prefixed with the name of
their target platform so that multiple builds can be used at once
without clobbering each other on the PATH. I was using identifiers named
`prefix` for this purpose, but that conflicts with the standard use of
`prefix` to mean the directory where something is installed. To avoid
conflict and confusion, I renamed those to `targetPrefix`.
starting with linux 4.12 our patch no longer applied. In order to
avoid having to maintain patches for different linux kernels it is
easier to use a wrapper instead.
In 4.1, the build system changed, and it now wants to execute ld like this:
ld -r -o util/scripting-engines/libperf-in.o util/scripting-engines/trace-event-perl.o util/scripting-engines/trace-event-python.o
The actual problem seems to be that `buildInputs = [elfutils ...]`
causes 'ld' to point to elfutils in PATH instead of the usual binutils.
So remove elfutils from buildInputs and set NIX_CFLAGS_* manually. This
is a slight hack, but there is some precedent:
0761f81da7/pkgs/tools/package-management/rpm/default.nix (L13)
Fixes #9095.
Says: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
CC: #4803. There will likely appear more of these errors on Hydra in time.
In most cases, this just meant changing kernelDev (now removed from
linuxPackagesFor) to kernel.dev. Some packages needed more work (though
whether that was because of my changes or because they were already
broken, I'm not sure). Specifics:
* psmouse-alps builds on 3.4 but not 3.10, as noted in the comments that
were already there
* blcr builds on 3.4 but not 3.10, as noted in comments that were
already there
* open-iscsi, ati-drivers, wis-go7007, and openafsClient don't build on
3.4 or 3.10 on this branch or on master, so they're marked broken
* A version-specific kernelHeaders package was added
The following packages were removed:
* atheros/madwifi is superceded by official ath*k modules
* aufs is no longer used by any of our kernels
* broadcom-sta v6 (which was already packaged) replaces broadcom-sta
* exmap has not been updated since 2011 and doesn't build
* iscis-target has not been updated since 2010 and doesn't build
* iwlwifi is part of mainline now and doesn't build
* nivida-x11-legacy-96 hasn't been updated since 2008 and doesn't build
Everything not specifically mentioned above builds successfully on 3.10.
I haven't yet tested on 3.4, but will before opening a pull request.
Signed-off-by: Shea Levy <shea@shealevy.com>
First, pass in `self' again so that overriding works properly (thanks
for pointing that out, @edolstra)
Second, instead of having linuxPackages*.kernel mean something different
inside the set and out, add a new attribute linuxPackages*.kernelDev,
which for the generic kernel is simply linuxPackages*.kernel but for the
manual-config kernel is the `dev' output (which has the build tree,
source tree, etc.)
The second change required trivial modifications in a bunch of
expressions, I verified that all of the linuxPackages* sets defined in
all-packages.nix have the same drv paths before and after the change.
Signed-off-by: Shea Levy <shea@shealevy.com>
This is for consistency with terminology in stdenv (and the terms
"hostDrv" and "buildDrv" are not very intuitive, even if they're
consistent with GNU terminology).
