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.
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