On Sep 1, 2012, at 1:38 PM, Alexander Hansen <alexanderk.han...@gmail.com> wrote:
> On 9/1/12 1:07 PM, Hanspeter Niederstrasser wrote: >> On 9/1/2012 10:32 AM, Alexander Hansen wrote: >>> On 8/31/12 5:36 PM, Jack Howarth wrote: >>>> Why exactly are we building the entirety of gettext-tools at -O0 >>>> in 10.7 branch when only a single source file, xgettext.c, is >>>> problematic on >>>> older clang? The previous patch that applied -O4 to the compilation >>>> of xgettext.c, >>>> should work fine using -O0 instead for just that file. >>>> >>>> >>>> --- gettext-0.18.1.1/gettext-tools/src/Makefile.in.orig 2012-08-31 >>>> 20:21:15.000000000 -0400 >>>> +++ gettext-0.18.1.1/gettext-tools/src/Makefile.in 2012-08-31 >>>> 20:22:03.000000000 -0400 >>>> @@ -2357,11 +2357,11 @@ >>>> >>>> xgettext-xgettext.o: xgettext.c >>>> $(AM_V_CC) @AM_BACKSLASH@ >>>> - $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) >>>> $(xgettext_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o >>>> xgettext-xgettext.o `test -f 'xgettext.c' || echo >>>> '$(srcdir)/'`xgettext.c >>>> + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) >>>> $(xgettext_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -O0 -c -o >>>> xgettext-xgettext.o `test -f 'xgettext.c' || echo >>>> '$(srcdir)/'`xgettext.c >>>> >>>> xgettext-xgettext.obj: xgettext.c >>>> $(AM_V_CC) @AM_BACKSLASH@ >>>> - $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) >>>> $(xgettext_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o >>>> xgettext-xgettext.obj `if test -f 'xgettext.c'; then $(CYGPATH_W) >>>> 'xgettext.c'; else $(CYGPATH_W) '$(srcdir)/xgettext.c'; fi` >>>> + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) >>>> $(xgettext_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -O0 -c -o >>>> xgettext-xgettext.obj `if test -f 'xgettext.c'; then $(CYGPATH_W) >>>> 'xgettext.c'; else $(CYGPATH_W) '$(srcdir)/xgettext.c'; fi` >>>> >>>> xgettext-x-c.o: x-c.c >>>> $(AM_V_CC) @AM_BACKSLASH@ >>>> >>>> Building everything at -O0 seems like massive overkill. >>>> Jack >>> >>> Don't cc stuff over multiple lists. There's no reason to do that and it >>> makes it easy to lose the discussion. >>> >>> Pretty much everybody on -core reads -devel, too >>> >>> And speaking of overkill, why raise the Revision? >> >> The revision needs to be raised because compiling at different -O level >> changes the deb. >> >> The change to everything at -O0 was mostly meant as a temporary solution >> when I was crafting the update to 0.18.1.1, but crept into the release. >> >> Hanspeter >> > > It changes the .deb, sure, but does the change actually have a practical > effect? Will users notice any difference in how the executables run, > since this isn't a library package? > Our traditional standard has been: if it changes the .deb, bump the revision. -- Dave ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
