https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #14 from rdubner at symas dot com --- > -----Original Message----- > From: iains at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> > Sent: Wednesday, April 9, 2025 11:19 > To: rdub...@gcc.gnu.org > Subject: [Bug cobol/119414] cobol driver unconditionally adds platform- > specific command line options. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414 > > --- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> --- > (In reply to rdubner from comment #11) > > COBOL comes from long ago, and far away. And the vast bulk of code that > I > > never forget is where my boss, paying my salary, hopes to someday > actually > > make some money as we support migration and conversion, is mainframe > code. > > And mainframe code operates on different assumptions than those expected > by > > people who are steeped in Unix-like platforms. > > > > (I am not a mainframe guy. But I don't think that the customs of the > Unix > > tribe constitute natural law, either.) > > I think the general idea of GCC is that it should run on as many platforms > as > possible, including mainframe-like, unix-like and Windows-like. > > > Here is the test program that first alerted me to the problem that I > tracked > > down to -rdynamic. > > > > > > IDENTIFICATION DIVISION. > > PROGRAM-ID. caller. > > PROCEDURE DIVISION. > > CALL "callee1" ON EXCEPTION > > CALL "callee2" ON EXCEPTION > > DISPLAY "neither callee1 nor callee2 found" > > END-CALL > > END-CALL > > GOBACK. > > END PROGRAM caller. > > IDENTIFICATION DIVISION. > > PROGRAM-ID. callee2. > > PROCEDURE DIVISION. > > DISPLAY "this is callee2" NO ADVANCING > > GOBACK. > > END PROGRAM callee2. > > > > The instruction CALL "callee1" ON EXCEPTION means that if "callee1" > can't be > > found, then execute the code following "ON EXCEPTION" until the > enclosing > > END-CALL is encountered. > > > > There is no callee1 to be found; there are no DSOs involved. As you can > see > > callee2 is part of the source code module. > > > > When compiled with "gcobol playpen.cbl", the result is a static linking > > error: > > > > /usr/bin/ld: /tmp/ccqZ2tzw.o: in function > > `_para._implicit_paragraph_5._initialize_program.caller.0.67': > > playpen.cbl:(.text+0x399): undefined reference to `callee1' > > A suggestion would be to ensure that every program ID _is_ exported > regardless > of whether there is a direct reference to it. It seems that those > constitute > the public symbols of the implementation. > > Question - do you expect the missing "callee1" to be a link-tim error - or > is > it permissible for it to be found at runtime? Without the -fno-static-call, the attempt to CALL "callee1", where "callee1" is a literal, we expect a link-time error. With the -fno-static-call, we explicitly do not expect a link-time error. COBOL allows for CALL "callee1" ON EXECPTION DISPLAY "Couldn't find 'callee1'" END-CALL > > I realize (from first hand experience) that it can be frustrating when one > asks > how to do X and the answer comes back "what is it that you want to > achieve" .. > but it's a common scenario with compiler-engineering ;) > > -- > You are receiving this mail because: > You are on the CC list for the bug.
