On Fri, 29 Nov 2024, Prathamesh Kulkarni wrote: > > My expectation is that CFLAGS should not be modified until after > > save_CFLAGS is set, which should not be until after configure has > > executed the logic that sets a -g -O2 default. Is there some problem > > with that ordering (e.g. configure tests that expect to link target > > programs but run as part of the same Autoconf macro invocation that > > also generates the logic to determine default values)? Also, the > It seems that in configure, AC_PROG_CC expands to setting "-g -O2" in CFLAGS, > and running conftests using those CFLAGS, and any adjustments to CFLAGS after > invoking AC_PROG_CC don't help. > In the attached patch, I simply moved save_CFLAGS and CFLAGS before invoking > AC_PROG_CC, > and adding "-fno-link-libatomic" to CFLAGS, which seems to work, but not sure > if it's the correct approach ?
I don't think having those settings before the default from AC_PROG_CC is logically right, because the default from AC_PROG_CC only applies if CFLAGS is not already set (that is, you'd lose the default -g -O2, if libatomic/configure is run without CFLAGS set). The underlying principle is that CFLAGS is a variable for the *user* to set as they wish, not something that should be used for any options required as part of the build (that's what other things such as XCFLAGS and AM_CFLAGS are for). So if you need to modify CFLAGS in configure for use as part of configure tests, it should only be done temporarily in a way that doesn't interfere with the normal logic to determine that default setting. If for some reason that doesn't work (if AC_PROG_CC also runs tests that need modified CFLAGS, giving nowhere you get modify the value between the default being set and it being used), you'd need an assertion that libatomic/configure didn't get run with unset CFLAGS so the default wouldn't be applicable anyway, with appropriate comments explaining the issues. -- Joseph S. Myers josmy...@redhat.com
