(j3.2006) Alternative binding label without C interoperability?

[Van Snyder]

On Thu, 2016-09-29 at 14:01 +0900, Cohen Malcolm wrote:
> I don't even follow what the alleged problem is with module procedures
> either, since the same compiler is involved! 

I don't know whether Tom is thinking of POSIX functions called dlopen()
and dlsym() (IEEE Std 1003.1), but it would seem to be a problem to use
them.  dlopen() isn't a problem because it just wants a file name.  But
dlsym() wants a handle for a loaded shared library (provided by dlopen),
and a string for an entry name.  I don't know if these are Windows
function names.  There are Linux man pages for them, as well as pages in
The Open Group Base Specifications Issue 7 (2013 edition), for example
at http://pubs.opengroup.org/onlinepubs/9699919799/, where you can put
dlopen and dlsym into a search pane.

If the entry name is for a module procedure, it's unlikely the program
will be able to guess how the compiler mangled it.  If the processor
mangles names of external procedures, that's a problem too.

If a non-mangled label for an external or procedure can be specified,
then using shared libraries dynamically according to the dynamic needs
of the program, not just what was discovered by ld, becomes possible and
portable.

I have been asked whether it's possible to create a dynamic library of
Fortran procedures, load it dynamically (without ld being aware of its
future use or the names of any entries in it), get a handle for a
Fortran procedure name in it, which procedure name might have come from
input without appearing anywhere in the program, associate that entry
with a procedure pointer, and then invoke the procedure.  So far, my
answer has been "Not in portable standard Fortran."  The nonportable
part has been the mangling of both external and module procedure names.
People have gone to some interesting nonportable extremes, such as
looking in .mod and .o files, and trying to guess how one particular
processor has mangled procedure names.

I mentioned one way to do this in a paper that I circulated informally
at the 2001 London WG5 meeting, wherein it was suggested that a
variation of the ALLOCATE statement might provide the functionality:

  ALLOCATE ( LIBRARY = '/mypath/mylibrary', &
    & ASSOCIATE = ( proc_ptr_1, 'entry_1'), &
    & ASSOCIATE = ( proc_ptr_2, 'entry_2'), STAT = oops )

The problem of entry name mangling was not discussed.  Of course, it
should be possible to provide the entry names as variables.  Otherwise,
the feature offers nothing new.  Nobody commented on anything proposed
in that paper, other than Dan, who said the next revision would be
minor.

As I said, I don't know what scenario Tom is battling, but I and my
colleagues would like a solution for this one.