All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baruch Siach <baruch@tkos.co.il>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] Raspberry Pi - WiringPi Library Package
Date: Fri, 12 Jul 2013 09:47:49 +0300	[thread overview]
Message-ID: <20130712064749.GJ4338@tarshish> (raw)
In-Reply-To: <20130712043056.GA9929@enterprise.localdomain>

Hi Guillermo,
On Thu, Jul 11, 2013 at 09:30:56PM -0700, Guillermo Amaral wrote:
> On Fri, Jul 12, 2013 at 06:24:30AM +0300, Baruch Siach wrote:
> > On Thu, Jul 11, 2013 at 11:22:58AM -0700, Guillermo Amaral wrote:
> > > On Thu, Jul 11, 2013 at 09:06:03PM +0300, Baruch Siach wrote:
> > > > On Thu, Jul 11, 2013 at 10:55:30AM -0700, Guillermo Amaral wrote:
> > > > > The Raspberry Pi doesn't go down to 2.6.y, the oldest supported version is
> > > > > 3.2.27. :)
> > > > 
> > > > If this is the case, then there is no reason to make O_CLOEXEC a no-op.
> > > > 
> > > > > So there should be no need to do the kernel check, since the package is RPi
> > > > > specific.
> > > > > 
> > > > > The problem here was that O_CLOEXEC was not defined with the default uclibc
> > > > > and older versions of glibc.
> > > > 
> > > > The O_CLOEXEC define comes with the kernel headers used to build the 
> > > > toolchain, not from the C library.
> > > 
> > > I didn't say it didn't. I'll clarify, if __USE_GNU and/or __USE_XOPEN2K8 don't
> > > get defined at some point O_CLOEXEC is not getting defined. My guess is that
> > > they get defined by *libc, feel free to correct me if I'm wrong.
> > 
> > The code below builds just fine on my machine:
> > 
> > #include <sys/types.h>
> > #include <sys/stat.h>
> > #include <fcntl.h>
> > 
> > void func(void) { open("f", O_RDWR | O_CLOEXEC); }
> 
> Congratulations, I'm very proud. Have a beer on me! (B)
> 
> G
> 
> P.S.
> 
> $ host/usr/bin/arm-linux-gcc -c x.c
> x.c: In function ?func?:
> x.c:5:38: error: ?O_CLOEXEC? undeclared (first use in this function)
> x.c:5:38: note: each undeclared identifier is reported only once for each
> function it appears in
> 
> $ cat x.c
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> 
> void func(void) { open("f", O_RDWR | O_CLOEXEC); }

And does defining __USE_GNU and/or __USE_XOPEN2K8 improves the situation?

My point is that the existence of O_CLOEXEC at build time is determined by the 
version of the kernel headers in the toolchain. At run time, O_CLOEXEC is 
effective when the running kernel supports it. The toolchain you are using is 
based on on old kernel headers, so you need to define O_CLOEXEC yourself, 
which is fine. The kernel running on a Raspberry Pi should always be recent 
enough to support O_CLOEXEC. So the right solution, in my opinion, is to 
define O_CLOEXEC to its real value.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

  reply	other threads:[~2013-07-12  6:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAPeEpDpMY2sRjGdd+TgPz5S--Pws+5hUNrV8jpiznxBqFZ7zDg@mail.gmail.com>
2013-07-11  5:17 ` [Buildroot] [PATCH] Raspberry Pi - WiringPi Library Package Guillermo A. Amaral
2013-07-11  5:19   ` Guillermo A. Amaral
2013-07-11  5:33     ` Baruch Siach
2013-07-11  6:00       ` Guillermo A. Amaral
2013-07-11  6:04         ` Baruch Siach
2013-07-11  6:38           ` Guillermo A. Amaral
2013-07-11  7:42             ` Carsten Schoenert
2013-07-11 17:55               ` Guillermo Amaral
2013-07-11 18:06                 ` Baruch Siach
2013-07-11 18:22                   ` Guillermo Amaral
2013-07-12  3:24                     ` Baruch Siach
2013-07-12  4:30                       ` Guillermo Amaral
2013-07-12  6:47                         ` Baruch Siach [this message]
2013-07-12  6:54                           ` Guillermo A. Amaral
2013-07-10  7:12 Guillermo A. Amaral
2013-07-10  9:26 ` Thomas Petazzoni

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=20130712064749.GJ4338@tarshish \
    --to=baruch@tkos.co.il \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.