On Tue, Nov 11, 2025 at 6:14 AM James K. Lowden <[email protected]> wrote: > > I'm having some difficulty getting specs up to spec. > > 1. gcobol --help produces much less than promised > 2. -foo=arg doesn't work > 3. -exec-charset becomes -e xec-charset > > I suspect there are knobs I haven't turned. This work is in > preparation for a much larger effort to support -Werror. > > gcobol --help produces much less than promised: > > $ gcobol --help | awk '/Options specific/,/^$/ { if( /^ +-/ > ) {print; n++}} END{ print n, "options"}' -main option uses the first > PROGRAM of filename as the entry point for -no_main > -findicator-column > -ffixed-form > -ffree-form > -fmax-errors nerror > -fflex-debug, -fyacc-debug > 7 options > > Notably absent is -dialect, but there are many others. > > I can explain that, and I cannot. The text comes from > > gcobolspec.cc::lang_specific_driver() > > Static text is output in answer to "case OPT__help:". But is that > supposed to be necessary. Someone, maybe me, inserted a comment, > > /* Let gcc.cc handle this, as it has a really > cool facility for handling --help and --verbose --help. */ > > What is supposed to work? There are allusions in gccint.info about > "help text" being generated, but there's no "help" entry in the index. > > Perhaps related, as I read gccint.info, there's nothing special I need > to do to get support for -option=arg, but it seems there must be. > > This works: > > $ gcobol -oo failures/jkl/bob.cbl -dialect mf -v 2>&1 | > sed /mf/q Driving: (15) > [ 0] 2292 /home/jklowden/projects/3rd/gcc/unicode/build/gcc/gcobol > [ 1] 429 -B/home/jklowden/projects/3rd/gcc/unicode/build/gcc > [ 2] 2145 -oo > [ 3] 2090 -main=failures/jkl/bob.cbl > [ 4] 2293 failures/jkl/bob.cbl > [ 5] 995 -dialect mf > > This does not: > > $ gcobol -oo failures/jkl/bob.cbl -dialect=mf > gcobol: error: Unrecognized COBOL dialect name: ?=mf? > gcobol: note: valid arguments to ?-dialect? are: gcc gnu ibm mf; did > you mean ?mf?? > > Finally, my initial attempt to handle -exec-charset came to tears. > Specs now has: > > [...] > {"@cobol", > "cobol1 %i %(cc1_options) " > "%{D*} %{E} %{I*} %{M} %{fmax-errors*} %{fsyntax-only*} " > "%{fcobol-exceptions*} " > "%{copyext} " > "%{exec-charset*} " > "%{exec-national-charset*} " > "%{fstatic-call} %{fdefaultbyte} " > "%{ffixed-form} %{ffree-form} %{indicator-column*} " > "%{preprocess} " > "%{dialect} " > "%{include} " > "%{nomain} " > "%{!fsyntax-only:%(invoke_as)} " > , 0, 0, 0}, > > and in lang.opt I added > > exec-charset > Cobol Joined Separate Var(cobol_charset) > ; Documented in c.opt > > While it's possible that lang_specific_driver() is gumming up the > works, it isn't being handed the right stuff: > > (gdb) p decoded_options[3] > $3 = { > opt_index = 1005, > warn_message = 0x0, > arg = 0xfffffffff549 "xec-charset", > orig_option_with_args_text = 0x7f9300 "-exec-charset", > canonical_option = {0x667c80 "-e", 0xfffffffff549 "xec-charset", 0x0, > 0x0}, canonical_option_num_elements = 2, > value = 1, > mask = 0, > errors = 0 > } > > It looks like the option is "-e" with the argument "xec-charset". [1]
Likely because there is e Driver Joined Separate in common.opt which conflicts. May I suggest to use -exec-charset instead? You'd then use --exec-charset ... I have no idea what -e is about or how to work around this conflict ... this option is undocumented. Removing 'Joined' from it would make it not take all of the 'e' "namespace" ... Joseph, do you by chance remember what this is about? Richard. > I don't see what I am doing to cause that. > > If this is just a matter of undocumented magic, I could fix that if I > knew what it was. :-) > > --jkl > > > [1] That was the trick troff used back in the day. To let the user say > > troff -man > > meaning, use the "man" macro package, the system actually had a '-m' > option that took a 'an' argument. > >
