All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Marek <mmarek@suse.cz>
To: Valentin Ochs <a@0au.de>
Cc: Roman Zippel <zippel@linux-m68k.org>,
	trivial@kernel.org, linux-kbuild@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] kconfig/kbuild: define _POSIX_C_SOURCE
Date: Tue, 19 Apr 2011 11:54:19 +0200	[thread overview]
Message-ID: <4DAD5BCB.8010604@suse.cz> (raw)
In-Reply-To: <20110410143153.GJ4663@erwin>

On 10.4.2011 16:31, Valentin Ochs wrote:
> On Sat, Apr 09, 2011 at 11:34:00PM -0400, Arnaud Lacombe wrote:
>> On Sat, Apr 9, 2011 at 10:09 PM, Valentin Ochs <a@0au.de> wrote:
>>> The three patched files use PATH_MAX without defining the required
>>> _POSIX_C_SOURCE feature test macro.  This prevents compilation with the
>>> musl libc.  The patch applies to 2.6.38.2.
>>>
>>> Changes since v1:
>>>  - fix scripts/kconfig/lex.zconf.c_shipped
>> this file is autogenerated from zconf.l, which should be updated as
>> well. I'm not sure how you searched for PATH_MAX, but you're still
>> missing `confdata.c' and `nconf.c'.

Yes, please fix the bison parser and run make GENERATE_PARSER=1
menuconfig to update the *_shipped files.


>> I had a quick look to different libc implementation, glibc and uClibc
>> default to _POSIX_C_SOURCE == 200112L, FreeBSD >8.0 defaults to
>> 200809L for >8.0, FreeBSD 7.x to 200112L.
> 
> I got the value I used from the Open Group System Interfaces
> specification, but the musl author said that 200112L would be fine too.

I suggest you use 200112L, so that it is a nop for glibc/uClibc builds.
Please also accompany it with a /* for PATH_MAX */ comment or so.

> 
>> None of these seems to requires _POSIX_C_SOURCE to define PATH_MAX, so
>> I'm not certain of the requirement of the change.
> 
> While I don't want to appear like a language lawyer, the specification
> says that 'all symbols required by POSIX.1-2008 to appear when the
> header is included shall be made visible' when an application defines
> _POSIX_C_SOURCE. I guess the musl author interprets that as 'if you
> don't define the feature test macros, you're not getting PATH_MAX.' This
> does not seem to be incorrect behaviour to me.

While I don't completely understand the motivation for such
super-pedantic libc implementation, the fact is that POSIX says one
should define this macro, so let's define it, it does not hurt us.

Michal

  reply	other threads:[~2011-04-19  9:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-10  2:09 [PATCH v2] kconfig/kbuild: define _POSIX_C_SOURCE Valentin Ochs
2011-04-10  2:09 ` Valentin Ochs
2011-04-10  3:34 ` Arnaud Lacombe
2011-04-10 14:31   ` Valentin Ochs
2011-04-10 14:31     ` Valentin Ochs
2011-04-19  9:54     ` Michal Marek [this message]
2011-04-19 17:03       ` Arnaud Lacombe
2011-04-19 17:07         ` Arnaud Lacombe

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=4DAD5BCB.8010604@suse.cz \
    --to=mmarek@suse.cz \
    --cc=a@0au.de \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trivial@kernel.org \
    --cc=zippel@linux-m68k.org \
    /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.