[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Gustavo,

On Wed, 22 Jul 2015 09:30:46 -0300, Gustavo Zacarias wrote:

> That's exactly the problem, though in your previous mail you had a 
> slight conceptual slip, libatomic is provided by gcc itself.
> libatomic is provided to provide (sic!) fallback atomic operations, 
> usually implemented via a lock.
> SPARC v8 doesn't provide lockless atomics, it needs stbar trickery.
> v9+ does implement them via membar (TSO), see:
> http://www.oracle.com/technetwork/server-storage/solaris10/index-142944.html
> 
> Long story short not every architecture provides the necessary atomics 
> for all packages (sparc v8 being the "none"), since there are varying 
> sizes (bits=8,16,32,64 normally).
> 
> A failure example would be building libglib2 for i386 which doesn't have 
> them either, though glib captures this rather than failing later:
> 
> checking for lock-free atomic intrinsics... configure: error: GLib must 
> be build with -march=i486 or later.
> 
> Another example is the trick i'm doing for the new webkit version and 
> some arch combinations:
> 
> # Some 32-bit architectures need libatomic support for 64-bit ops
> ifeq ($(BR2_i386)$(BR2_mips)$(BR2_mipsel)$(BR2_sh),y)
> WEBKITGTK24_CONF_ENV += LIBS="-latomic"
> endif
> 
> So adding libatomic to LIBS normally "fixes" the problem, but enabling 
> it on a global-scale doesn't look that great, and each package has a 
> different set of requirements depending on the atomics size it uses.
> (example: microblaze and strongswan = 8 bits).

Ok, thanks for the summary. If I summarize it another way:

 * Some packages use atomic operations, operating on values of
   different sizes

 * Some architectures implement all the atomic operations in a built-in
   way, but some architectures need libatomic to be linked in to
   provide the atomic operations on certain value sizes.

> We could "declare" each package atomics needs via selects and throw 
> libatomic into some variable in the package infrastructure, that's the 
> best i could think of so far - but it's some work, which sparc could 
> help test because it generally needs it ;)

I don't think packages should declare atomics needs via selects,
because we certainly don't want to link all packages with libatomic if
they don't need that.

However, the architectures could declare through selects which atomic
operations they have, and then packages needing operations of a given
size could use those hidden options to decide whether they should link
against libatomic or not. Like:

config BR2_ARCH_HAS_1_BYTE_ATOMIC
	bool

config BR2_ARCH_HAS_2_BYTES_ATOMIC
	bool

config BR2_ARCH_HAS_4_BYTES_ATOMIC
	bool

config BR2_ARCH_HAS_8_BYTES_ATOMIC
	bool

and then in a package:

ifeq ($(BR2_ARCH_HAS_8_BYTES_ATOMIC),)
FOO_LIBS += -latomic
endif

FOO_CONF_ENV = LIBS="$(FOO_LIBS)"

*Or*, maybe better, we fix those packages so that they do the right
configure.ac test and automatically link with libatomic if needed.
Probably this is what glib should do, for example. This reduces the
crap in Buildroot, and allows to push the solution to the upstream
projects. I don't think that many packages have atomic operations
requirements, so it should not be a horrible effort.

Thoughts?

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