https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to rdubner from comment #14) > > -----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 that is the key piece of information - COBOL expects that the symbol might not be available (presumably, to be found in some other DSO) .. in which case Jakub's suggestion of using the weak symbol idiom would avoid the dance with -fno-static-call etc.
