[Buildroot] [PATCH] libcap-ng: disable on avr32 which lacks TLS

[Buildroot] [PATCH] libcap-ng: disable on avr32 which lacks TLS

[Samuel Martin]

libcap-ng needs TLS support, which is not available on avr32.
Also, disable reverse dependencies.

Fixes:
  http://autobuild.buildroot.net/results/73c/73c7c211a51c312bbe4eb6a540f3ad9c92c79ebe/

Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 package/libcap-ng/Config.in | 1 +
 package/ofono/Config.in     | 1 +
 2 files changed, 2 insertions(+)

diff --git a/package/libcap-ng/Config.in b/package/libcap-ng/Config.in
index d1663cd..da5b447 100644
--- a/package/libcap-ng/Config.in
+++ b/package/libcap-ng/Config.in
@@ -1,5 +1,6 @@
 config BR2_PACKAGE_LIBCAP_NG
 	bool "libcap-ng"
+	depends on !BR2_avr32 # lacks TLS
 	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 c431e08..2f4f2b9 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
 	select BR2_PACKAGE_LIBCAP_NG
 	select BR2_PACKAGE_DBUS
 	select BR2_PACKAGE_LIBGLIB2
-- 
1.8.4.2

[Buildroot] [PATCH] libcap-ng: disable on avr32 which lacks TLS

[Thomas Petazzoni]

Dear Samuel Martin,

On Fri, 22 Nov 2013 09:08:14 +0100, Samuel Martin wrote:
> libcap-ng needs TLS support, which is not available on avr32.
> Also, disable reverse dependencies.
> 
> Fixes:
>   http://autobuild.buildroot.net/results/73c/73c7c211a51c312bbe4eb6a540f3ad9c92c79ebe/
> 
> Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> ---
>  package/libcap-ng/Config.in | 1 +
>  package/ofono/Config.in     | 1 +
>  2 files changed, 2 insertions(+)

See the discussion at http://patchwork.ozlabs.org/patch/288051/.

However, this patch is better in that it takes into account reverse
dependencies. But it still isn't perfect because it isn't updating
ofono comment so that it doesn't get shown on AVR32.

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

[Buildroot] [PATCH] libcap-ng: disable on avr32 which lacks TLS

[Samuel Martin]

Hi Thomas,


2013/11/22 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

> Dear Samuel Martin,
>
> On Fri, 22 Nov 2013 09:08:14 +0100, Samuel Martin wrote:
> > libcap-ng needs TLS support, which is not available on avr32.
> > Also, disable reverse dependencies.
> >
> > Fixes:
> >
> http://autobuild.buildroot.net/results/73c/73c7c211a51c312bbe4eb6a540f3ad9c92c79ebe/
> >
> > Signed-off-by: Samuel Martin <s.martin49@gmail.com>
> > ---
> >  package/libcap-ng/Config.in | 1 +
> >  package/ofono/Config.in     | 1 +
> >  2 files changed, 2 insertions(+)
>
> See the discussion at http://patchwork.ozlabs.org/patch/288051/.
>

> However, this patch is better in that it takes into account reverse
> dependencies. But it still isn't perfect because it isn't updating
> ofono comment so that it doesn't get shown on AVR32.
>
Indeed.

If I resubmit the patch, would it be merged or do we prefer just having the
solution in which
TLS knob is driven by thread support (as discussed in the thread you
mentioned above)?

IMHO, this patch (with the comment fixed) can be integrated for the
release, and a more long
term solution can be implement later for the next release.

Regards,

-- 
Samuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131122/0f0c022a/attachment.html>

[Buildroot] [PATCH] libcap-ng: disable on avr32 which lacks TLS

[Thomas Petazzoni]

Dear Samuel Martin,

On Fri, 22 Nov 2013 10:17:20 +0100, Samuel Martin wrote:

> If I resubmit the patch, would it be merged or do we prefer just
> having the solution in which
> TLS knob is driven by thread support (as discussed in the thread you
> mentioned above)?
> 
> IMHO, this patch (with the comment fixed) can be integrated for the
> release, and a more long
> term solution can be implement later for the next release.

I believe for 2013.11, a patch like the one you proposed is the best
solution we have (with the ofono comment fixed, of course), but I'd like
to have an entry added in the TODO-list at http://elinux.org/Buildroot
to remind us to do something, with pointers to the relevant discussion.

Thanks,

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