dhcpcd: unavailable for bfin and fix another bug

dhcpcd needs a toolchain with getifaddrs support which the current
blackfin toolchain lacks. Fixes:
http://autobuild.buildroot.net/results/f4dd9ca2774bc89e6f976d75a13190d8a1e457f3/

This is not detected by dhcpcd's configure because it's being called
with default (non-cross) CC and other variables.
Thus pass TARGET_CONFIGURE_OPTS to configure to fix this.
Fixes another build failure i've encountered where the host has very
modern headers and dhcpcd tries to use the latest features which the
cross toolchain lacks.

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/dhcpcd/Config.in | 1 +
 package/dhcpcd/dhcpcd.mk | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

Dear Gustavo Zacarias,

On Fri, 28 Jun 2013 20:56:25 -0300, Gustavo Zacarias wrote:

> diff --git a/package/dhcpcd/Config.in b/package/dhcpcd/Config.in
> index a06a973..a032694 100644
> --- a/package/dhcpcd/Config.in
> +++ b/package/dhcpcd/Config.in
> @@ -1,5 +1,6 @@
>  config BR2_PACKAGE_DHCPCD
>  	depends on BR2_INET_IPV6
> +	depends on !BR2_bfin

I would prefer to see an explicit "depends on !" on the specific
Blackfin external toolchains that are causing problems. If one day we
get the internal backend to properly build a toolchain for Blackfin,
then doing a "depends on !BR2_bfin" wouldn't make sense.

The Blackin external toolchain versions aren't changing that often, so
it shouldn't cause too much hassle to update dhpcd dependencies when
that happens.

Best regards,

Thomas

On 06/29/2013 05:42 AM, Thomas Petazzoni wrote:

> I would prefer to see an explicit "depends on !" on the specific
> Blackfin external toolchains that are causing problems. If one day we
> get the internal backend to properly build a toolchain for Blackfin,
> then doing a "depends on !BR2_bfin" wouldn't make sense.
> 
> The Blackin external toolchain versions aren't changing that often, so
> it shouldn't cause too much hassle to update dhpcd dependencies when
> that happens.

That would be all good and well if the internal toolchain worked, snip:

checking for F_SETLKW... yes
checking if mkdir takes one argument... no
This target does not support --with-cpu.
Valid --with options are:
make[1]: *** [configure-gcc] Error 1
make[1]: Leaving directory
`/home/gustavoz/b/fin/output/toolchain/gcc-4.7.3-initial'
make: ***
[/home/gustavoz/b/fin/output/toolchain/gcc-4.7.3-initial/.compiled] Error 2

(all defaults except +IPV6 for dhcpcd).
And 2012R1-RC2 fails to download properly (2012R2-RC2 too for that
matter but i've got a local copy).
I kind of doubt that 2012R1 being older has getifaddrs enabled though.
Regards.

Dear Gustavo Zacarias,

On Sat, 29 Jun 2013 07:52:01 -0300, Gustavo Zacarias wrote:

> > I would prefer to see an explicit "depends on !" on the specific
> > Blackfin external toolchains that are causing problems. If one day we
> > get the internal backend to properly build a toolchain for Blackfin,
> > then doing a "depends on !BR2_bfin" wouldn't make sense.
> > 
> > The Blackin external toolchain versions aren't changing that often, so
> > it shouldn't cause too much hassle to update dhpcd dependencies when
> > that happens.
> 
> That would be all good and well if the internal toolchain worked, snip:
> 
> checking for F_SETLKW... yes
> checking if mkdir takes one argument... no
> This target does not support --with-cpu.
> Valid --with options are:
> make[1]: *** [configure-gcc] Error 1
> make[1]: Leaving directory
> `/home/gustavoz/b/fin/output/toolchain/gcc-4.7.3-initial'
> make: ***
> [/home/gustavoz/b/fin/output/toolchain/gcc-4.7.3-initial/.compiled] Error 2

The fact that the internal toolchain doesn't work today for Blackfin is
a separate issue :)

> (all defaults except +IPV6 for dhcpcd).
> And 2012R1-RC2 fails to download properly (2012R2-RC2 too for that
> matter but i've got a local copy).
> I kind of doubt that 2012R1 being older has getifaddrs enabled though.

Yes, one recent patch to the download infrastructure broke this. I
should sent a different e-mail with this.

Best regards,

Thomas

On 06/29/2013 07:55 AM, Thomas Petazzoni wrote:

>> (all defaults except +IPV6 for dhcpcd).
>> And 2012R1-RC2 fails to download properly (2012R2-RC2 too for that
>> matter but i've got a local copy).
>> I kind of doubt that 2012R1 being older has getifaddrs enabled though.
> 
> Yes, one recent patch to the download infrastructure broke this. I
> should sent a different e-mail with this.

Downloaded manually and as i supposed, it lacks getifaddrs too.
Regards.

Dear Gustavo Zacarias,

On Sat, 29 Jun 2013 09:31:21 -0300, Gustavo Zacarias wrote:
> On 06/29/2013 07:55 AM, Thomas Petazzoni wrote:
> 
> >> (all defaults except +IPV6 for dhcpcd).
> >> And 2012R1-RC2 fails to download properly (2012R2-RC2 too for that
> >> matter but i've got a local copy).
> >> I kind of doubt that 2012R1 being older has getifaddrs enabled though.
> > 
> > Yes, one recent patch to the download infrastructure broke this. I
> > should sent a different e-mail with this.
> 
> Downloaded manually and as i supposed, it lacks getifaddrs too.

Yes, of course it lacks getifaddrs, but I don't see how it changes the
point I was making originally: it is not because /some/ external
toolchains are affected that we should exclude an entire architecture
from building a particular package.

Best regards,

Thomas

On 06/29/2013 09:37 AM, Thomas Petazzoni wrote:

> Yes, of course it lacks getifaddrs, but I don't see how it changes the
> point I was making originally: it is not because /some/ external
> toolchains are affected that we should exclude an entire architecture
> from building a particular package.

Oh come on!
The ct-ng sample doesn't have UCLIBC_SUPPORT_AI_ADDRCONFIG set
(default=n in uClibc upstream).
None of Analog's toolchains have it either.
There's some old Ronetix blackfin toolchain that doesn't support it either.
So that just leaves a customized ct-ng or hand-built toolchain as a
canditate, which i take it as "very unlikely" to happen.
Regards.