Re: intel OS X and intel f77 compiler

On Feb 21, 2007, at 8:59 AM, Richard Mitchell wrote:

> Has anyone successfully compiled NCAR on intel OS X?
>
> I'm using gcc and Intel's f77 compiler: ifort (IFORT) 9.1 20070112
>
> I have followed other hints I found here for changing config/DARWIN
> (adding -lifcore) and a few other files. Right now everything
> compiles and looks reasonably good, until I try actually use it.
> This:
>
> ncargex cpex08
>
> NCAR Graphics Fortran Example <cpex08>
>
> Copying cpex08.f
>
> Copying cpexcc.f
>
> Compiling and linking...
> ifort -mp -O -o cpex08 cpexcc.f cpex08.f -L/usr/local/ncar/lib -L/
> usr/X11R6/lib -L/opt/local/lib -lncarg -lncarg_gks -lncarg_c -lXpm -
> lX11 -lXext
> cpexcc.f(51) : (col. 14) remark: LOOP WAS VECTORIZED.
>
> Executing <cpex08>...
> GKS ERROR NUMBER -107 ISSUED FROM SUBROUTINE :
>
>
> Metafile file is named cpex08.ncgm.
>
>
>
> doesn't actually create an output file. As anyone else seen this?
> As anyone else got it to work on an intel Mac? I can go into
> details on what I've changed, but there may not be any need to bore
> everyone with the minutia just yet.
>
Richard,

This GKS error message of -107 is supposed to mean that you
have exceeded the maximum number of error messages allowed
for this run (default is ten). However, when this message
is issued as it is here, it usually means that blockdata has
not been loaded (the variable storing the maximum number of
error messages has not been set).

Mary Haley has provided me with a detailed analysis, which
I pass on here:

I don't think this is a Mac-specific issue, certainly not with g77.
This problem has surfaced in other situations when a
non-g77 compiler is used on the Mac, like Absoft or Intel.

The only thing I can suggest is not to use these compilers, or to
ask the vendors what they can do for a work-around.

Another remote possibility is to compile the "ncarbd.f"
subroutine in $NCARG/ncarg2d/src/liboptional/ncarbd, and try loading
this on the compile line every time they compile an NCAR Graphics
program. (I think it needs to be included on the compile line
*before* any NCAR Graphics libraries.) This doesn't always fix the
problem, however.

There is a simple blockdata test that can be run to see if their
compilers have a problem with loading and/or initializing blockdata
variables. It doesn't depend on NCAR Graphics at all. It is attached.

To generate and run the tests:

    tar -xvf Blockdata_test.tar
    cd Blockdata_test
    make main.good
    make main.bad
    ./main.bad
    ./main.good

If the compiler is not correctly initializing blockdata
variables, then "./main.bad" (and maybe even "./main.good") will
produce output like:

   TESTSUB: WK = 0...it should be 20

If "main.good" gives the correct results:

   TESTSUB: WK = 20...it should be 20

and "main.bad" doesn't, then this probably means the Intel
compiler is being used. This compiler correctly initializes blockdata
variables as long as you don't load them in via a library. In other
words, you would have to compile NCAR Graphics programs by linking in
every single *.o file in the NCAR Graphics library source tree, rather
than linking in the libraries with "-lncarg_c -lncarg_gks -lncarg".
Of course, this is an unacceptable and impractical work-around, because
we have hundreds of *.o files.

The simple answer is to use the g77 compiler, if you aren't doing so.
If you are, then we have an unexplored problem on our hands.

--Mary

>
> Richard
> --------------------------+-----------------------------
> Richard Mitchell | Airborne Oceanographic Lidar
> mitchell_at_osb.wff.nasa.gov | Laboratory
> (shining a little light on the world)
>
>
> _______________________________________________
> ncarg-talk mailing list
> ncarg-talk_at_ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/ncarg-talk

_______________________________________________
ncarg-talk mailing list
ncarg-talk_at_ucar.edu
http://mailman.ucar.edu/mailman/listinfo/ncarg-talk