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

[Simon Sobisch]

The usage of --static has one big side effect: COBOL sources compiled
with it need all these directly CALLed objects at run time. It's usage
was kind of deprecated, it's in 1.1 (without any alternative) and in 2.0
more because of "legacy issues" :-)

V2.0 has evolved, you can do

    CALL STATIC "mylib"

which will do the static linking only for "mylib" or leave it as

    CALL "mylib"

and tell cobc to statically link it with

    cobc prog.cob -K mylib

the following information is included in --help and therefore in the
FAQ, too)

 -K <entry>        Generate CALL to <entry> as static

Simon
   
> Message: 1
> Date: Thu, 13 Nov 2014 08:23:28 -0800
> From: Scott McKellar <address@hidden>
> Subject: [open-cobol-list] Undocumented cobc option: -static
> To: "address@hidden"
>       <address@hidden>
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> There appears to be an undocumented option to cobc: -static.
>
> So far as I can tell, this option tells cobc to translate CALL statements to 
> static calls instead of dynamic calls.
>
> However I only discovered that by trial and error.  A program that wasn't 
> working without -static is now working with it.  I also examined the 
> generated C code to verify that it's different.  I don't know what other 
> effects -static may have.
>
> However, -static is not listed among the compile options in the FAQ, nor in 
> the corresponding page in Gary Cutler's book (I'm looking at the FAQ for 
> GnuCOBOL v1.1 and the Cutler book for v2.0).  My only clue that -static was 
> even available was that I saw it used in a couple of examples on the FAQ 
> page.  I took a wild guess at what it did, and it looks like I guessed right.
>
> I'm glad I found out about -static because the default of dynamic linking 
> could have been a deal-breaker.  Without -static I couldn't find a way to 
> link to a static library (a *.a file on a UNIX or Linux system).  Migrating 
> to GnuCOBOL would be even more disruptive if we had to use dynamic linking 
> everywhere.  It might not even be possible; for all I know we may rely on a 
> third party static library somewhere that isn't available as a shared library.
>
> Questions:
>
> Have I interpreted -static correctly?
>
> Does -static have any other effects that I didn't notice?
>
> Will -static be available in v2.0?  (I'm currently doing my explorations 
> using v1.1.)
>
> Could someone please please document -static in the FAQ and wherever else is 
> appropriate?
>
> Scott McKellar
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 13 Nov 2014 10:40:34 -0600
> From: Kevin Monceaux <address@hidden>
> Subject: Re: [open-cobol-list] Undocumented cobc option: -static
> To: OpenCOBOL Mailing List <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Thu, Nov 13, 2014 at 08:23:28AM -0800, Scott McKellar wrote:
>  
>> > Questions:
>> > 
>> > Have I interpreted -static correctly?
> I suspect you have, but I'm only guessing based on poking around a little in
> the source.  In cobc.c in the long_options struct I found:
>
>     {"static",      CB_NO_ARG, &cb_flag_static_call, 1},
>     {"dynamic",     CB_NO_ARG, &cb_flag_static_call, 0},
>
> Which looks like -static, though for a long option --static would look more
> natural, enabled static calls and -dynamic enables dynamic calls.  
>
>> > Will -static be available in v2.0?  (I'm currently doing my explorations
>> > using v1.1.)
> It would appear so.  It was the 2.0 source I got the above info from.
>
>> > Could someone please please document -static in the FAQ and wherever else
>> > is appropriate?
> The text output by cobc --help would be another helpful place to have it
> documented.  It doesn't currently display info about the -static and/or
> -dynamic options.
>
>
>
> -- Kevin http://www.RawFedDogs.net http://www.Lassie.xyz
> http://www.WacoAgilityGroup.org Bruceville, TX What's the definition
> of a legacy system? One that works! Errare humanum est, ignoscere caninum.