Runtime loader issue

[Steve Kargl]

On Thu, May 10, 2018 at 11:23:39AM -0400, Kurt Lidl wrote:
> On 5/10/18 11:15 AM, Steve Kargl wrote:
> > On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote:
> >>
> >> Agreed, however this has the side effect of meaning conflicts with libraries
> >> between clang and gcc libs. Notably gfortran and flang use different
> >> conventions for I/O :(
> >>
> >> See http://people.FreeeBSD.org/~db/fortran_libs.txt
> > 
> > Page doesn't appear to exist?  If I go to
> > 
> > https://people.freebsd.org/homepage.html
> > 
> > you're not listed.
> 
> There's one too many "e" characters in the given URI.
> 
> Correct URI: http://people.FreeBSD.org/~db/fortran_libs.txt
> 

Ah, thanks!  I simply copy-n-pasted the link, then went to
the homepage.html via a bookmark.

The incompatibility in IO runtimes between gfortran and
flang is a minor issue for anyone using actual modern
Fortran, and in particular, Fortran's MODULE feature.

% cat m.f90
module foo
   implicit none
   real :: pi = 3.14
   contains
     function real_pi() result(p)
         real p
         p = atan(1.)
     end function real_pi
end module foo
% gfortran6 -c m.f90
% nm m.o
0000000000000000 D __foo_MOD_pi
0000000000000000 T __foo_MOD_real_pi
% file foo.mod
foo.mod: gzip compressed data, from Unix
% flang -c m.f90
% nm m.o
0000000000000000 r .C288_foo_real_pi_
0000000000000000 r .LCPI1_0
0000000000000000 D _foo_8_
0000000000000000 T foo_
0000000000000010 T foo_real_pi_
% file foo.mod
foo.mod: ASCII text

foo.mod can be thought of as a pre-compile header.
It will encode the named constant pi and a signature
for the function real_pi.  The object files contain
name-mangled entry points for the function.  The
Fortran Standard(s) do not specify implementation detail,
so there is an incompatibility between not only
gfortran and flang, but all Fortran compiler vendors. 

-- 
Steve