Patchwork libcap-ng: doesn't build on AVR32, requires TLS support

login
register
mail settings
Submitter Thomas Petazzoni
Date Oct. 6, 2013, 4:34 p.m.
Message ID <1381077279-19561-1-git-send-email-thomas.petazzoni@free-electrons.com>
Download mbox | patch
Permalink /patch/280889/
State Superseded
Headers show

Comments

Thomas Petazzoni - Oct. 6, 2013, 4:34 p.m.
libcap-ng doesn't build on AVR32, since it requires TLS support in the
compiler and C library.

Fixes:

  http://autobuild.buildroot.org/results/770/77061f301ba405a1607ce5bfa9e450182f0fdec5/build-end.log

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/libcap-ng/Config.in | 2 ++
 package/ofono/Config.in     | 1 +
 2 files changed, 3 insertions(+)
Peter Korsgaard - Oct. 6, 2013, 6:44 p.m.
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> libcap-ng doesn't build on AVR32, since it requires TLS support in the
 Thomas> compiler and C library.

 Thomas> Fixes:

 Thomas>   http://autobuild.buildroot.org/results/770/77061f301ba405a1607ce5bfa9e450182f0fdec5/build-end.log

 Thomas> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
 Thomas> ---
 Thomas>  package/libcap-ng/Config.in | 2 ++
 Thomas>  package/ofono/Config.in     | 1 +
 Thomas>  2 files changed, 3 insertions(+)

 Thomas> diff --git a/package/libcap-ng/Config.in b/package/libcap-ng/Config.in
 Thomas> index d1663cd..b799dc9 100644
 Thomas> --- a/package/libcap-ng/Config.in
 Thomas> +++ b/package/libcap-ng/Config.in
 Thomas> @@ -1,5 +1,7 @@
 Thomas>  config BR2_PACKAGE_LIBCAP_NG
 Thomas>  	bool "libcap-ng"
 Thomas> +	# tls support, needed by libcap-ng, not available on avr32
 Thomas> +	depends on !BR2_avr32

Shouldn't it then depend on BR2_GCC_ENABLE_TLS (and the avr32 toolchain
not select it)?
Thomas Petazzoni - Oct. 6, 2013, 9:23 p.m.
Dear Peter Korsgaard,

On Sun, 06 Oct 2013 20:44:30 +0200, Peter Korsgaard wrote:

>  Thomas> diff --git a/package/libcap-ng/Config.in b/package/libcap-ng/Config.in
>  Thomas> index d1663cd..b799dc9 100644
>  Thomas> --- a/package/libcap-ng/Config.in
>  Thomas> +++ b/package/libcap-ng/Config.in
>  Thomas> @@ -1,5 +1,7 @@
>  Thomas>  config BR2_PACKAGE_LIBCAP_NG
>  Thomas>  	bool "libcap-ng"
>  Thomas> +	# tls support, needed by libcap-ng, not available on avr32
>  Thomas> +	depends on !BR2_avr32
> 
> Shouldn't it then depend on BR2_GCC_ENABLE_TLS (and the avr32 toolchain
> not select it)?

It wouldn't work with external toolchains, which is the reason why I
excluded the AVR32 architecture rather than using a BR2_GCC_ENABLE_TLS
condition.

Best regards,

Thomas
Peter Korsgaard - Oct. 6, 2013, 9:42 p.m.
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> Dear Peter Korsgaard,
 Thomas> On Sun, 06 Oct 2013 20:44:30 +0200, Peter Korsgaard wrote:

 Thomas> diff --git a/package/libcap-ng/Config.in b/package/libcap-ng/Config.in
 Thomas> index d1663cd..b799dc9 100644
 Thomas> --- a/package/libcap-ng/Config.in
 Thomas> +++ b/package/libcap-ng/Config.in
 Thomas> @@ -1,5 +1,7 @@
 Thomas> config BR2_PACKAGE_LIBCAP_NG
 Thomas> bool "libcap-ng"
 Thomas> +	# tls support, needed by libcap-ng, not available on avr32
 Thomas> +	depends on !BR2_avr32
 >> 
 >> Shouldn't it then depend on BR2_GCC_ENABLE_TLS (and the avr32 toolchain
 >> not select it)?

 Thomas> It wouldn't work with external toolchains, which is the reason why I
 Thomas> excluded the AVR32 architecture rather than using a BR2_GCC_ENABLE_TLS
 Thomas> condition.

Ok, but from your comment I believe it should also depend on
BR2_GCC_ENABLE_TLS (E.G. it would break on other archs if you disable
TLS support)?

If we start having other packages needing TLS, then we should perhaps
provide the option for external toolchains as well, similar to how we do
for the other toolchain settings.
Thomas Petazzoni - Oct. 7, 2013, 6:53 a.m.
Dear Peter Korsgaard,

On Sun, 06 Oct 2013 23:42:54 +0200, Peter Korsgaard wrote:

>  Thomas> It wouldn't work with external toolchains, which is the reason why I
>  Thomas> excluded the AVR32 architecture rather than using a BR2_GCC_ENABLE_TLS
>  Thomas> condition.
> 
> Ok, but from your comment I believe it should also depend on
> BR2_GCC_ENABLE_TLS (E.G. it would break on other archs if you disable
> TLS support)?

If we make the package depend on BR2_GCC_ENABLE_TLS, then it would no
longer be visible for any external toolchain.

> If we start having other packages needing TLS, then we should perhaps
> provide the option for external toolchains as well, similar to how we do
> for the other toolchain settings.

I'm always a bit reluctant to add more and more toolchain options,
since they are a pain to maintain, and do not necessarily reflect real
use cases. Is it really an useful use-case to support non-TLS
toolchains on architectures where TLS support is available?

Best regards,

Thomas

Patch

diff --git a/package/libcap-ng/Config.in b/package/libcap-ng/Config.in
index d1663cd..b799dc9 100644
--- a/package/libcap-ng/Config.in
+++ b/package/libcap-ng/Config.in
@@ -1,5 +1,7 @@ 
 config BR2_PACKAGE_LIBCAP_NG
 	bool "libcap-ng"
+	# tls support, needed by libcap-ng, not available on avr32
+	depends on !BR2_avr32
 	help
 	  The libcap-ng library is intended to make programming with
 	  posix capabilities much easier than the traditional libcap
diff --git a/package/ofono/Config.in b/package/ofono/Config.in
index 5d82170..729f15b 100644
--- a/package/ofono/Config.in
+++ b/package/ofono/Config.in
@@ -3,6 +3,7 @@  config BR2_PACKAGE_OFONO
 	depends on BR2_USE_WCHAR # gettext, libglib2
 	depends on BR2_TOOLCHAIN_HAS_THREADS # dbus, libglib2
 	depends on BR2_USE_MMU # dbus
+	depends on !BR2_avr32 # libcap-ng -> tls support
 	select BR2_PACKAGE_LIBCAP_NG
 	select BR2_PACKAGE_DBUS
 	select BR2_PACKAGE_LIBGLIB2