Hi Thomas, On Tue, Dec 06, 2016 at 09:06:08PM +0100, Thomas De Schampheleire wrote: > On Wed, Nov 16, 2016 at 8:27 PM, Dmitry V. Levin wrote: [...] > > The correct fix is going to be more complex, e.g. > > - move all gl_WARN_ADD/WARN_CFLAGS related code from configure.ac to a > > separate m4 macro, say st_WARN_CFLAGS; > > - call st_WARN_CFLAGS in configure.ac; > > - modify AX_PROG_CC_FOR_BUILD to > > + pushdef WARN_CFLAGS to WARN_CFLAGS_FOR_BUILD, > > + call st_WARN_CFLAGS, > > + popdef WARN_CFLAGS back, > > + AC_SUBST WARN_CFLAGS_FOR_BUILD; > > - add WARN_CFLAGS_FOR_BUILD to AM_CFLAGS_FOR_BUILD. > > Thanks for the suggestion. > I tried implementing it but got stuck. What I observe is that the > second invocation of ST_WARN_CFLAGS is using cached results, which > should not happen because the compiler can be different. Looking at > the definition of gl_WARN_ADD, I think that the cache_id of the > AC_CACHE_CHECK call in gl_COMPILER_OPTION_IF should contain CC or a > similar variable, so that caching does not happen. > > I'm sending what I have for now below.
Yes, it appeared to be even more complicated than I expected. I've pushed a tentative fix to https://github.com/strace/strace/commits/ldv/WARN_CFLAGS_FOR_BUILD Please give it a try. I'm not quite happy with the change I made in m4/warnings.m4, though. The change of gl_Flags is just an ad hoc solution, and the tearing gl_UNKNOWN_WARNINGS_ARE_ERRORS off gl_WARN_ADD is not something I'd like to accept on gnulib side. -- ldv
pgplSMelyvBQk.pgp
Description: PGP signature
------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/xeonphi
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel