[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

2000126: Gempak compile problem

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 2000126: Gempak compile problem
  • Date: Wed, 26 Jan 2000 14:10:34 -0700
>From: Mark Tucker <address@hidden>
>Organization: .
>Keywords: 200001262100.OAA14472

>On Wed, 26 Jan 2000, Unidata Support wrote:
>
>> Did you attempt to run the binaries on your platform?
>> They are statically compiled, and should run on your system, but
>> I can no longer provide two sets of binaries for Linux.
>> 
>
>I thought that they were compiled dynamically linked based on what the
>readme said.  I downloaded it and installed.  It seems to be working
>except for a problem in the model selection - I cannot select a model
>group(ie. ETA, MOS..)  and therefore cannot select a datafile.  I just
>moved over our Gemenviron from the previous install so there may be some
>change I need to make for the new version.  
>
>Thank you.
>
>Mark Tucker
>Information Technology
>Lyndon State College
>address@hidden
>
>

Mark,

the Garp_defaults file was changed from 2.02 to 2.1 so you need to
use the 2.1 version of the file. You will find that the FDF chapters
are named differently between the 2 versions.

You will have to edit the model_keys, proj, garea and default in the
config file to match the naming scheme you use (this can be copied
from your previous 2.02 configuration). If you changes those names,
you will need to changes the directory names in $GARPHOME/fdf/scalar
and vector so that the macros for the individual models can be found
with names that match the model_keys.

The Importance in that we are using RedHat 6.x with glibc2.1 is that
the libraries (if you download that) are compiled using glibc2.1
and you may have problems linking your own programs under 5.x
with those libraries. Glibc2.1 defines stderr, stdout and stdin
as variables, where 5.x with glibc2.0 had these as constants.
As a result, things compiled with one library generally can't be linked
with the other version of the C library.

Steve Chiswell