> -----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)... //Peter _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
