Re: [open-cobol-list] Undocumented cobc option: -static

[Simon Sobisch]

Hi Scott,

Monday, November 11, 2014 Scott McKellar wrote:
> Simon:
>
> "The usage of --static has one big side effect: COBOL sources compiled
> with it need all these directly CALLed objects at run time."
>
> I'm not sure what you mean by that.  Surely any program needs its called 
> objects at run time, whether it's linked statically or dynamically.
>
> I'm going to assume you meant: a program linked statically needs all its 
> called objects at *compile* time (or more specifically at link time).
Of course that was what I meant :-)

> In that case -- yes!  That's what I want!  And if I couldn't have it, I would 
> recommend *against* migrating to GnuCOBOL, even though I'm the one who 
> suggested it in the first place.
>
>
> Even with the little toy programs I use to explore the use of GnuCOBOL, with 
> dynamic linking I repeatedly found myself getting a clean build only to see 
> the program crash and burn at run time because I forgot to include all the 
> right libraries in the link.
>
> I'm pretty sure I'm not infallible (though I might be wrong about that).  
> When I do make a mistake, I want to find out right away.  I don't want to 
> wait until my broken build is in production, and then watch it die abruptly 
> in the middle of a half-million dollar transaction.
>
> I also don't want the program to *seem* to work, but actually get the wrong 
> answer because when I updated the executable I forgot to update one of the 
> shared objects that it calls.
>
>
> When I put a new version of a program into production, I want to know that 
> it's exactly the same program as the one I tested, from top to bottom.  I 
> can't do that with dynamic linking.
>
> We do use dynamic linkage for various third party libraries, such as the 
> Xerces library for parsing XML.  However these libraries are stable; they're 
> not subject to the constant churn that our own code undergoes.
> The CALL STATIC syntax wouldn't help us much, even if we were willing to edit 
> a half-million lines of code to add the STATIC option to the calls.  Many of 
> the CALLs are generated by Oracle's precompiler, and I doubt that we can coax 
> Oracle into adding STATIC everywhere.
>
>
> Likewise the -K option would be a nightmare to apply across the board.  We'd 
> have to keep track of all the CALLs made within every load module at every 
> level, including all the mysterious Oracle functions.
>
>
> I know that, for reasons unclear to me, the GnuCOBOL developers are much 
> enamored of dynamic linkage.  As for me, you can have my static linkage when 
> you pry it from my cold, dead fingers.
>
> If there any plans to abandon the -static option, I'd like to know about it 
> now, so that we can stick with the expensive proprietary compiler.
>
> Scott McKellar
There are no plans for abandoning this option. I just won't recommend it
for most cases. In my case the programs I currently write are about 3000
single COBOL programs for one big application written by lots of
programmers - and in this case you neither want to recompile everything
(ok, link only, but still a lot work) if you changed a single
computation (or received a change) nor want to send out one big
executable to all customers with hundreds of MB just because of this
change - easier to get one single and small module send out via mail.

Modules do make unit tests possible (and useful), too.

Applications with a size of more than some MB tend to start quite slow
(reading from HDD and needing the space in RAM afterwards) while a
modular application just needs some small reads to start up and loads
whatever module is necessary when necessary.

But I won't take the static linkage away from anyone - it just don't
make much sense for most (not all) cases to me. And therefore you're
initial request is more than valid - I'm adding these options to --help
(or show the currently not shown help for -fstatic-call: "Output static
function calls for the CALL statement") and discuss the further
documentation with Gary Cutler as soon as he replies to my mail.

Simon