Hot answers tagged

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 ...


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 ...


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

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, ...). ...


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 ...


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 ...


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 ...


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

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 ...


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 ...


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 ...


1

That double-slash in the pathname looks odd. Perhaps you have no permission to write the ${BASE}, which might be /files/ondisk/shared. The umask value is irrelevant, because it only affects the permissions of the directories and files which mkdir and cp create — not the permissions of the existing directory into which you are copying.


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.



Only top voted, non community-wiki answers of a minimum length are eligible