[Buildroot] [PATCH] strongswan: needs atomics

[Buildroot] [PATCH] strongswan: needs atomics

[Gustavo Zacarias]

Fixes:
http://autobuild.buildroot.net/results/3d1/3d13ced1b142d014c5bc098137174c4369a1e3b5/

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

diff --git a/package/strongswan/Config.in b/package/strongswan/Config.in
index 23131dc..bdbbb50 100644
--- a/package/strongswan/Config.in
+++ b/package/strongswan/Config.in
@@ -1,10 +1,12 @@
 comment "strongswan needs a toolchain w/ threads"
 	depends on BR2_USE_MMU
+	depends on BR2_ARCH_HAS_ATOMICS
 	depends on !BR2_TOOLCHAIN_HAS_THREADS
 
 menuconfig BR2_PACKAGE_STRONGSWAN
 	bool "strongswan"
 	depends on BR2_USE_MMU # fork()
+	depends on BR2_ARCH_HAS_ATOMICS
 	depends on BR2_TOOLCHAIN_HAS_THREADS
 	help
 	  strongSwan is an OpenSource IPsec implementation for the
-- 
2.0.5

[Buildroot] [PATCH] strongswan: needs atomics

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Wed,  8 Apr 2015 12:32:08 -0300, Gustavo Zacarias wrote:
> Fixes:
> http://autobuild.buildroot.net/results/3d1/3d13ced1b142d014c5bc098137174c4369a1e3b5/
> 
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>

Hum, I don't quite see how this change can fix the build issue. The
build issue is on Microblaze, and Microblaze has BR2_ARCH_HAS_ATOMICS=y.

So while I agree that Strongswan is indeed using atomic intrinsics, it
isn't going to fix the issue.

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

[Buildroot] [PATCH] strongswan: needs atomics

[Gustavo Zacarias]

On 04/08/2015 04:22 PM, Thomas Petazzoni wrote:

> Hum, I don't quite see how this change can fix the build issue. The
> build issue is on Microblaze, and Microblaze has BR2_ARCH_HAS_ATOMICS=y.
> 
> So while I agree that Strongswan is indeed using atomic intrinsics, it
> isn't going to fix the issue.

The real problem is that we declared that microblaze has atomics when it
doesn't. All of the __atomic_compare_and_exchange_? functions for
microblaze live in libatomic, which is a clear indication that it has no
native atomics support whatsoever.
Regards.

[Buildroot] [PATCH] strongswan: needs atomics

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Wed, 08 Apr 2015 17:19:09 -0300, Gustavo Zacarias wrote:
> On 04/08/2015 04:22 PM, Thomas Petazzoni wrote:
> 
> > Hum, I don't quite see how this change can fix the build issue. The
> > build issue is on Microblaze, and Microblaze has BR2_ARCH_HAS_ATOMICS=y.
> > 
> > So while I agree that Strongswan is indeed using atomic intrinsics, it
> > isn't going to fix the issue.
> 
> The real problem is that we declared that microblaze has atomics when it
> doesn't. All of the __atomic_compare_and_exchange_? functions for
> microblaze live in libatomic, which is a clear indication that it has no
> native atomics support whatsoever.

Does BR2_ARCH_HAS_ATOMICS says if the HW itself has atomics or if
generally atomic operations are available in the compiler? I would say
the latter, since this is actually what we care about.

But atomic handling is clearly an area that requires some
clarification, as there are still some autobuilder failures that we are
not able to solve due to bad handling of atomic related dependencies.

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

[Buildroot] [PATCH] strongswan: needs atomics

[Gustavo Zacarias]

On 04/08/2015 05:40 PM, Thomas Petazzoni wrote:

> Does BR2_ARCH_HAS_ATOMICS says if the HW itself has atomics or if
> generally atomic operations are available in the compiler? I would say
> the latter, since this is actually what we care about.
> 
> But atomic handling is clearly an area that requires some
> clarification, as there are still some autobuilder failures that we are
> not able to solve due to bad handling of atomic related dependencies.

I'd venture to say the first (hardware has atomics) - that's what it
means right now because:

1) We don't handle libatomic, which is the fallback if HW doesn't do it.
This would entail adding LIBS="-latomic" for autotools packages, and
things are magically fixed.

2) We don't copy libatomic (patches sent), so we can't do 1 just yet.

So basically we should rename the whole thing.
BR2_ARCH_HAS_ATOMICS isn't precise, we need to formulate this probably
as BR2_ARCH_NEEDS_LIBATOMIC since AFAIK the fallback is mandatory, while
copying it for the toolchains.
We could have BR2_TOOLCHAIN_HAS_ATOMICS to point towards
toolchains/architectures that don't provide atomics and a fallback.
It also means that packages that were previously excluded can, in fact,
be used anyway as long as libatomic is thrown to the mix.

Regards.

[Buildroot] [PATCH] strongswan: needs atomics

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Wed, 08 Apr 2015 18:15:51 -0300, Gustavo Zacarias wrote:

> I'd venture to say the first (hardware has atomics) - that's what it
> means right now because:
> 
> 1) We don't handle libatomic, which is the fallback if HW doesn't do it.
> This would entail adding LIBS="-latomic" for autotools packages, and
> things are magically fixed.
> 
> 2) We don't copy libatomic (patches sent), so we can't do 1 just yet.
> 
> So basically we should rename the whole thing.
> BR2_ARCH_HAS_ATOMICS isn't precise, we need to formulate this probably
> as BR2_ARCH_NEEDS_LIBATOMIC since AFAIK the fallback is mandatory, while
> copying it for the toolchains.
> We could have BR2_TOOLCHAIN_HAS_ATOMICS to point towards
> toolchains/architectures that don't provide atomics and a fallback.
> It also means that packages that were previously excluded can, in fact,
> be used anyway as long as libatomic is thrown to the mix.

Thanks for the summary.

How do you handle Blackfin, which uses gcc 4.3, while I believe
libatomic is a new thing in gcc 4.8, no?

Are you sure all atomic intrinsics are tied to the existence of
libatomic? It's quite hard to find some good documentation on the web
about libatomic.

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

[Buildroot] [PATCH] strongswan: needs atomics

[Gustavo Zacarias]

On 04/08/2015 06:22 PM, Thomas Petazzoni wrote:

> Thanks for the summary.
> 
> How do you handle Blackfin, which uses gcc 4.3, while I believe
> libatomic is a new thing in gcc 4.8, no?
> 
> Are you sure all atomic intrinsics are tied to the existence of
> libatomic? It's quite hard to find some good documentation on the web
> about libatomic.

Experimental evidence says that if it's hardware supported you don't
need libatomic, for the rest you do.
The problem is some bits may be, others may not.
Example: i386, mips, mipsel, they do the up-to-32-bits stuff but need
libatomic for 64+ bits.
Regards.