[v5,1/3] busybox: disable nslookup applet

Some toolchains have no resolver support (res_* family), so they fail to
build this applet (which is the only user of those functions). Instead
of selectively disabling it on such limited toolchains, just drop it
from the default config, since (to the best of my knowledge) is not
widely used.

Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>
---
 package/busybox/busybox.config | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Dear Guido Martínez,

On Tue, 14 Jul 2015 13:09:32 -0300, Guido Martínez wrote:
> Some toolchains have no resolver support (res_* family), so they fail to
> build this applet (which is the only user of those functions). Instead
> of selectively disabling it on such limited toolchains, just drop it
> from the default config, since (to the best of my knowledge) is not
> widely used.
> 
> Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar>

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.

Thomas

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

On 14/07/15 13:55, Thomas Petazzoni wrote:

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

As far as i remember as you say uclibc for M3 requires minimal patching.
IMHO option 1 would be best rather than the "black box" solution 
(besides a lack of options being problematic).
It would help Waldemar include any required patches upstream in 
uclibc-ng going forward.
Regards.

Hi Thomas,

On Tue, Jul 14, 2015 at 06:55:14PM +0200, Thomas Petazzoni wrote:
> [...]
>
> 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?

I have no problem with option 1. In fact, I was going to try to do it
anyway even if the OSELAS toolchain got accepted. I'll start looking
into it in detail and report back. I haven't done anything similar in
the past so it might take me a while.

Thanks to all who reviewed the patches!