From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: buildroot@busybox.net
Subject: [Buildroot] [arc-buildroot] [autobuild.buildroot.net] arc build results for 2015-06-28
Date: Wed, 8 Jul 2015 14:48:06 +0000 [thread overview]
Message-ID: <1436366885.3043.31.camel@synopsys.com> (raw)
In-Reply-To: <20150708163639.44ba74d5@free-electrons.com>
Hi Thomas,
On Wed, 2015-07-08 at 16:36 +0200, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,
>
> On Wed, 8 Jul 2015 14:33:36 +0000, Alexey Brodkin wrote:
>
> > Ok I now see the difference.
> >
> > [1] Toolchain that builds "empty" successfully is based on uClibc-0.9.33.2
> > which simply doesn't have "uClibc_posix_opt.h" where _POSIX_SEMAPHORES
> > is undefed in more recent versions of uClibc be it uClibc-ng or up to date uClibc
> > (tip of upstream uClibc's master branch in case of ARC).
> >
> > See commit that happened 1 month after 0.9.33.2 was cut:
> > http://git.uclibc.org/uClibc/commit/libc/sysdeps/linux/common/bits/uClibc_posix_opt.h?id=2389017f787dd51e11e697c4480
> > 71ec
> > dd217169a
> >
> > In that commit "uClibc_posix_opt.h" was introduced and since then "empty"
> > won't built without threads.
> >
> > Mystery solved? :)
>
> Thanks for the investigation!
>
> To conclude, I think marking the empty package as not available when
> thread support is not there is probably the easiest/simplest solution.
> What do you think?
I'd agree with that point, i.e. making "empty" dependent on threads support in toolchain
is the simplest approach for us.
But what bothers me a little bit I am frankly not completely sure if "empty" really needs
threads. Actually it forks a brand new process instead of creating new (p)thread.
And then semaphores are used for IPC between processes.
So if uClibc requires pthread library for implementation of semaphores, then "empty"
is really dependent on threads. And from the first glance I'd say that's the case.
Otherwise we may simply patch "empty".
Adding Waldemar who might comment on that.
-Alexey
next prev parent reply other threads:[~2015-07-08 14:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150629063017.4326F10013E@stock.ovh.net>
2015-07-06 14:51 ` [Buildroot] [arc-buildroot] [autobuild.buildroot.net] arc build results for 2015-06-28 Alexey Brodkin
2015-07-06 15:43 ` Thomas Petazzoni
2015-07-08 12:15 ` Alexey Brodkin
2015-07-08 12:29 ` Thomas Petazzoni
2015-07-08 14:33 ` Alexey Brodkin
2015-07-08 14:36 ` Thomas Petazzoni
2015-07-08 14:48 ` Alexey Brodkin [this message]
2015-07-09 0:13 ` Waldemar Brodkorb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1436366885.3043.31.camel@synopsys.com \
--to=alexey.brodkin@synopsys.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox