[Buildroot] Analysis of build results for 2015-08-05

[Brendan Heading]

> So we really need to make more progress on fixing the musl issues, and
> find a solution for the SPARC atomic problem.

I'm doing a separate investigation into SPARC to identify all of the
packages that have the atomic issue, maybe we can track it with
bugzilla and come up with a structured approach to tackling it.

Some can be fixed relatively trivially, others need a bit more surgery
to add conditional compilation/detection/conditional linking of
libatomic.

It is worth highlighting that fixing these problems benefits other
architectures, as there are a number of the less mainstream ones that
lack full atomic support.

>>        sparc |                   boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/14591f0ce708f68f925c9223471b3c4f0ddb9eef/
>
>  error: #error "platform not supported"
>
> Pff, why do we care about SPARC ?

I keep asking that question .. :)

>>       x86_64 |                  clapack-3.2.1 | NOK | http://autobuild.buildroot.net/results/66fa17376cbb05351988e7ef0dc0c232bbd19f2d/
>
> musl build problem:

This one is non-trivial to fix. The part that includes fpu_control.h
can be conditionally compiled out, but there are lots of other
glibc-isms (missing header files).

According to the maintainer site, the code is generated by some kind
of Fortran-to-C converter, so upstream patches may be an issue.

>>          arm |                linux-pam-1.1.8 | NOK | http://autobuild.buildroot.net/results/c865d16a7f878f2ecc52c30f285c43e5cf45bdcc/
>>       x86_64 |                linux-pam-1.1.8 | NOK | http://autobuild.buildroot.net/results/4dfd26c01fb8d64b2793402b7ebdc2992ee5a54d/
>
> musl build problem:
>
>    error: '_PATH_LASTLOG' undeclared (first use in this function)

I am preparing a patch series for this. It's also non-trivial - the
macros can be fixed but then you run into a problem with musl lacking
an implementation of logwtmp(). The musl maintainers say they won't
implement this for security reasons, unless someone can provide a
justification that they will accept, so my patch steals an
implementation of it from OpenBSD's libc and supplies it as a
conditionally compiled static function.

>>        sparc |                 moarvm-2015.05 | NOK | http://autobuild.buildroot.net/results/063b8e47a39eef601fe6d7d9578a64216c8eccb6/
>
> /tmp/ccrWqi6b.s: Assembler messages:
> /tmp/ccrWqi6b.s:187: Error: Architecture mismatch on "membar".
> /tmp/ccrWqi6b.s:187:  (Requires v9|v9a|v9b; requested architecture is v8.)
> /tmp/ccrWqi6b.s:188: Error: Architecture mismatch on "cas".
> /tmp/ccrWqi6b.s:188:  (Requires leon|v9|v9a|v9b; requested architecture is v8.)
> /tmp/ccrWqi6b.s:189: Error: Architecture mismatch on "membar".
> /tmp/ccrWqi6b.s:189:  (Requires v9|v9a|v9b; requested architecture is v8.)
> make[1]: *** [src/core/threads.o] Error 1
>
> Pff, why do we care about SPARC, again? If nobody sends a patch for
> this, I'll just mark moarvm as not available on SPARC.

This error is very similar to the problem with libpthsem on SPARC that
I was debating with Yann earlier this week. On libpthsem, the
configure script is implemented in such a way that it doesn't support
cross-compilers. If it's the same issue it can probably be fixed by
adding forced defaults in the configure section (although I haven't
checked).

Brendan