[Buildroot] Analysis of build results for 2015-11-18

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Hello,

On Fri, 20 Nov 2015 12:29:49 -0300, Gustavo Zacarias wrote:

> Hi, yes, it needs both.
> For wchar it's mandatory, for threads it could be optional but isn't 
> because the default for sqlite (bundled) is threads on for *nixes and 
> the decision can be changed from configure (which is missing).
> It's probably not worth the effort/testing to make them optional.

Agreed, trying to make thread support optional is not super useful for
such package.

> I already have a bump to 3.18 in the pipe.
> For now i'd say ignore this, even if it builds it doesn't work at 
> runtime since the wayland/weston xdg api level != gtk3.
> This happened when wayland/westion were bumped, the API level was raised 
> with it, but gtk3 wasn't, hence it's in a previous level.
> Mental note for the future: wayland/weston bumps may be tied to gtk3.
> The gtk3 bump isn't 100% clean right now (WIP) and tinkers somewhat 
> heavily in other packages, so it's material for the 2016.02 release.
> Unfortunately this means we'll ship a known-broken combo (gtk3 with 
> wayland).

Can you provide a patch that disables the wayland back of libgtk3 in
order to avoid this build failure ?

> >> microblazeel |                  mesa3d-11.0.4 | NOK | http://autobuild.buildroot.net/results/5b50695350b48cff6ac2eecd4cf9d7b2fb5c1beb/
> >
> > ./.libs/libglsl.a(glsl_parser_extras.o): In function `_mesa_glsl_compile_shader':
> > (.text+0x3588): undefined reference to `__sync_val_compare_and_swap_1'
> >
> > I'm tempted to simply mark mesa3d as not available on microblaze. Bernd, any suggestion?
> 
> This is in the bag of "arch needs libatomic" together with strongswan 
> for microblaze.
> 
> >> sparc |                    mpd-0.19.11 | NOK | http://autobuild.buildroot.net/results/8dcf5f73904de835bf66c46747cd544efc9d3a22/
> >
> > undefined reference to `__atomic_fetch_or_4'
> >
> > Waldemar, can you have a look ?
> 
> SPARC (v8, 32 bits) doesn't have atomics at all, libatomic, again could 
> fit the bill. It may be inherited from somewhere else like boost.

We really need to find a plan to solve this atomic thing. I still
haven't gotten a full understanding of how this atomic mess is handled,
so it's hard to lay out a plan. Anyone else?

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