Re: gfortran, ncar and blockdata_test failures

[Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>]

Walter Spector wrote:
> Tobias Schlüter wrote:
> > ...
> >  From your description, and from looking around the testcase from the
> > webpage, I take it that it's actually a linker problem that some people
> > used to work around in the weirdest ways.  Creating an intermediate
> > library should not ever cause any differences.
>
> It is not a linker problem per se.  It is a semantic difference between:
>
>   gfortran -o myexe *.o
>
> and
>
>   gfortran -o myexe mymain.o -lmylib  # (where libmylib.a is an ar library)
>
> In the former, the linker just links everything in the list of .o files
> into myexe.  Often without checking to see if the routine is actually
> called.
>
> In the latter, the linker notices there are unsatisfied externals from
> mymain.o, then tries to find those externals in libmylib.a.  It pulls
> in the needed routines as found.  Routines which are not in the call tree
> are generally not included in myexe.  (Again, we are NOT talking about
> shared libs/dlls - which are essentially pre-linked in the *.o style.)

I modified the testcase to use -l instead of typing out the name of the 
.a file.  It still worked as before, it simply didn't make any 
difference at all.

> Did you try both main.good and main.bad?  The makefile links the first
> straight from the .o files.  The latter is a main.o with the remainder
> of the routines pulled in from the library.
>
> Note that I am not using an Apple.  I am using cygwin, running on Windows
> NT.  Cygwin uses the gnu ld from binutils.

When I mentioned apple, I was referring to Jack's initial report, I 
should have perhaps made that clear.  To be sure, did you actually try 
what happens if you run the various compiled testcases, or did you look 
at the contents of the binary files right away?  I'm asking because I'd 
be somewhat surprised if cygwin behaves any different from Linux in this 
regard.

> The interesting situation is BLOCK DATAs in the library.  Since they are
> never CALLed, how does the programmer tell the linker to pull them in?

Not at all.  He simply references the common blocks contained therein, 
and the linker will do the right thing.   Unless (as you pointed out in 
the rest of your e-mail) the user relied on non-standard quirks, such as 
 relying on the ability of choosing between different block datas via 
external statements or hoping that incompatible layouts of common blocks 
will not wreak havoc.  Both techniques are definitely disallowed in 
Fortran 90, and possibly older incarnations of the standard which I 
don't have around to check.

I don't think supporting that kind of ugliness should be a priority for 
gfortran.

Cheers,
- Tobi