xtables-addons does not build for arm kernel 4.1.4

Hello Gustavo,

I am trying to compile xtables-addons by Buildroot, however, I get a lot of "undefined!" warnings and some errors.

I build with:
- Buildroot (master: 15a53b93a034af78)
- internal toolchain
- Linux 4.1.4.

The Buildroot is patched by http://lists.busybox.net/pipermail/buildroot/2015-August/137485.html
for the olinuxino lime2 support. However, the same issues come with olimex_a20_olinuxino_lime_defconfig.

My setup is:

$ make olimex_a20_olinuxino_lime2_defconfig
$ make menuconfig
  enable Target packages/Network Applications/xtables-addons
$ make

And I end up with:

WARNING: "param_ops_uint" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "single_release" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "seq_read" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "seq_lseek" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "__aeabi_unwind_cpp_pr1" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "xt_unregister_matches" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "unregister_pernet_subsys" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "xt_register_matches" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "register_pernet_subsys" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "printk" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "proc_set_user" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "proc_create_data" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
WARNING: "strncpy" [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_quota2.ko] undefined!
(...)
make[6]: *** [buildroot-a20/output/build/xtables-addons-2.7/extensions/xt_DELUDE.mod.o] Error 1 buildroot-a20/output/build/xtables-addons-2.7/extensions/compat_xtables.mod.c:8:1: error: variable ?__this_module? has initializer but incomplete type
__attribute__((section(".gnu.linkonce.this_module"))) = {
^
buildroot-a20/output/build/xtables-addons-2.7/extensions/compat_xtables.mod.c:9:2: error: unknown field ?name? specified in initializer
.name = KBUILD_MODNAME,
^
buildroot-a20/output/build/xtables-addons-2.7/extensions/compat_xtables.mod.c:9:2: warning: excess elements in struct initializer buildroot-a20/output/build/xtables-addons-2.7/extensions/compat_xtables.mod.c:9:2: warning: (near initialization for ?__this_module?) buildroot-a20/output/build/xtables-addons-2.7/extensions/compat_xtables.mod.c:10:2: error: unknown field ?arch? specified in initializer
.arch = MODULE_ARCH_INIT,
^
buildroot-a20/output/build/xtables-addons-2.7/extensions/compat_xtables.mod.c:10:10: error: ?MODULE_ARCH_INIT? undeclared here (not in a function)
.arch = MODULE_ARCH_INIT,

          ^

buildroot-a20/output/build/xtables-addons-2.7/extensions/compat_xtables.mod.c:10:2: warning: excess elements in struct initializer
.arch = MODULE_ARCH_INIT,
(...)

I can see the commit eaa872edca27c6f375d
that should fix some kind of issues with Linux 4.1+. Is there something I am missing here?

I can build xtables-addons from git (tag 2.7, e277360) for both Linux 4.1.4 and 4.1.5 on x86_64 by the standard xtables-addons build-system (without Buildroot).

Regards
Jan Viktorin

   Jan Viktorin                  E-mail: Viktorin at RehiveTech.com
   System Architect              Web:    www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic

The problem is that you don't have modules (CONFIG_MODULES=y) support enabled in your kernel, as the sunxi_defconfig in the kernel until very recently didn't enable that - But it is naturally needed to build the xtables-addons modules.

Arguably Buildroot should automatically enable this for you when enabling the xtables-addons package, similar to how it is done for the netfilter options even though it is quite a "big" option to enable behind your back. Alternatively we could simply error out with a sensible message like it was recently done for the pkg-kernel-module infrastructure.

You most likely have modules support in your x86-64 kernel.

Bye, Peter Korsgaard

Thank you for this hint! I'll check it out.

I agree, I would be happy to get a reasonable error message instead of loosing few hours of looking up for such a trivial mistake.

  Jan Viktorin                E-mail: Viktorin at RehiveTech.com
  System Architect            Web:    www.RehiveTech.com
  RehiveTech                  Phone: +420 606 201 868
  Brno, Czech Republic

Hello all,

this short patch series introduces a way how to check whether certain CONFIG_* entries are set to an expected value in a selected .config file. When building a package that requires a certain CONFIG_* to be set (as in the case of xtables-addons), Buildroot can either force to set the config or just error out a message.

I could not find any suitable mechanism for this in Buildroot (if there is one, please give me a reference) so I propose a simple extension of KCONFIG_*_OPT util macros. It is then implemented for xtables-addons to check whether CONFIG_MODULES are set in the Linux Kernel .config.

Regards
Jan Viktorin

Jan Viktorin (2):
pkg-utils: Define KCONFIG_ASSERT_OPT macro
xtables-addons: test CONFIG_MODULES=y in the kernel

 package/pkg-utils.mk                     | 5 +++++
 package/xtables-addons/xtables-addons.mk | 5 +++++
 2 files changed, 10 insertions(+)

2.5.0

The macro can be used (eg. in packages) to assure that a certain option in the Linux/BusyBox/...'s .config is set to the given value.

---
 package/pkg-utils.mk | 5 +++++
 1 file changed, 5 insertions(+)

index 44bd2c9..1e34864 100644
@@ -63,6 +63,11 @@ define KCONFIG_DISABLE_OPT # (option, file)
 	echo '# $(1) is not set' >> $(2)
 endef
 
+define KCONFIG_ASSERT_OPT # (option, value, file)
+	grep "\\<$(1)\\>=$(2)" $(3) > /dev/null \
+		|| (echo "KCONFIG_ASSERT_OPT($(1),$(2),$(3)) has failed" >&2; exit 1)
+endef
+
 # Helper functions to determine the name of a package and its
 # directory from its makefile directory, using the $(MAKEFILE_LIST)
 # variable provided by make. This is used by the *-package macros to

2.5.0

Jan, All,

On 2015-08-19 15:14 +0200, Jan Viktorin spake thusly:

    $(call KCONFIG_ASSERT_OPT,CONFIG_FOO,y,$(LINUX_DIR)/.config); \
    $(call KCONFIG_ASSERT_OPT,CONFIG_BAR,y,$(LINUX_DIR)/.config); \
    $(call KCONFIG_ASSERT_OPT,CONFIG_BUZ,y,$(LINUX_DIR)/.config)

    define KCONFIG_ASSERT_OPT # (option, value, file)
        if ! grep -E "^$(1)=$(2)\$$" $(3) >/dev/null; then \
            printf "Error: option %s is not set to %s\n" '$(1)' '$(2)' '$(3}'; \
            exit 1; \
        fi
    endef # KCONFIG_ASSERT_OPT

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

The package builds several loadable modules for the Linux kernel. There are in-kernel defconfigs that does not enable the CONFIG_MODULES by default. Thus, a build of xtables-addons should fail for such incompatible kernel configuration.

---
 package/xtables-addons/xtables-addons.mk | 5 +++++
 1 file changed, 5 insertions(+)

index 75e2a5a..9450ebb 100644
@@ -22,6 +22,11 @@ define XTABLES_DISABLE_GEOIP_HELPERS
 endef
 XTABLES_ADDONS_POST_PATCH_HOOKS += XTABLES_DISABLE_GEOIP_HELPERS
 
+define XTABLES_ASSERT_CONFIG_MODULES
+	$(call KCONFIG_ASSERT_OPT,CONFIG_MODULES,y,$(LINUX_DIR)/.config)
+endef
+XTABLES_ADDONS_PRE_CONFIGURE_HOOKS += XTABLES_ASSERT_CONFIG_MODULES
+
 define XTABLES_ADDONS_BUILD_CMDS
 	$(MAKE) -C $(@D) $(LINUX_MAKE_FLAGS)
 endef

2.5.0

Dear Jan Viktorin,

There is some discussion already going on on this topic, around the pkg-kernel-module infrastructure. We recently committed a patch that makes the infrastructure verify that the kernel has been built with module support, and if not, bail out with a clear error message:

http://git.buildroot.net/buildroot/commit/?id=8df95d926e963601c727defeb4ab90ce2368da70

However, Peter Korsgaard raised the concern that we should instead just forcefully enable CONFIG_MODULES=y in the configuration in such a case. There has then been some discussion with Yann on how to achieve that properly. Please see the thread at
http://lists.busybox.net/pipermail/buildroot/2015-August/137511.html.

Best regards,

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Thomas, Jan, All,

On 2015-08-19 19:46 +0200, Thomas Petazzoni spake thusly:

Arguably, xtables-addons should be (if possible) converted over to using the kernel-modules infra, which should (will) take care of that (in the future). I'll try to see if I can convert it.

Yes, I'm thinking about it...

I think the plan I'll be goign with is to add a hidden Kconfig knob that packages that want to build a kernel module will have to select.

Then, if that option is set, we can force-on support for modules in linux.mk. Note: if the option is not set, we would *not* disable support for modules, and let it as set in the user-provided (def)config file.

So, all in all, that would solve the xtables-addons issue, because we would be handling CONFIG_MODULE explicitly.

Now, there are two questions:

- will we need to _check_ for any arbitrary kernel option to be set, and offer packages a simple mean to do so?

- will we need to _force_ (on or off) any other kernel option, and offer packages a simple mean to do so?

Regards,
Yann E. MORIN.

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Dear Yann E. MORIN,

Sounds good to me.

We already do your second item.

In general, I'd like to keep the handling of the kernel configuration to be as minimal as possible. Otherwise, we'll quickly enter a situation where we need to enable different kernel options depending on the kernel version. It can quickly become a real nightmare. Buildroot has always been about the user knowing what (s)he is doing, including in terms of making sure that the kernel configuration matches what is done in userspace.

Thanks,

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Thomas, All,

On 2015-08-19 21:08 +0200, Thomas Petazzoni spake thusly:

[--SNIP--]

No, we are not allowing any random package to set kernel options.

We do have infra for packages to tweak their *own* options, not those of other packages (and history has proved it was not doable, I should know, I tried and failed miserably with the lzo stuff).

I do fully agree with you on this position. Tweaking the kernel options is a real hornet's nest...

Regards,
Yann E. MORIN.

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Dear Yann E. MORIN,

No, we do it the other way around: linux.mk tweaks the kernel options depending on which packages are selected.

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Hi,

Yeah, agreed.

Why not just like the kernel-module infrastructure handle it like I proposed? I don't think it is very nice that people have to remember to add the select as well (and chances are they won't notice if they forget).

Like Thomas says, we are already doing the 2nd option and I think it makes sense to keep on doing so - So I don't think there's a common need for the first.

Bye, Peter Korsgaard

Peter, All,

[I forgot to send that one; it got stuck in my draft folder...]

On 2015-08-19 23:05 +0200, Peter Korsgaard spake thusly:

I'll be working on it (not trivial from a first look).

Because that would not work for packages in br2-external trees, as I already explained.

And I do *not* want that we treat packages from br2-external differently that the in-tree ones [*].

I know you are not using br2-external (and also do not really see the point of it), but a lot of people find this to be a really important feature. I also suspect some of our (corporate) users did choose Buildroot (partly) because of br2-external.

[*] there already are a few use-cases that br2-external does not and can't solve, because of the way Buildroot is designed, see below for an example; let's not add arbitrary limitations that we can very easily avoid.

Still, we are currently not allowing another package to set kernel options _from_ that package's .mk file. All we have is the kernel (de)activating options based on the presence of other packages, and that excludes packages from br2-external. Unless Buildroot is modified accordingly (but then br2-external looses its attractiveness for that package).

Note: I never said we should provide a way for packages to enable or disable arbitrary kernel options. I was just asking.

Regards,
Yann E. MORIN.

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

On a related note (mainly to fuel ideas) Denis posted the following patch a couple of weeks ago...

http://lists.busybox.net/pipermail/buildroot/2015-August/135321.html

This patch is integrated in pkg-kconfig and "transforms" all kconfig variables into makefile variables. These variables can then be used from any package to test for available options...

Just pointing out a different approch to the same problem

Cordialement

J?r?my Rosen
+33 (0)1 42 68 28 13

fight key loggers : write some perl using vim

Open Wide Ingenierie

23, rue Daviel
75013 Paris - France
www.openwide.fr

Hi,

Are you sure? I didn't try it, but as we only *USE* the variable when LINUX_KCONFIG_FIXUP_CMDS runs, which is after all the .mk files have been parsed I think it should work?

It's true that I don't personally use br2-external and don't find it such a killer feature, I *DO* acknowledge that some people do (which is why I merged the support for it in the first place) and will try to keep it working as good as possible. With that said, we have a lot of other requirements for Buildroot (like keeping it simple), so will not bend over backwards to improve br2-external support if it means making big compromises elsewhere.

br2-external stuff will always been more limited than normal packages in the tree.

Ok, but if all of these use the kernel-module infrastructure (which linux.mk knows about), then this should work for CONFIG_MODULES, right? It naturally cannot work for random other config settings.

Venlig hilsen,
Peter Korsgaard 

Peter, All,

On 2015-08-21 22:28 +0200, Peter Korsgaard spake thusly:

Ah, just checking would indeed be doable, something similar (but more restrictive) to the patch proposed by Jan:

    https://patchwork.ozlabs.org/patch/508729/

I.e. somthing like:

    define $(2)_KERNEL_MODULES_BUILD
        if ! grep -E "^CONFIG_MODULES=y\$$" $$(LINUX_DIR)/.config >/dev/null; then \
            printf "Error: your Linux kernel does not support modules\n"; \
            exit 1; \
        fi
        [--current code--]
    endef

Yes, that would work.

But I was focused on actually enabling the CONFIG_MODULES option when a package wants to build a kernel module, and _that_ is not possible with the kernel-module infra.

OK, thanks! :-)

I do agree with that.

Yes, probably. But what I argue is that we should not introduce _arbitrary_ restrictions that we can easily avoid. And by "easily", I do agree that it should not require huge changes in Buildroot, be simple code, be simple to understand and be simple to use.

No, linux.mk does not know of the kernel-module infra. The kernel-module infra is entirely implemented using post-build and post-install hooks of the package itself, not of the kernel.

Maybe you confused kernel-module with the linux extensions?

So I guess I start to see where the misunderstanding comes from... The kernel-module infra can indeed _check_ that CONFIG_MODULES is set, but it can not set it.

(Arguably, we could do it for in-tree packages, because their .mk are parsed before that of the kernel, so we could set a Makefiel variable to tell linux.mk to enable CONFIG_MODULES. But since br2-external packages are parsed after linux.mk, then we could not for those packages).

So, I've decided to prepare two patch series, and we can apply the one that gets consensus:
- one that does the check in the kernel-module infra,
- one that forces CONFIG_MODULES when required.

When both are ready, I'll push them to the list.

I hope we can get either in *before* the release: the kernel-module infra is brand new in this cycle, and I'd like we get a stable "API" for it before releasing it to the wild.

ACK.

Regards,
Yann E. MORIN.

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Hi,

We seemed to be talking past eachother, but got it sorted out on IRC. For others following, the change I suggested was actually the one mentioned here:

http://lists.busybox.net/pipermail/buildroot/2015-August/137540.html

Venlig hilsen,
Peter Korsgaard