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

[Brendan Heading]

Thomas, Yann,

>>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/98fd1c9a3f92d2354fe3bd9c233916f720e26234/
>>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/7ce7267bdc4da3bd0069cec49b8286316d220cd9/
>>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/3ebe4454210fb257af08a0ca9cd13844d6985d58/
>>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/cf90773bcca2b0401135779a293af33dc9cf658b/
>
> Peter, what do you suggest we do about these issues for the release?
> Long-term, libtirpc will be changed to not use atomic builtins. But
> what do we do now? Mark libtirpc as not available on SPARCv8, and
> propagate the reverse dependency?

Can I suggest that you just leave it broken ? I suspect it's been
broken for a little while. The problem in libtirpc was a commit in
2011, which would have first been seen in stable release 0.2.3 in
2013. We jumped from 0.2.2 to 0.2.4 on 26 Jun 2014 (f2ac23454) so each
release since then will have had this problem. A simple workaround in
the short term is simply to turn off libtirpc on SPARC manually.

I've been talking to the devs about this. After some discussion
they've pretty much come to the view that the commit which added the
use of the atomic builtins to the library was a bad idea to start
with, as it exposed extra, needless functionality to the caller that
is not part of the TI-RPC API. So the plan at the moment is to remove
it entirely, which will fix our build bug here. This should fix a
number of other packages that fail on SPARC due to dependence on
libtirpc.

It will take another week or so to sort this out as we're waiting for
the person who committed the change in the first place (in 2011) to
return from vacation so he can comment on it. The fix should be ready
by the end of the month assuming no objections are raised.

>>          arm |                linux-pam-1.1.8 | NOK | http://autobuild.buildroot.net/results/e337d69420ad00b2cc4017d639a31803926f2353/
>
> musl build issue.

I have fixed most of this, nearly ready to submit a patch set once
I've tidied it all up. There are several further problems that also
have to be fixed. An additional headache is that the changes clash
with some of the existing patches.

Also, I've had to implement some functions that are missing from musl
entirely (by borrowing BSD implementations and conditionally
compiling). I know that Yann has been disabling musl support with
other packages that require this kind of change, so I'd be interested
to hear what the view is. linux-pam is a reasonably major component
and part of the justification for musl is to do with security ..

I will try to send an RFC patch tomorrow, it might take an iteration
or two to get it right. This might be a case where it is appropriate
to disable libpam + musl in the coming release.

regards

Brendan