[Buildroot] [PATCH v5 1/3] busybox: disable nslookup applet

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Hello,

On Tue, 14 Jul 2015 18:31:26 +0200, Thomas Petazzoni wrote:

> I know this solution was suggested to you instead of adding a new
> toolchain option that tells us whether resolver support is available or
> not.
> 
> However, the problem with the solution of changing the Busybox config
> file is that it fixes Busybox only: there will possibly be plenty of
> other packages using res_*(). And we will have no way to fix those
> packages in a proper way, except possibly by making them 'depends
> on !BR2_TOOLCHAIN_EXTERNAL_OSELAS_ARM_CORTEX_M3_201412'. But if other
> OSELAS toolchains for other architectures also lack resolver support,
> then we will have to add more and more of those exclusions.
> 
> Conclusion: I am wondering if your initial solution was not the right
> one.

I did a comparison between the uClibc_config.h of the OSELAS Cortex-M3
toolchain and the uClibc_config.h of a uClibc toolchain built by
Buildroot, and there are quite a few differences in the configuration.

First and foremost, OSELAS is using uClibc 0.9.33.2 with almost no
patches. And in Buildroot, we had to add a lot of patches to uClibc to
make it properly support a number of packages (which is also why we've
switched to uClibc-ng as the default C library).

And then, the uClibc configuration itself is quite different: a number
of features that we enable by default in the Buildroot uClibc
configuration are not enabled in the OSELAS Cortex-M3 uClibc. So when
we will start adding the OSELAS Cortex-M3 toolchain in the
autobuilders, it will probably start showing a number of failures
caused by this uClibc version/configuration being quite different from
the usual Buildroot expectations.

So, we've got two possibilities here:

 1/ Just give up on the OSELAS toolchain, and focus on making Buildroot
    capable of building a Cortex-M3 toolchain.

 2/ Really add the toolchain anyway, but be prepared for some
    additional work to handle all those issues. Since the Cortex-M3 is
    noMMU, it means that a significant fraction of the packages are not
    available, so maybe it will be more reasonable that I expect. But I
    was in fact hoping to be able to add other OSELAS toolchains, even
    for MMU capable platforms. But if they have such uClibc
    configurations, we might be limited to using their glibc toolchains.

What do you think?

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