gfortran
By phystad at Thu, Jul 10 2008 10:22am |
I am compiling a large collection of Fortran 77 code using gfortran. All source compiles cleanly without error or warnings. However, during link I get the following warning:
"Can't find atom for N_GSYM stabs...."
Some google research has shown me that this error has occurred for others but there is no hint as to its cause other then there might be a problem or conflict with the Mac OS X loader.
Does anyone know about this problem or other hints for resolving?
Re: gfortran
Hi,
Can you tell me a bit more about the system this is running on? If it's Leopard, was it an upgrade from Tiger? How recently have you installed gfortran or Xcode/gcc?
Thanks
Dave
gfortran problems -- more information
System: MacBook Pro with 2 GB RAM, running Leopard, OS X 10.5.4.
This problem seems to have some connection with how a large program is divided up into separate files, compiled separately and then linked together. Let me explain...
The program is NEC2 (been available for years) used for computing electromagnetic field response of wire antennas (and, other parameters). This program is available as a rather large, 10000 line source program of about 80 subroutines and functions specified in a single source file. When I compile this single source file and link it using gfortran, I have no problems at all. Program links and executes correctly.
However, the problem shows up when I split the source up into individual files: one file per function or subroutine. I have a simple little script I use to do this split and it works very well (tested and used a number of times). When I compile the individual source files and then link the compiled objects I get this "Can't find atom for N_GSYM..." error. Note that all source files compile cleanly without problems.
I have experimented using debug (-g) and nodebug flags and using DWARF as the debug symbol table or not using it yet I get the same error.
So, somehow, the act of dividing this program into a multitude of source files results in this problem showing its ugly little head. By the way, about two-thirds of the functions and subroutines use various named common blocks for exchanging data. I suspect that something about handling these common blocks might be the problem. Also, there are places where EQUIVALENCE statements are used to combine local arrays with common block arrays. I know that EQUIVALENCE used in this fashion is sort of a deprecated feature of F90 but I am not sure how it would affect this compile. These are just my current guesses.
gfortran addendum...
Answers to more of the questions:
1. Leopard is an update from Tiger.
2. Xcode is updated frequently because I am on the iPhone SDK distro. But, GCC is
not updated with these myriad of updates of Xcode due to iPhone SDK updates.
3. Xcode 3.0+
points?
Why am I earning points with my posts? Do I get a free PowerMac if I get 'so many' points?
I'm still confused
I'm still confused. It the problem in the linking stage or in the script that splits the file into many files?
Is this all done at the command line or in XCode?
Justin
gFortran followup...
The problem is in the linking stage. The script that I use to split up the files works fine. All files compile cleanly and without problems. In fact, everything compiles cleanly. Only the link stage produces this error.