[Top][All Lists]

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

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

From: Bernard Giroud
Subject: Re: [open-cobol-list] Undocumented cobc option: -static
Date: Mon, 17 Nov 2014 21:28:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

Le 17/11/2014 20:10, Scott McKellar a écrit :

"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.
That happens with static linking too; either you forgot to relink your main or you forgot to put the module and/or the library in prod (or one silly operator skipped one line in the prod request ;-) ).

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.
I used to work for a swiss bank with the main application written in DELTA/COBOL on VMS. We just organized the application in layers, each layer being a shared lib. Less link time, easier fallback in prod (just switch the library in fault with its previous version), less disk space used. But some specific modules were statically linked, because their use was less important.
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

Bernard Giroud

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


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


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:

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 Bruceville, TX What's the definition
of a legacy system? One that works! Errare humanum est, ignoscere caninum.
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
open-cobol-list mailing list

reply via email to

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