> -----Original Message-----
> From: Richard Biener <richard.guent...@gmail.com>
> Sent: Tuesday, July 8, 2025 09:54
> To: Robert Dubner <rdub...@symas.com>
> Cc: Andreas Schwab <sch...@suse.de>; Rainer Orth <r...@cebitec.uni-
> bielefeld.de>; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] cobol: Implement CXXFLAGS_FOR_COBOL.
>
> On Tue, Jul 8, 2025 at 3:45 PM Robert Dubner <rdub...@symas.com> wrote:
> >
> > > -----Original Message-----
> > > From: Andreas Schwab <sch...@suse.de>
> > > Sent: Tuesday, July 8, 2025 03:16
> > > To: Robert Dubner <rdub...@symas.com>
> > > Cc: Rainer Orth <r...@cebitec.uni-bielefeld.de>; gcc-patches@gcc.gnu.org
> > > Subject: Re: [PATCH] cobol: Implement CXXFLAGS_FOR_COBOL.
> > >
> > > On Jul 07 2025, Robert Dubner wrote:
> > >
> > > > Furthermore, even if this method did work, I need the
> > CXXFLAGS_FOR_COBOL
> > > > options to appear at the end of the list, not the beginning, since
> > they
> > > > may need to override what came before.
> > >
> > > Why can't you use CXXFLAGS?
> >
> > Because CXXFLAGS applies to everything.
> >
> > Not long ago, we added code using std::size() to one of the gcc/cobol
> > files. Jim and I both use GCC-11, which in its default configuration
> > provides C++17 features. But somebody compiling using GCC-9 reported
> that
> > it led to a failure.
> >
> > So, in an attempt to find such things before committing them to
> > gcc/master, in my development environment I tried
> >
> > CXXFLAGS="-std-c++14" ../configure ...
> >
> > That leads to a build failure of libcody, with the message to the effect
> > of "libcody requires C++11".
>
> Still CXXFLAGS is the correct thing to do. And to fix that libcody
> requirement, of course. By simply dropping NMS_CXX_11 I'd say.
Although I am eager to try to move this along, I am not knowledgeable. Are
you suggesting that the entire section
AC_DEFUN([NMS_CXX_11],
in libcody/config.m4 (which seems to specify that -std= version has to be
exactly C++11) can be removed?
I did that, and ran autoreconf. I then attempted
CXXFLAGS="-std=c++14"
../configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib
That resulted in this set of errors:
../../../../libstdc++-v3/libsupc++/eh_alloc.cc: In constructor
‘{anonymous}::pool::pool()’:
../../../../libstdc++-v3/libsupc++/eh_alloc.cc:199:18: error: ‘string_view’
in namespace ‘std’ does not name a type
199 | const std::string_view ns_name = "glibcxx.eh_pool";
| ^~~~~~~~~~~
../../../../libstdc++-v3/libsupc++/eh_alloc.cc:199:13: note:
‘std::string_view’ is only available from C++17 onwards
199 | const std::string_view ns_name = "glibcxx.eh_pool";
| ^~~
../../../../libstdc++-v3/libsupc++/eh_alloc.cc:200:12: error: ‘pair’ is not
a member of ‘std’
200 | std::pair<std::string_view, int> tunables[]{
| ^~~~
../../../../libstdc++-v3/libsupc++/eh_alloc.cc:43:1: note: ‘std::pair’ is
defined in header ‘<utility>’; this is probably fixable by adding ‘#include
<utility>’
42 | # include <ext/concurrence.h> // __gnu_cxx::__mutex,
__gnu_cxx::__scoped_lock
+++ |+#include <utility>
43 | #endif
../../../../libstdc++-v3/libsupc++/eh_alloc.cc:200:22: error: ‘string_view’
is not a member of ‘std’
200 | std::pair<std::string_view, int> tunables[]{
| ^~~~~~~~~~~
../../../../libstdc++-v3/libsupc++/eh_alloc.cc:200:22: note:
‘std::string_view’ is only available from C++17 onwards
../../../../libstdc++-v3/libsupc++/eh_alloc.cc:200:35: error: expected
primary-expression before ‘int’
200 | std::pair<std::string_view, int> tunables[]{
| ^~~
../../../../libstdc++-v3/libsupc++/eh_alloc.cc:208:16: error: ‘ns_name’ was
not declared in this scope
208 | if (!ns_name.compare(0, ns_name.size(), str,
ns_name.size())
| ^~~~~~~
../../../../libstdc++-v3/libsupc++/eh_alloc.cc:212:28: error: ‘tunables’ was
not declared in this scope
212 | for (auto& t : tunables)
| ^~~~~~~~
../../../../libstdc++-v3/libsupc++/eh_alloc.cc:227:24: error: ‘min’ is not a
member of ‘std’; did you mean ‘minus’?
227 | obj_count = std::min(tunables[1].second, MAX_OBJ_COUNT); //
Can be zero.
| ^~~
| minus
../../../../libstdc++-v3/libsupc++/eh_alloc.cc:227:28: error: ‘tunables’ was
not declared in this scope
227 | obj_count = std::min(tunables[1].second, MAX_OBJ_COUNT); //
Can be zero.
I suppose I can create a PR pointing out that CXXFLAGS='-std=c++14' is
leading to errors.
This is exactly why I want to be able to affect gcc/cobol without touching
everything else. I want to make sure that our code is C++14 compliant,
without tripping over the possibility that some other code isn't.
This grows frustrating.
I have a need. I managed to satisfy that need by adding CXXFLAGS_FOR_COBOL.
The changes to configure.ac, Makefile.def, Makefile.tbl and
gcc/cobol/Make-lang.in are modest, and do not adversely affect any other
part of the build.
Rather than being able to move forward, I am being advised to try other
things (that so far don't work), or to research and develop other solutions
(that I don't understand), or being advised that a method that doesn't solve
my problem is actually the right way to go, even though it breaks the build
in ways I am not (because of time constraints and limitations on my
knowledge of GCC) able to fix.
This comes down to: I would really like to apply my working and tested
CXXFLAGS_FOR_COBOL solution.
>
> > I have been unable to find any method of doing a complete build while
> > setting compilation options that apply only to the gcc/cobol files. So,
> I
> > did the investigation, and created the patch.
> >
> > It operates as do some other flags, including CXXFLAGS:
> >
> > CXXFLAGS_FOR_COBOL=xxx ..configure ...
> >
> > results in gcc/Makefile and gcc/cobol/Makefile that uses xxx for files
> in
> > gcc/cobol, and for no other source code trees, in all subsequent builds
> > unless overridden with
> >
> > make CXXFLAGS_FOR_COBOL=yyy
> >
> > That's what we want. I have found no other way of doing it.
> >
> > >
> > > --
> > > Andreas Schwab, SUSE Labs, sch...@suse.de
> > > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA
> B9D7
> > > "And now for something completely different."
