[Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library

["kargl at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #3 from kargl at gcc dot gnu dot org  2010-01-01 02:49 -------
(In reply to comment #2)
> Subject: Re:  BLOCKDATA referenced in EXTERNAL not loading from library
> 
> I just got it from the gfortran Wiki because of problems with the previous 
> version I had:
> http://gcc.gnu.org/wiki/GFortranBinaries
>  then the "CygWin" version, which appears to point to
> http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.5-Cygwin-i686.tar.bz2
> today, anyway.
> 
>  I guess tastes vary.
> We preferred shell scripts when I worked at Cray, HP, SGI, Compaq, and 
> Digital;
> as you otherwise don't know which compiler switches, system level, and so on 
> were used..

Then please attach the script to the bug report.  The web interface
to bugzilla and cut-n-paste plays havoc with whitespace, long lines,
etc.

> It works for me on several Linux boxes as well, just not CygWin. What 
> platform are you on?

FreeBSD on i686 and x86_64.

> I'm curious
> if you do a nm on your libex.a file if juinit2 is type T or B;

% nm libex.a

a2.o:
00000000 B juinit2_
00000000 D qindex2_

> I haven't  used a non-Unix/GNU
> machine for so many years (except for CygWin) I guess it didn't occur to me 
> a shell script
> would be harder, not easier, to use. Some examples in the Wiki of "ideal" 
> bug reports would
> be useful.

The ideal bug report is the shortest source code example that 
exhibits the problem, which you gave us.

The simplest command line used to compile the code that 
exhibits the problem.

If a data file or input is needed, the shortest such data
is desirable.

If the problem is an internal compiler error or segfault of
the compiler, include the last several lines that appear
on the terminal.

If it's a runtime problem, either give the abort message
or error message, or tell us what the expected output
should have been.

> Note I just upgraded my CygWin a few days ago, to version 1.7;

This is my suspicion.  There's a problem with the new cygwin.

> (and G77 and G95) on CygWin; but a recent Vista upgrade broke CygWin (the 
> X11 windows
> were a bit fragile on Vista anyway). It still builds with G95, and an older 
> version still builds with G77.
> 
> PS: I found it surprising that if I just compiled the main program I didn't 
> get a warning about >unsatisified external JUINIT2; I did with every other
> compiler I tried.

I don't know much about how BLOCK DATA and COMMON are implemented.
But, it looks like the compiler is simply eliminating the symbol
as dead code.

% gfc4x -o z a1.f
% nm z | grep -i juin
% nm a1.o
00000000 t MAIN__
         U _gfortran_compare_string
         U _gfortran_set_args
         U _gfortran_set_options
         U _gfortran_st_write
         U _gfortran_st_write_done
         U _gfortran_transfer_array
         U _gfortran_transfer_character
00000197 T main
00000060 r options.4.1509
00000019 C qindex2_

AFAIK, there is no constraint in the Standard that something
marked by EXTERNAL must be referenced.

> It was also odd that
> if I put a no-op subroutine in the same file as the BLOCKDATA file and then 
> called it from the main
> program that the BLOCKDATA was then initialized properly.

That is strange.  It seems to be a linker problem.  I suspect that
you may need to ping the cygwin guys.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568