[Buildroot] [PATCH v3] Add package connman
Daniel Mack
zonque at gmail.com
Mon Dec 5 23:07:26 UTC 2011
On 12/05/2011 11:18 PM, Peter Korsgaard wrote:
>>>>>> "Daniel" == Daniel Mack <zonque at gmail.com> writes:
> Daniel> +if BR2_PACKAGE_CONNMAN
> Daniel> +
> Daniel> +config BR2_PACKAGE_CONNMAN_THREADS
> Daniel> + bool "enable threading support"
> Daniel> + depends on BR2_TOOLCHAIN_HAS_THREADS
> Daniel> + default y
> Daniel> +
> Daniel> +config BR2_PACKAGE_CONNMAN_ETHERNET
> Daniel> + bool "enable Ethernet support"
> Daniel> + default y
> Daniel> +
> Daniel> +config BR2_PACKAGE_CONNMAN_WIFI
> Daniel> + bool "enable WiFi support"
> Daniel> + select BR2_PACKAGE_WPA_SUPPLICANT
> Daniel> + default y
>
> I wouldn't enable WIFI support by default, to not get it to pull in
> wpa_supplicant, so drop the 'default y'
Ok, that's reasonable.
> Daniel> +++ b/package/connman/connman.mk
> Daniel> @@ -0,0 +1,21 @@
> Daniel> +#######################################################
> Daniel> +#
> Daniel> +# connman - open source connection manager
> Daniel> +#
> Daniel> +#######################################################
> Daniel> +
> Daniel> +CONNMAN_VERSION = 0.78
> Daniel> +CONNMAN_SITE = git://git.kernel.org/pub/scm/network/connman/connman.git
> Daniel> +CONNMAN_DEPENDENCIES = libglib2 dbus iptables
> Daniel> +CONNMAN_AUTORECONF = YES
>
> It seems to install a .pc file and some headers, so we should have
> CONNMAN_INSTALL_STAGING = YES
Ok, I can do this, too. The primary interface for communication with the
daemon is DBus, so we don't seem to need headers, but the .pc file is a
fair reason.
> What about installing an initscript? I see there's an example init
> script in the connman sources, but that doesn't seem directly applicable
> to our busybox based system.
Yes, I can write one up.
> I applied the patch and gave it a quick test, but it fails with the
> default uClibc configuration as we don't enable
> UCLIBC_HAS_RESOLVER_SUPPORT (just like upstream), and connman seems to
> want it for gweb/gresolv.c:
>
> checking resolv.h usability... yes
> checking resolv.h presence... yes
> checking for resolv.h... yes
> checking for ns_initparse in -lresolv... no
> checking for __ns_initparse in -lresolv... no
> configure: error: resolver library support is required
> make: *** [/home/peko/source/buildroot/output/build/connman-0.78/.stamp_configured
Yes, this is the reason why I added resolver support to uClibc some
months back, and all the stuff in upstream now.
> I don't like to add it if doesn't work with uClibc based toolchains.
Well, it does, if you enable UCLIBC_HAS_RESOLVER_SUPPORT. What about
adding a dependency for that? If people want to have connman, they have
to manually select this feature and rebuild their uClibc. Does that
sound ok?
> We
> can add a toolchain configuration option to enable the UCLIBC
> configuration, but that doesn't help for ctng and external toolchains.
Why not depend on UCLIBC_HAS_RESOLVER_SUPPORT if uClibc is used and
whitelist others?
Something like
depends on (BR2_TOOLCHAIN_BUILDROOT && UCLIBC_HAS_RESOLVER_SUPPORT) ||
BR2_TOOLCHAIN_CTNG
?
And if people verify that it works with other toolchains as well, this
list can be augmented.
> What configuration are you using it with?
I tested it with both uClibc and Crosstool-NG (eglibc), and both worked
fine for me.
Thanks,
Daniel
More information about the buildroot
mailing list