passing command-line arguments

passing command-line arguments

[James K. Lowden]

https://git.symas.net:443/cobolworx/gcc-cobol/

My first question regards command-line options.  I've had no trouble
defining switches (-f-foo), but no luck defining an option that takes
an argument.  The latter are accepted by gcobol and not passed to
cobol1.  

In cobol/lang.opt, I have:

indicator-column
Cobol Joined Separate UInteger Var(indicator_column) Init(0)
IntegerRange(0, 8) -indicator-column=<n>	Column after which
Region B begins

strace(1) shows the problem:

[pid 683008] execve("../../../build/gcc/gcobol",
["../../../build/gcc/gcobol", "-main", "-o", "obj/SG105A", "-B",
"../../../build/gcc/", "-f-flex-debug", "-f-yacc-debug",
"-indicator-column", "1", "cbl/SG105A.cbl", "-lgcobol", "-lm", "-ldl"],
0x55a19b487940 /* 36 vars */ <unfinished ...>

gcobol is being invoked with 3 options used by cobol1:
      "-f-flex-debug", "-f-yacc-debug", "-indicator-column", "1"

where -indicator-column takes an argument, "1".  But it's not  passed to
cobol1: 

[pid 683008] <... execve resumed>)      = 0
[pid 683009] execve("../../../build/gcc/cobol1",
["../../../build/gcc/cobol1", "cbl/SG105A.cbl", "-quiet", "-dumpbase",
"SG105A.cbl", "-main", "-mtune=generic", "-march=x86-64", "-auxbase",
"SG105A", "-f-flex-debug", "-f-yacc-debug", "-o", "/tmp/ccIBQZv1.s"],
0x1578290 /* 40 vars */ <unfinished ...>

The stanza in cobol/lang.opt looks similar to others in
fortran/lang.opt. The gcc internals don't mention anything else that I
could find that needs to be done.  I've done a complete rebuild after
"make distclean".  And still no joy.

We are working with a gcc fork of 10.2.  Our log message says (in part):

    The "tiny" branch was started with the 10.2.1
origin/releases/gcc-10 branch> c806314b32987096d79de21e72dc0cf783e51d57)

What am I missing, please?

--jkl

Re: passing command-line arguments

[Jonathan Wakely]

On Wed, 16 Mar 2022, 00:37 James K. Lowden, <jklowden@schemamania.org>
wrote:

>
> I've done a complete rebuild after
> "make distclean".  And still no joy.
>

Not an answer to your question (sorry), but it's more reliable to just
remove the entire build directory and rebuild in a new, empty directory.
The 'clean' and 'distclean' targets are created by automake but not really
maintained (or used) by anybody.

You should be building outside the source tree in a dedicated build
directory anyway, so just removing the whole thing is easy and doesn't
affect the source tree.

https://gcc.gnu.org/wiki/FAQ#configure