------- Comment #2 from urbanjost at comcast dot net 2010-01-01 01:57 ------- 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.. It works for me on several Linux boxes as well, just not CygWin. What platform are you on? I'm curious if you do a nm on your libex.a file if juinit2 is type T or B; 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. Note I just upgraded my CygWin a few days ago, to version 1.7; as X11 windows were not working. I have built the program I extracted the problem from many times in the past with older GFORTRAN versions (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. 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. ----- Original Message ----- From: "kargl at gcc dot gnu dot org" <gcc-bugzi...@gcc.gnu.org> To: <urbanj...@comcast.net> Sent: Thursday, December 31, 2009 7:46 PM Subject: [Bug fortran/42568] BLOCKDATA referenced in EXTERNAL not loading from library > > > ------- Comment #1 from kargl at gcc dot gnu dot org 2010-01-01 > 00:46 ------- > Can you please read how to submit a bug report? I can't > find anywhere were it states that a Bourne shell script > should be submitted. It simply makes it almost impossible > to read the actual bug report. In fact, all the crap with > nm and ar is just unneeded cluttered. > > % gfc4x -c a2.f90 > % ar -cur libex.a a2.o > % gfc4x -o z a1.f90 -L. -lex > % ./z > chars=abcdefghijklmnopqrst<remainder deleted> > *missingBlockData* loaded common block > % gfc4x -c a2.f90 a1.f90 > % ./z > chars=abcdefghijklmnopqrst<remainder deleted> > *missingBlockData* loaded common block > % gfortran44 -c a2.f90 > % ar -cur libex.a a2.o > % gfortran44 -o z a1.f90 -L. -lex > % ./z > chars=abcdefghijklmnopqrst<remainder deleted> > *missingBlockData* loaded common block > % gfortran44 -o z a1.f90 a2.f90 > % ./z > chars=abcdefghijklmnopqrst<remainder deleted> > *missingBlockData* loaded common block > > Appears to work for me. Where did you get your copy of > gfortran? > > > -- > > kargl at gcc dot gnu dot org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |WAITING > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
