Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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