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
next prev parent reply other threads:[~2011-04-19 9:54 UTC|newest]
Thread overview: 6+ 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 3:34 ` Arnaud Lacombe
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox