Let me also add that although nmap2 builds correctly, its functionality is
compromised as many of the widgets do not appear. This is the same
behavior I've recently discovered with 5.11.4 on Fedora 12. I suspect
that latest versions of openmotif are no longer fully compatible with
nmap2 (this explains why CentOS/RHEL 5-based builds of 5.11.4 still work)
. . .
Any other folks see similar behavior and/or have fixes?
______________________________________________________________________
Kevin Tyle, Systems Administrator **********************
Dept. of Atmospheric & Environmental Sciences ktyle@xxxxxxxxxxxxxxxx
University at Albany, ES-235 518-442-4578 (voice)
1400 Washington Avenue 518-442-5825 (fax)
Albany, NY 12222 **********************
______________________________________________________________________
On Tue, 9 Mar 2010, Kevin R. Tyle wrote:
Hi Pete,
With a bit of patience, the use of macports, and GCC/Gfortran 4.4.3, I have
indeed been able to build all of 5.11.4 and I have been able to view gridded
data with gdplot2 and display the grids with gdinfo.
Let me gather my build notes together and develop a how-to that hopefully
will work for you too. Hopefully in a few days . . .
Cheers,
Kevin
______________________________________________________________________
Kevin Tyle, Systems Administrator **********************
Dept. of Atmospheric & Environmental Sciences ktyle@xxxxxxxxxxxxxxxx
University at Albany, ES-235 518-442-4578 (voice)
1400 Washington Avenue 518-442-5825 (fax)
Albany, NY 12222 **********************
______________________________________________________________________
On Fri, 5 Mar 2010, Pete Pokrandt wrote:
All,
Has anyone had any success building GEMPAK 5.11.4 under a 64 bit
environment in OS X 10.6?
Some background -
I was able to fairly easily build a 32 bit GEMPAK using gcc-4 and g77
3.4.3, along with openmotif3 from a 32 bit install of fink. However, the
executable files run much slower on a brand new 64 bit CPU iMac than even
on a 2 year old linux box. This includes both included GEMPAK executable
files (gddiag was one I think) and some code that the user wrote that links
into various GEMPAK libraries for reading/writing files.
One thing I noticed was that if I added any optimization level to the
compile of the user code, the calls to the gempak file open routines would
return with a -12 error (file not found, I think). So maybe there is
something about the lack of optimization that is causing it to be slow?
I also considered the possibility that I'm running 32 bit code under a 64
bit OS/CPU, so maybe that is slowing it down. I attempted a compile using a
64 bit fink install of gcc44 and gfortran, loosely basing several of the
config files on the 64 bit linux gfortran compile. I ran into lots of
undefined routine problems, which seemed to result from certain libraries
not being included on the compile line, mostly in the drivers section (ps,
xw, gif, etc.) I was able to manually get each of these to compile by
adding the required libraries to the compile line, and much of GEMPAK
appeared to compile and install properly, but it doesn't run right. Very
strange - any program that I run, for example, gdinfo, produces the
following output:
Usage: convcvg type ...
type = 3e3f, 3i3h, 3k3j, 3l3j, 3m3j, etc.
This output happens for any gempak program, or any of the users programs
that link to the gempak libraries. Very strange, since I'm running gdinfo,
not convcvg
Does anyone have any ideas or tips on getting GEMPAK to build correctly
using 64 bit Mac OSX and gcc/gfortran?
Thanks,
Pete
--
Pete Pokrandt - Systems Programmer
UW-Madison Dept of Atmospheric and Oceanic Sciences
608-262-3086 - poker@xxxxxxxxxxxx
_______________________________________________
gembud mailing list
gembud@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
_______________________________________________
gembud mailing list
gembud@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
