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: Ron Norman
Subject: Re: [open-cobol-list] Undocumented cobc option: -static
Date: Mon, 17 Nov 2014 11:17:23 -0800

I use static link of COBOL main & subroutines all of the time for the same reasons you explained.
I think the --static compiler option has been replaced by -fstatic-call option.
The feature to have staticly linked modules to build a program is not going away.
I think it is just the way to you ask for that feature.
The options I use all of the time for cobc are:   -w -O2 -std=mf -fstatic-call -fimplicit-init
Another option you might find useful is:  -frelax-syntax 



On Mon, Nov 17, 2014 at 11:10 AM, Scott McKellar <address@hidden> 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).


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.

------------------------------------------------------------------------------
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
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list



--
Cheers
Ron Norman

reply via email to

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