[GEMPAK #GZK-619275]: Gempak binaries fail

Hi Mike,

re:
> (Happy Thanksgiving!)

Same back 'atcha :-)

re: what is output of ldd /usr/local/gempak/GEMPAK5.11.1/os/linux64/bin/garp

> [mapmaker@lightning ~]$ ldd /usr/local/gempak/GEMPAK5.11.1/os/linux64/bin/garp
> libXm.so.2 => /usr/lib64/libXm.so.2 (0x0000003265a00000)
> libXt.so.6 => /usr/lib64/libXt.so.6 (0x0000003ead200000)
> libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003e9c000000)
> libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002b94887a8000)
> libm.so.6 => /lib64/libm.so.6 (0x0000003e9a000000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003ea9a00000)
> libc.so.6 => /lib64/libc.so.6 (0x0000003e99c00000)
> libXmu.so.6 => /usr/lib64/libXmu.so.6 (0x0000003e99000000)
> libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003e9c800000)
> libXp.so.6 => /usr/lib64/libXp.so.6 (0x0000003266000000)
> libXft.so.2 => /usr/lib64/libXft.so.2 (0x0000003eab200000)
> libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x0000003e9e000000)
> libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x0000003e9d400000)
> libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003e9d000000)
> libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x0000003ea2e00000)
> libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0000003e9dc00000)
> libSM.so.6 => /usr/lib64/libSM.so.6 (0x0000003ea3a00000)
> libICE.so.6 => /usr/lib64/libICE.so.6 (0x0000003ea4a00000)
> libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003e9bc00000)
> libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x0000003e9b800000)
> libdl.so.2 => /lib64/libdl.so.2 (0x0000003e9a400000)
> /lib64/ld-linux-x86-64.so.2 (0x0000003e98c00000)
> libexpat.so.0 => /lib64/libexpat.so.0 (0x0000003e9d800000)
> libz.so.1 => /usr/lib64/libz.so.1 (0x0000003e9ac00000)
> [mapmaker@lightning ~]$

OK.  This all looks reasonable.

Question:

- is 'mapmaker' the account you usually run GEMPAK (NTL, Garp, etc.) from?

re: did you install the 64-bit binary 5.11.1 distribution, or the 32-bit binary
    how did you install the LessTif package

> Yes, 64 bit binaries. Not sure about LessTif, I can't find it

The fact that LessTif (Motif) library, libXm.so.2, is found in /usr/lib64 looks 
correct
(from 'ldd' listing).

re: output of locate libXm.so

> [root@lightning etc]# locate libXm.
> /usr/lib/libXm.so.4
> /usr/lib/libXm.so.4.0.0
> /usr/lib64/libXm.so.2
> /usr/lib64/libXm.so.4
> /usr/lib64/libXm.so.4.0.0

The fact that there is a libXm.so.2 and libXm.so.4 in /usr/lib64 but not in 
/usr/lib looks
a little suspicious to me.

Questions:

- how did libXm.so.2 get put in /usr/lib64
- what is the output of:

cd /usr/lib64
ls -alt libXm*

> Well, I guess a made a bad assumption that this version of linux
> would work.

Not necessarily, but I have run into some quirkiness on other RedHat Enterprise 
5
systems (a system at CICESE in La Paz, Baja, Mexico and another system at 
Creighton
University).

In the CICESE case, we were seeing weird problems related to the LDM:

- 'ldmadmin watch' would show that products were arriving and apparently being
  put into the LDM queue
- 'notifyme -vl-' did _NOT_ show the arrival of large sets of the products being
  reported by 'ldmadmin watch'

- GEMPAK decoders did not see many of the products being reported by
  'ldmadmin watch'.  This, at least, agreed with the non-listing by 'notifyme'

The "fix" in the CICESE case was to disable IPv6 support on the machine.  We can
discuss this in detail (i.e., a 1-2-3 for how to disable IPv6) later if this
appears to be a problem on your machine.

The problems you are reporting do not match what we were seeing on the CICESE 
machine,
but you never know...

> What system do you guys test the 64 bit linux on?

The 64-bit GEMPAK 5.11.1 binary distribution was built on a Fedora 8 machine 
(using gfortran,
not g77).

By the way, when Don and I tried to pick-up support for GEMPAK after Chiz left, 
we noted
how many support inquiries were directly related to the use of a pre-compiled 
binary
distribution.  In at least two cases, the problems that were being reported 
went away
when GEMPAK was built from source on the user's machine.  For this reason, we 
have agreed
that the STRONG recommendation that will be made for the next GEMPAK release, 
5.11.4, will
be that users should build from source UNLESS they running machines that are 
identical
to the machines on which we will produce a _small_ set of binaries.

> thanks for your help,

Haven't been successful yet, but we will figure this one out!

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: GZK-619275
Department: Support GEMPAK
Priority: Normal
Status: Closed