New answers tagged

2

efivar version 0.23 needs a patch to work with kernel headers from 4.4 (and later kernels), because the header defining NVME_IOCTL_ID changed (it was renamed from nvme.h to nvme_ioctl.h). To build efivar on your system, you'll need the "Workaround rename of linux/nvme.h" patch. To apply that, go into the directory containing the efivar source code (with the ...


1

I would suggest that any decent not-so-modern x86_64 true server should be able do a full build in a couple of hours or maybe less, including xsrc. My NetBSD-current build server is a Xen domU with 8GB RAM and 8 VCPUs running on a Dell PE2950 8-core (Xeon E5440 @2.83GHz) with 32GB RAM and with a decently fast set of SAS disks on the integrated PERC 6/i ...


0

Simple: run a representative test while running old kernel and while running custom kernel and compare the results. The key here is "representative": different workloads will have different performance requirements and may work better or worse on different kernel settings. Your custom-compiled kernel may improve performance for some apps while hurting ...


1

If you need a newer kernel, elrepo might be helpful and save you the grief: http://elrepo.org/tiki/tiki-index.php http://elrepo.org/linux/kernel/el6/ Don't expect it to necessarily be flawless. I tried one of the newer kernels on a CentOS 5 machine recently, for some reason the NFS server would not start. I ended up digging-in and rebuilt that server in ...


2

Assuming you're running x86_64 (amd64) architecture, don't expect a huge difference in performance. This architecture gave things a new baseline for processor features (as compared to 32-bit code possibly going back to i386). Also, in the 32-bit world kernels and C libraries have already been compiled for different minimum architectures (i586, i686, ...). ...


0

Here's a community wiki to collect other distros' equivalent tools for Faheem's method. Feel free to edit, but keep the sort alphabetical for searching. Arch Use pkgfile from the extra repository, passing the header file name as a parameter. Example: $ pkgfile XInput.h extra/libxi extra/nx-headers Debian (and anything Debian-based using dpkg) ...


2

It takes roughly a day for me to build 5 or so different architectures, as complete release builds (aka, tarballs and ISO images.) I'm building on a relatively low memory (512M), i386 virtual machine, using a script that also checks out the sources, and does a bunch of setup around build.sh. If you have more than one processor/core, you can speed things up ...


4

The question is how to determine what linker flag to use from inspection of the source file. The example below will work for Debian. The header files are the relevant items to note here. So, suppose one has a C source file containing the header #include <X11/extensions/XInput.h>. We can do a search for XInput.h using, say apt-file. If you know this ...


2

Maybe it will take more than 90 min to build the kernel . To speed up the compilation process we need to use -j option for example if you have 2 core you can type: fakeroot make-kpkg..... -j 2 or make -j 2 you can speed up the compilation process X2 ( 45 min) , (8 core less than 10min) Also you can use the CONCURRENCY_LEVEL variable for example if ...


2

If you're repeatedly building the kernel on the same machine, ccache can help a lot, especially if you're using a VM. In my experience, successive clean builds of the same project on a VM will build in about half the time as a build that didn't use ccache. You will need some extra disk space, to store the object files saved from the first build. Also the ...


5

The following instructions apply to building a kernel from upstream. Personally I find that simplest. I don't know how to obtain a tree with the ubuntu patches applied, ready to build like this. (1) Theoretically the way you build kernels in more reasonable timespans for testing is supposed to be cp /boot/config-`uname -r` .config you don't need to ...


0

Recycling the environment would seem to be the culprit, which indicates to me that a specific environment setting/variable/configuration is not being retained in the event of a system halt. Provided I don't halt the host, I can compile the entire toolchain with the chain's make without errors.


2

Actually here two things are there to care about: Is the running kernel version is same are of the source we are using. As previously compiled kernel may not be having all the dependencies which may be used in latest version, while compilation of external module with latest kernel source may be dependent on any part of the code, which is only present in ...


1

I've found the problem(s): as Munir staded, I had sh pointing to dash instead of bash; after that, gcc failed to compile because of the missing rpc/xdr.h header; this was fixed by rebuilding the glibc by adding the flag: --enable-obsolete-rpc; All is fine now.


4

The compiler flags used are a function of the debian/rules file, the package's build files (since the upstream author may specify flags there too), the build system used (dh, cdbs etc.), the default compiler settings. To see the flags used you effectively need to at least compile the package: debian/rules build Trying things like debian/rules -n ...



Top 50 recent answers are included