> -----Original Message----- > From: Khem Raj [mailto:[email protected]] > Sent: den 1 augusti 2010 10:48 > To: Peter Kjellerstedt > Cc: [email protected] > Subject: Re: [patch] avoid c99 declaration > > On Sun, Aug 1, 2010 at 1:35 AM, Peter Kjellerstedt > <[email protected]> wrote: > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of Khem Raj > >> Sent: den 1 augusti 2010 10:11 > >> To: Peter Kjellerstedt > >> Cc: [email protected] > >> Subject: Re: [patch] avoid c99 declaration > >> > >> On Sat, Jul 31, 2010 at 11:22 PM, Peter Kjellerstedt > >> <[email protected]> wrote: > >> >> -----Original Message----- > >> >> From: [email protected] > >> >> [mailto:[email protected]] On Behalf Of Mike Frysinger > >> >> Sent: den 1 augusti 2010 04:08 > >> >> To: [email protected] > >> >> Subject: Re: [patch] avoid c99 declaration > >> >> > >> >> On Saturday, July 31, 2010 16:22:35 Khem Raj wrote: > >> >> > On Tue, Jul 27, 2010 at 11:37 PM, Carmelo AMOROSO wrote: > >> >> > > On 7/28/2010 7:51 AM, Mike Frysinger wrote: > >> >> > >> On Monday, June 21, 2010 06:39:12 Gianluigi Tiesi wrote: > >> >> > >>> While compiling uClibc inside openwrt build system I > >> >> > >>> have somehow the compiler without -std=c99 flash (since > >> >> > >>> adding id causes me some troubles) > >> >> > >> > >> >> > >> why dont we fix uClibc to use c99 then ? if your toolchain > >> >> > >> is new enough to support TLS as NPTL requires, then it's > >> >> > >> new enough to support c99 features. we shouldnt go throwing > >> >> > >> frivolous patches at the NPTL code when we're merely > >> >> > >> importing it from glibc. realistically, we dont have the > >> >> > >> man power to maintain a fork which means we need to be > >> >> > >> sticking as lose to glibc as possible here. > >> >> > > > >> >> > > I definitely agree with Mike. Even if changes are dummy, > >> >> > > merging effort with updated version of NPTL/glibc could be > >> >> > > too huge. > >> >> > > >> >> > yes I agree. I proposed to make C99 a requirement for uclibc. > >> >> > >> >> i'm not necessarily set on all of uClibc, but certainly any part > >> >> that utilizes TLS. i guess we could enable -std=gnu99 in the > >> >> build and see who (if any) complains. > >> >> > >> >> if no one has anything else, i'll revert the changes in > >> >> question and add -std=gnu99. > >> >> -mike > >> > > >> > You already have this in Rules.mak: > >> > > >> > CPU_CFLAGS-y += $(call check_gcc,-std=gnu99,) > >> > > >> > so C99 should already be a requirement (at least for gcc)... > >> > >> No. its only turned on if gcc supports it. what I proposed was to > >> have it turned on always. > > > > And if the compiler does not support it, how do you propose to > > turn it on? > > huh? if C99 is a requirement then you better use a compiler > that supports it.
What I meant was that -std=gnu99 is a gcc specific option. However, as Bernhard mentioned, gcc is needed in practice to compile uClibc, so then that is not a problem any more. > thats what is meant with adding a c99 requirement to uclibc. > > I thought gcc is not the only compiler used to compile > > uClibc, but I may be wrong as I never used anything other than > > gcc myself. > > c99 is not a gcc standard its a ISO C language standard gcc is one of > the compilers that support it. Of course. However, _how_ to require C99 is compiler specific. //Peter _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
