gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Scott McKellar
Subject: Re: [open-cobol-list] Undocumented cobc option: -static
Date: Mon, 17 Nov 2014 11:10:03 -0800

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).


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


________________________________
From: Simon Sobisch <address@hidden>
To: Scott McKellar <address@hidden>; Kevin Monceaux <address@hidden> 
Cc: address@hidden 
Sent: Friday, November 14, 2014 2:31 PM
Subject: Re: [open-cobol-list] Undocumented cobc option: -static


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]