https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
Simon Sobisch <simonsobisch at gnu dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |simonsobisch at gnu dot org
--- Comment #18 from Simon Sobisch <simonsobisch at gnu dot org> ---
Just to add:
* explicit exported should be all
ENTRY "abc".
* PROGRAM-ID. "def".
is the most common (internal) entry point, with the code starting in the
first non-declarative procedure
* PROGRAM-ID. GFH. and
PROGRAM-id. gfh.
should be handled identical = somehow exported, most environments export an
uppercase variant for non-literals
* FUNCTION-ID. "abc".
needs to be somehow available, but how is implementation defined, and it it
totally valid if this is only done via an "internal" external-repository -
because function definitions _can_ be implemented 100% static - and their used
name in COBOL is always case-insensitive (the actual exported entry point is an
implementation internal definition)
at least from COBOL CALLs the entry points should be available:
* in nested programs (those don't need to be exported otherwise, but also be
accessible inside via CALL var)
* in the same binary
* in linked objects (linker optimisation of "unused" symbols may apply, in
which case the user may need to disable that)
* in already loaded (COBOL) shared objects
* in binaries resolved "implementor defined" - but for dynamic CALL "VAR"
people will expect VAR.so (or var.so) to be loaded - COBOL requires to document
this to the user
It is _very_ useful to have an option to "pre-load" libraries somehow - because
often multiple functions are in a single shared objects. An environment var
similar to LD_PRELOAD (but portable and only applying to COBOL) is useful.
Another option is to allow "pre-loading" by CALL "binary-name" (this is at
least done in ACUCOBOL, but I think also in other COBOL environments).
