buildroot does not regard config changes - compilation

Im playing around with buildroot together with linaro 2016.11 for arm.
Im actually building the latest Linux Kernel for the i.MX6 Processors.
So far so good.
I have setup the buildroot config with
$ make makeconfig
I have configured an external toolchain (the linaro one). I also configured the uboot to be built. In the uboot section, i had to choose the appropriate board name for the defconfig.
Now the problem:
I have done a full make which was successfull without any errors.
After that, i have changed the uboot board name to something which does not exist in the source. Just to make sure everything is working correct.
i have restartet the build process with
$ make uboot-rebuild
to my confusion, the build was sucessfull. After a deeper look to the shell commands, i saw, that the new config was just ignored. I have tried everything without success. It only rebuilds correctly after i do a
$make clean
$make
but this will build the whole thing again and it takes a lot of time.
I hope someone could help me with that and give me some hint.
Thanks.

make <pkg>-rebuild rebuilds the package without applying a new configuration, so what happens is correct.
After changing the U-Boot configuration you have to run make uboot-reconfigure. This command first applies the configuration, then it does the same actions as uboot-rebuild.
See also the Buildroot manual, section Understanding how to rebuild packages.

Related

autoconf configure script broke under a newer Xcode version

I am trying to build the apcupsd package under a newer version of MacOS and Xcode, but the configure script supplied with the current version of apcupsd breaks under Xcode 12.4 (though it worked under Xcode 11.2).
The error is gethostbyname_r is required. Now, configure tests for this function, and ordinarily it adapts to systems that do not provide it. On the newer Xcode version, however, configure just exits with an error. I THINK it has something to do with Apple making the -Werror setting mandatory. I've found that I can get a successful build by commenting out the broken test in configure, then running it and explicitly passing the flag that configure is supposed to set. But that's not very satisfactory.
Is there is a general way to pass an override to configure for the compiler? I tried setting -Wno-error in the CPPFLAGS and CFLAGS environment for configure, but the configtest program seems to ignore those. What seems to be going on is configure is seeing that gethostbyname_r doesn't exist and sets it to no but then later on still tests for it. I'm just wondering if there's a flag or something to get past this error, as it seems to me that whatever Apple did to break (or fix) Xcode after version 11.2 would have broken a lot of people's projects.
I am looking for a solution that does not involve modifying the program sources or the Autotools input files. The project manual is not helpful in this regard.
As an update: someone on the apcupsd list told me that this issue is fixed in a later version of Xcode. I have not tried that yet but when I do if that is what it proves out to be I'll post a followup
Is there is a general way to pass an override to configure for the
compiler? I tried setting -Wno-error in the CPPFLAGS and CFLAGS
environment for configure, but the configtest program seems to ignore
those.
If you set the CFLAGS or CPPFLAGS variable in configure's environment, then not only should configure use those flags when it builds test programs, but it should also memorialize the variable so that you don't need to specify it again to make. Indeed, this ...
What seems to be going on is configure is seeing that
gethostbyname_r doesn't exist and sets it to no
... suggests that it is doing so in your case.
In that event, if it seems to test again later, or else to fail in some other way despite determining that the function is not present, then that suggests a flaw in the project's own autotooling.
I'm just wondering if there's a flag or something
to get past this error,
You have already tried the most likely candidate (CFLAGS). Alternatively, you might also be able work around the issue through use of a cache file. That's still hacky, but I think less so than modifying the configure script. I'm afraid I have no specific guidance on doing this.
as it seems to me that whatever Apple did to
break (or fix) Xcode after version 11.2 would have broken a lot of
people's projects.
It did. That does not imply that there is a quick or easy solution, though it would be good news if indeed Apple solved the issue in a later version of Xcode.

Where is the kernel config in AOSP Android 10?

I've found various kernel configs in kernel/configs/q.
When I alter them, and run mm in kernel/msm-4.14 the kernel is not rebuilt.
Where do I edit the kernel config, such that a kernel rebuild is forced when mm is run?
The kernel is built separately from the Android platform first. Then the Android platform build system is pointed at where the kernel image is located, using the TARGET_PREBUILT_KERNEL environment variable.
Here is an outline of how I usually configure and build. I have done it this way for both Android 9 and 10, for various vendors. The scheme I use is mentioned in the docs here. Non-Google kernels usually don't come with version control (repo), I don't know what you're dealing with so I'll cover both.
Configuring the kernel
For repo-checkout kernels, you do the config in build/build.config. Basically, after defconfig was taken as basis, you use the ${KERNEL_DIR}/scripts/config tool to alter the config. This usually looks as follows:
POST_DEFCONFIG_CMDS="check_defconfig && update_config"
function update_config() {
${KERNEL_DIR}/scripts/config --file ${OUT_DIR}/.config \
-d CONFIG_SOMETHING_I_DISABLE \
-e CONFIG_SOMETHING_I_ENABLE \
--set-val CONFIG_FOO = 123
}
If you don't have a repo-checkout kernel, locations and details may differ but the basic idea is usually the same: Find/Create the script that kicks of the build, and add invocations of the config tool after making defconfig.
Run the config tool by its own to see full options and more info on its usage, but the above is usually all you need. Beware: If you make syntactically-correct invalid changes (e.g. enable symbols of which the dependencies are not met), the build system will NOT complain and ignore these changes silently. If you face this situation, e.g. use menuconfig to find out what's wrong, as it shows dependencies.
Building AOSP / Making boot.img
After you've built your kernel, you will have Image.lz4 in out/.../dist (or Image.gz in out/.../private/msm-google/arch/arm64/boot). You go to your Android source, and in addition to the usual things (source build/envsetup.sh, lunch) you point the build system at the image you built, e.g. export TARGET_PREBUILT_KERNEL=/path/to/Image.lz4. Then just start the build normally, e.g. make bootimage or m droid.
Note that for Android 10 at least in some cases, you'll have to copy over the kernel modules from out/.../dist too, since the new kernel can't load the old ones. With this part, I am having problems myself at the moment. I think they have to be copied to device/VENDOR/DEVICE (e.g. google/coral-kernel), you may also copy your kernel image there btw, since the original prebuilt one also is there by default. The problem is that at least in my case, the new kernel modules were not copied to device after all.

Assistance with Compiling Synergy KVM Software

I'm following the instructions here: https://github.com/symless/synergy-core/wiki/Compiling for compiling on OSX. I've "finished" everything. But I don't understand what to do to install synergy once the compiler has completed? I was expecting a nice output directory somewhere with a synergy.app or something in it. Am I missing something? I've used the GUI method using QT to compile the code as I didnt scroll down far enough initially to realise you can do it on the command line. But either way I've managed to get to the end of the instructions for compiling and I'm a little lost now.
Thanks
Once it's compiled, Synergy binaries are outputted to the build/bin directory inside whatever directory you cloned the Synergy source to (it was ~/git/synergy-core in my case).
You can run ~/git/synergy-core/build/bin/synergy (replacing with whatever your path is) to start the Synergy configuration UI which lets you configure your server or client as desired.

Why would Buildroot not provide make target for a project-specific host package added to the build per procedure?

I've used Buildroot quite a bit over the years, and I've always managed to find solutions to the obstacles I've hit. But this one has me going in circles.
I've added a git-sourced python tool as a host package to my Buildroot build for an ARM target. I have completed the work on the package/Config.in.host and the package/toolname/Config.in.host as well as package/toolname/toolname.mk files. Everything looks to be in order. I have compared the work with what the add_new_package.wizard outputs.
The new option DOES appear in the menuconfig.
It is NOT available as a make target, although I do have target-side packages I have included that ARE valid make targets. i.e. I can run:
make target-side-package-name
and those packages are built just fine.
I cannot run:
make host-side-package-name as I get the error "No rule to make target".
So there must be something I'm doing incorrectly with the host package, although I clearly am doing the right things with the target packages.
Everything points to Buildroot simply ignoring my host package, other than sticking it into the menuconfig. My hours of searching on the webs have led to not one single post about someone having this same problem. I'm missing something obvious I would think.
My question is - what debugging can I do, where can I look to find out what is keeping Buildroot from properly recognizing my new package?
EDIT: I believe I understand now that part of the problem is the build order, and perhaps I can fix one issue with dependency directives. My target package that relies on the host package was being built first. I had assumed as common sense would dictate that host packages would be dealt with first, but that is apparently not true.
EDIT: Posting the .mk file
TOOLNAME_VERSION = 2
TOOLNAME_SITE = $(call github,devname,toolname,$(TOOLNAME_VERSION))
TOOLNAME_SETUP_TYPE = setuptools
TOOLNAME_LICENSE = GPL-3.0
TOOLNAME_LICENSE_FILES = LICENSE
HOST_TOOLNAME_DEPENDENCIES = host-python-library
$(eval $(host-python-package))
TOOLNAME = $(HOST_DIR)/usr/bin/toolname
As I hinted before, it is now running just fine so I know it's mostly set up correctly, the remaining problem is the make target is missing. Per the Buildroot manual, I should have one available.
I have now discovered that the missing make target is in fact making it impossible to build other packages dependent upon this one. The build of the dependent package now fails because "No rule to make" on the toolname package it is made to depend upon through
TARGET_PACKAGE_DEPENDENCIES = toolname
Can you post your toolname.mk? It sounds like you forgot to add the $(eval $(host-python-package)) line.
Hallelujah! The answer is that the make target name is NOT toolname, but is instead host-toolname. The root cause of the problem is the lack of mention of this nuance in section 8.12.5 of the Buildroot documentation. I stumbled across the answer while researching package dependencies in Chapter 17, where it does identify proper use for that specific case.

Kernel menuconfig under Yocto

I'm trying to configure a kernel in a Yocto build environment (bitbake virtual/kernel -c menuconfig), and for some reason the new terminal that opens when running it simply runs a full compilation of the kernel and then exits, instead of simply opening the config menu.
This used to work with the same metas in the jethro branch, but now it doesn't with krogoth.
Does anyone have any idea what could cause it?
I think I found the problem, it appears that a custom implementation of the 'do_menuconfig' python function in the vendor meta layer (classes/*.bbclass), stuck around from an older version.
Simply removing that function and thus letting the default 'do_menuconfig' function run instead seemed to do the trick.

Resources