On Friday, August 31 2018, Tom Tromey wrote: >>>>>> "Sergio" == Sergio Durigan Junior <sergi...@redhat.com> writes: > >>>> "CC=$(CC)" \ >>>> "CFLAGS=$(CFLAGS)" \ >>>> "CXX=$(CXX)" \ >>>> "CXX_DIALECT=$(CXX_DIALECT)" \ >>>> "CXXFLAGS=$(CXXFLAGS)" \ >>>> ... > >>>> Which ends up overriding gnulib's CC/CXX variables. That's why we don't >>>> see the "-std=gnu11" there. > >>> Maybe the solution can be inspired by the line of thought Paul started >>> in [1]. Namely: >>> Define a *small* set of variables that influence the configure >>> results. Currently these are CC, CFLAGS, LDFLAGS, but not CPPFLAGS. >>> Then, can we define a set of variables that can be passed down from the >>> top-level Makefile the subordinate Makefiles? >>> These two sets of variables must be disjoint, and that is the problem >>> here, because users would like to use CFLAGS to pass optimization and >>> debugging flags down the build tree, after the configuration is complete. > > Sergio> I'm still inclined to go the "easy way" and do what I proposed above: > Sergio> create a "FLAGS_TO_PASS_TO_GNULIB" which would omit the CC/CXX (and > Sergio> possibly other) variables, even if it's just to unbreak the s390x > build > Sergio> (I still have a gnulib issue happening with mingw to investigate, > sigh). > > Historically the GNU and/or configure and/or automake rule was that > variables like CC, CXX, CFLAGS (etc) were for users. So, following this > rule, I think it's correct for gdb to pass these to sub-configures and > sub-makes.
Hm, fair enough. Actually, after experimenting with this yesterday, I found that it's not enough to remove CC/CXX from the list of variables passed down to gnulib. I still haven't found a fix for this problem. > I haven't looked at the gnulib code here, but it seems to me that if > gnulib wants to find special compiler flags to build itself, then I > think those should be stuck into some other-named variable, not CFLAGS. > gdb does this itself as well, for example warning flags aren't added to > CXXFLAGS but some other variable. In automake the convention is to name > these internal things AM_mumble, like AM_CFLAGS. There's some > discussion in (info "(automake) Flag Variables Ordering") That's a good idea. I'd like to know what the gnulib folks think of it. I'll try to take a look at the gnulib code and see if I can come up with a patch for this. Also, Paul Eggert suggested something yesterday: Another possibility that may be simpler for GDB, is to change its configure.ac files to require C99 or later everywhere. At this point it's more trouble than it's worth to tweak source code or makefiles to cater to compilers operating in C89 mode. Just tell your C compiler to support C99-or-better everywhere, and your life will surely be simpler. I don't know if just requiring C99 or later would be enough to solve this problem, but it's something to consider for GDB, I think. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/
