GC 4.x question

[Gregory A Failing]

With the upcoming release of GC 4.x will the 'static' modifier to the 'CALL' statement go away? After all if IBM, RMCobol, and others can find called code in the current run unit or linked libs or the DASD (usually searched in that order), why does GC have that requirement? Is it a technical mandate of some kind?

Inquiring minds want to know ...

Thanks.

Gregory

[Vincent (Bryan) Coen]

My understanding of this option is that it is directly linked in to the
module being compiled via the link loader so that it is included with
run time executable even as a .ddl for Windows or .so for Linux.

This saves time on loading later and forces that the static process in
in memory when ever the specific module is loaded.

I tried to do this in another way when a main menu program was linked
with a C program/module that is called DID not link in and therefore was
not found on execution so at least this way it was found.

DASD has nothing to do with this as the driver module for any of the
various implementations is auto linked in.

At least under Linux and I assume ditto for other platforms.

On 29/11/2023 13:25, Gregory A Failing wrote:

With the upcoming release of GC 4.x will the 'static' modifier to the
'CALL' statement go away? After all if IBM, RMCobol, and others can
find called code in the current run unit or linked libs or the DASD
(usually searched in that order), why does GC have that requirement?
Is it a technical mandate of some kind?

Inquiring minds want to know ...

Thanks.

[Simon Sobisch]

Nope:

• it isn't a requirement at all
• the linker commonly removes everything that is not "seen" as "used", if you have a "dynamic" call and don't want that you could also suppress this with -Q -Wl,--no-as-needed
• if you want the effect of CALL STATIC (if you define that in SPECIAL-NAMES then you even have a standard-conforming program there, and that would also work with at least ACUCOBOL and Micro Focus) but not code that you can also use --static or -K someentry options
• note that if you use any of the static options you may get linker warnings about not completely matching types, so that's nothing you want to have as a default...

[Gregory A Failing]

Simon / Vincent,

I include the '-Q -Wl,--no-as-needed' option in all my compiles as a default. I was given to understand that using that option negates the need for 'static' entirely. However I occasionally get CALL failures that seem to resolve when I add 'static' to the code. That is infrequent however.

I use mixed language code modules all over the place so I need to have a reliable way of detecting when a CALL fails. If I use 'static' I cannot use any 'ON ERROR' code. Is there any list of reasons why a CALL fails? If RETURN-CODE is set where are the return values documented? or something else?

G

[Simon Sobisch]

A CALL may fail because of a multitude of things, but a CALL STATIC will always either fail at link-time or the loading of the "contained" executable will fail.
A static call can allow the linker to "fix" parameters that don't match exactly (or even the C compiler if you [possibly force-]include matching C headers). Also: a static call would take C defines into account (for example you CALL 'func' and because of some C define this is translated to some_func.

Side note: if you want cobc to always drop the linker optimization you can add it to the appropriate CFLAGS during configure to be used in the cobc defaults.

For dynamic calls you could check if cob_resolve returns NULL and if this is the case check deeper - but 3.2 added a warning if something goes wrong and let you know about that.

In any case: if you have linking / resolve errors then drop the specific ones and we can have a look,

[Gregory A Failing]

When configuring GC for BDB ISAM support I use the following:

export LD_LIBRARY_PATH=/usr/local/BerkeleyDB.18.1/lib:$LD_LIBRARY_PATH
./configure \
--with-curses=ncurses \
--with-json=json-c \
--with-xml2 \
CFLAGS='-g -Q -Wl,--no-as-needed' \
LDFLAGS="-L/usr/lib/x86_64-linux-gnu" \
BDB_LIBS="-L/usr/local/BerkeleyDB.18.1/lib -ldb" \
BDB_CFLAGS="-I/usr/local/BerkeleyDB.18.1/include" \
JSON_C_LIBS="-ljson-c" \
XML2_CFLAGS="-I/usr/include/libxml2" \
XML2_LIBS="-lxml2"

When configuring for GC with VBISAM I assume some changes would be needed in 'LD_LIBRARY', 'BDB_LIBS", and 'BDB_CFLAGS'. anything else?

Thanks
G

[Simon Sobisch]

You may want to explicit request

--with-vbisam --with-bdb

as with 4.x you get both that way (with the first being the default for new files).
You may also add --with-odbc.

In general (also to see the FLAGS/LIBS variables you need to add) check out
configure --help

[Gregory A Failing]

Never mind Simon, I think this will work:

# GC with VBISAM, xml and json support
export LD_LIBRARY_PATH=/usr/local/?????????/lib:$LD_LIBRARY_PATH
./configure \
--with-vbisam \
--with-curses=ncurses \
--with-json=json-c \
--with-xml2 \
CFLAGS='-g -Q -Wl,--no-as-needed' \
LDFLAGS="-L/usr/lib/x86_64-linux-gnu" \
JSON_C_LIBS="-ljson-c" \
XML2_CFLAGS="-I/usr/include/libxml2" \
XML2_LIBS="-lxml2"

... at least when I find the correct path for LD_LIBRARY_PATH to VBISAM libs.

Thanks anyway.

G