Block Data already defined

[Larry Blodgett]

Here is the error information.
quicksilver:/gfortran/flare larry$ ./flarejcl
Output sent to file flare12.lis
/var/tmp//ccjxXfHM.s:12548:FATAL:Symbol __BLOCK_DATA____ already  
defined.

Here is the script that is executed
#!/bin/bash
cd /gfortran/flare/
rm flare12.lis
rm flare12.exe
/usr/local/bin/ftnchek -out=flare12 -lis -dec -ref -six -sym flare12.f
/usr/local/bin/gfortran -o flare12.exe flare12.f

Here is a list of the block data statements only
BLOCK DATA SPECHT
BLOCK DATA CRITPR
BLOCK DATA LHTVAL
BLOCK DATA BGNAME

Here is the verison information
quicksilver:/gfortran/flare larry$ gfortran -v
Using built-in specs.
Target: powerpc-apple-darwin7.8.0
Configured with: ../gcc/configure --prefix=/usr/local/gfortran -- 
enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050325 (experimental)

Maybe this could help spot an obvious problem that I do not see.
I will pursue debugging along the line you have suggested

BY THE WAY, The code runs fine under G77.

Thanks for any help you might have.

Larry Blodgett

On Jun 8, 2007, at 1:59 AM, Brooks Moses wrote:

> Larry Blodgett wrote:
>> I have searched and searched for a duplication.  Where can I find  
>> the  duplication?
>
> Unfortunately, without a code sample that illustrates the problem  
> you're having, or even a copy of the error message, I have no idea.
>
> Can you please try reducing your code to a small complete testcase  
> that reproduces the problem, and forward that to the list along  
> with a copy of your compilation command including any option flags  
> you're using, and the exact error message that you get?
>
> If you need help with reducing your code to a small testcase, ask  
> and I'll see if I can find some references.  The general process is  
> to make a copy of the code, and then delete portions of it that  
> appear to be unrelated to the bug, recompiling after each step to  
> confirm that the error remains.  If the error goes away, add back  
> in the last bit that you deleted, and try removing something else.   
> Repeat until there's nothing left that can be removed.  Except in  
> rare cases, the end result should be no longer than 50 lines, and  
> it's usually a lot shorter.
>
> (That can be a good debugging technique in general; often, when  
> you're reducing the code, you'll get about halfway through and  
> realize where the bug is coming from because you can now see it  
> clearly.)
>
> Hope this helps,
> - Brooks
>

Larry Blodgett
lblodgett@gmail.com