I’m experimenting with linux-kernel/net/ipv4/igmp.c. To compile I use buildroot. When I make a change on igmp.c, is a full rebuid necessary?
The easiest way to rebuild a single package from scratch is to remove its build directory in output/build. Buildroot will then re-extract, re-configure, re-compile and re-install this package from scratch. You can ask buildroot to do this with the make -dirclean command.
https://buildroot.org/downloads/manual/manual.html#rebuild-pkg
The documentation talks only about packages, but I think it doesn’t include changes on the kernel itself? How can I avoid a full rebuild?
Probably the simplest way to force a rebuild of the Linux package (or any other package) is to remove the .stamp_built file in the output/build/linux-version directory. After that just make again and it will be rebuilt and installed.
In my case :
rm output/build/linux-v4.19.253/.stamp_built
make
Linux is treated like any other package and you can rebuild it with:
$ make linux-rebuild
This is true for all packages.
-rebuild make recipe suffix means something like:
$ make all
in the build/linux/ package directory.
So if you change a file and issue that command only that file or its dependencies is built again.
Another useful recipe suffix is -menuconfig that is also available for u-boot (-rebuild too).
Related
I'm using ubuntu 18.04.
I want to modify and build a project and install it as a package. For example gstreamer1.5.
So I clone repo, modify code and use ./autogen.sh and make install in project folder. Why don't I see it in apt list then? Also there is no files in /usr/lib/x86_64-linux-gnu/gstreamer-1.5/.
The reason why I want it to behave as the original package is becase I want to build another project that uses it (kurento media server). So I just want to remove some plugins I don't need that use another packages as deps I cannot use.
apt list is from the Linux distribution. You custom made things won't appear there magically.
If you make install from your custom tree your libraries and plugins will land in /usr/local/lib/.. (note the local path). You may have some control over it by setting the prefix path. Just be careful you don't break you system by overwriting with broken libraries.
I am working to enable the kexec support in my propriety Linux distribution and I would like to debug the kexec tools in user space. I am adding debug prints in the kexec.c that's located in buildroot/output/build/kexec-2.0.15/kexec/kexec.c, but if I do an incremental build with make, it doesn't look like the kexec binary has been updated. If I rebuild everything from scratch with make all, the source code kexec.c has been overridden and I don't see my changes. My guess is that every full build re-extracts the kexec package and that is why my changes are not taking affect.
How do I solve this issue?
Try to use "make kexec-rebuild".
If you only want to restart the build process of a package from its
compilation step, you can run make <package>-rebuild [...]. It will restart the compilation and installation of
the package, but not from scratch: it basically re-executes make and
make install inside the package, so it will only rebuild files that
changed.
[...]
Internally, Buildroot creates so-called stamp files to keep track of
which build steps have been completed for each package. They are
stored in the package build directory,
output/build/-/ and are named .stamp_.
The commands detailed above simply manipulate these stamp files to
force Buildroot to restart a specific set of steps of a package build
process.
(from the Buildroot manual, section Understanding how to rebuild packages -- I suggest you read the whole section)
Also, look at your build log. If you don't see a line like
>>> kexec 2.0.16 Building
then the kecxec package hasn't been (re)built.
I cross compiled a library on Ubuntu, and I copied the build directory to my Raspberry pi. However, it won't let me do make install on raspberry pi because all the paths are according to my Ubuntu system not raspberry pi's. Is there a command to change that quickly? Thanks
it depends entirely on the build system of the library itself. if it's autotools based, you can often override specific vars like:
make install prefix=/usr bindir=/bin ...
the automake manual documents a bunch of these standard variables.
if it's not autotool based, then you'll have to read the Makefile directly to see how it can be installed. maybe it respects DESTDIR ?
make install DESTDIR=/some/other/place
I have just upgraded to latest version of buildroot. With the previous version after buildroot was done, I would see automake/autoconf in my uclibc/usr/bin. But with the latest version of buildroot ( 2014 ), I dont see that anymore.
Can anyone let me know how do I add packages which just to be built for the host? I.e I want to see host-package in the output/build folders
Thanks
First, you should never use anything in output/build, this directory contains temporary build directories. If you want to use host utilities, you should run them from the place they are installed, i.e in output/host/usr/bin/.
Regarding specifically automake, there is no option in menuconfig to enable the build of its host variant, because it normally gets built as a dependency of another package. So, you have two solutions:
1/ Create a Buildroot package for what you're trying to build, and make it depend on host-automake. That's the best solution.
2/ Run "make host-automake". This will force the build of the host variant of automake.
I have a libfoo-devel rpm that I can create, using the trick to override _topdir. Now I want to build a package "bar" which has a BuildRequires 'libfoo-devel". I can't seem to find the Right Way to get access to the contents of libfoo-devel without having to install it on the build host. How should I be doing it?
EDIT:
My build and target distros are both SuSE.
I prefer solutions that don't require mock, since I believe SuSE does not include it in its stock repo.
Subsequent EDIT:
I believe that the answer I seek is in the build package. Perhaps it's SuSE's answer to mock? Or it's the distributed version of the oBS service?
DESCRIPTION
build is a tool to build SuSE Linux
RPMs in a safe and clean way. build
will install a minimal SuSE Linux as
build system into some directory and
will chroot to this system to compile
the package. This way you don't risk
to corrupt your working system (due to
a broken spec file for example), even
if the package does not use BuildRoot.
build searches the spec file for a
BuildRequires: line; if such a line is
found, all the specified rpms are
installed. Otherwise a selection of
default packages are used. Note that
build doesn't automatically resolve
missing dependencies, so the specified
rpms have to be sufficient for the
build.
Note that if you really don't need libfoo-devel installed to build package bar the most sensible alternative would be to remove libfoo-devel from the BuildRequires directive (and maybe put the requirement where it belongs).
However, if you cannot do that for some reason, create a "development" rpm database. Basically it involves using rpm --initdb --root /path/to/fake/root. Then populate it with all of the "target packages" of your standard distro installation.
That's a lot of rpm --install --root /path/to/fake/root --justdb package-name.rpm commands, but maybe you can figure out a way to copy over your /var/lib/rpm/* database files and use those as a starting point. Once you have the alternative rpm database, you can fake the installation of the libfoo-devel package with a --justdb option. Then you'll be home free on the actual rpm build.
If neither mock nor the openSUSE Build Service are a viable choice then you will have to buckle down and install the package, either directly or in a chroot; the package provides files that the SRPM packager has decided are required to build, and hence is in the BuildRequires tag.