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.
>From: "James D. Marco" <address@hidden> >Organization: Cornell >Keywords: 200006231803.e5NI3JT07000 McIDAS-X addenda ldm-mcidas decoders James, > I've got the new decoders installed on my RH 6.2 box. But there were >2 issues with the 7.6.xx update for mcidas. > > 1) mcunpack fails. It appears that the FSF/RH people did some bad > things to tar. It fails when a directory is specified as "..". > The old RH 6.0 tar unpacked fine after moving the files to the old > McIDAS machine, hence this was non-fatal. (I could have installed the > old tar on the new machine also.) OK, thanks for the update. I have RedHat 6.1 and will be upgrading to 6.2 in the near future. I will check this out as soon as I get a 6.2 development platform. > 2) After installing the update, xcd stuff failed to compile. I > downloaded the full McIDASX version and it compiled OK. Very strange. > I used the binary ldm-mcidas7.6.3 to avoid compiling issues. OK. This is the easy thing to do in any case. > Unfortunatly, I overwrote the old directory with the new stuff > and lost the makelog...sorry...but, I think this is reproducible > 'cuz I tried twice from backup copies before rebuilding McIDAS. > If anyone else does this, please forward the log to Unidata. I see from your later note that you had a backup copy of makelog. More on that below. > 3) Good news. The LDM appears happy with the new decoders. I got as similar report back from Gilbert Sebenste of NIU (after an initial error which appears to have been caused by bad timing of changing a link to the new profiler decoder binary. After the first failure, he saw no others. >Query: > I didn't try to update the new Mcidas, downloaded 20000622. > Is this OK?; can I assume it has the Latest-and-Greatest code? Yes. The addenda that are produced are cumulative, and I always try to make a new distribution compressed tar file available at the same time as an addenda is released. The distribution tar file should, therefore, always contain the latest code. By the way, I had running emails with the one user that noted potential timing problems with conversion to PNG compressed imagery during which I provided him with information on the PNG compressed AREA file format. I think that he will be able to update his code well in advance of the datastream change at the end of July. >From address@hidden Fri Jun 23 13:00:38 2000 >I found a backup copy of the makelog from the update attempt. OK, I have deleted everything in the log file up until the point of failure. ****snip*** ****snip*** ****snip*** ****snip*** ****snip*** ****snip*** ... compile wtxgserv.cp: done ./mccomp -O -s -vendor -o wtxgserv wtxgserv.o -L. -lxcd -lmcidas -lX11 mcfc -s -O -o wtxgserv wtxgserv.o -L. -L/usr/local/lib -L/usr/X11R6/lib -lxcd -lmcidas -lX11 -lf2c -ldl -lm link wtxgserv: done ./mccomp -O -vendor -I. -I../netcdf/libsrc -c statdisp.cp gcc -c -O -ansi -D_GNU_SOURCE -I/usr/X11R6/include -O -I. -I../netcdf/libsrc statdisp.c statdisp.c: In function `main': statdisp.c:100: warning: return type of `main' is not `int' statdisp.c: In function `draw_text': statdisp.c:1178: virtual memory exhausted compile statdisp.cp: FAILED ########################################## Wed Jun 21 16:24:01 EDT 2000: BUILD BEGIN ########################################## ########################################## Wed Jun 21 16:24:02 EDT 2000: BUILD END ########################################## ########################################## Wed Jun 21 16:24:11 EDT 2000: BUILD BEGIN ########################################## ########################################## Wed Jun 21 16:24:12 EDT 2000: BUILD END ########################################## ./mccomp -O -vendor -I. -I../netcdf/libsrc -c statdisp.cp gcc -c -O -ansi -D_GNU_SOURCE -I/usr/X11R6/include -O -I. -I../netcdf/libsrc statdisp.c statdisp.c: In function `main': statdisp.c:100: warning: return type of `main' is not `int' statdisp.c: In function `draw_text': statdisp.c:1178: virtual memory exhausted compile statdisp.cp: FAILED ########################################## Wed Jun 21 16:25:27 EDT 2000: BUILD BEGIN ########################################## ########################################## Wed Jun 21 16:25:28 EDT 2000: BUILD END ########################################## ########################################## Wed Jun 21 16:25:34 EDT 2000: BUILD BEGIN ########################################## ########################################## Wed Jun 21 16:25:36 EDT 2000: BUILD END ########################################## ./mccomp -O -vendor -I. -I../netcdf/libsrc -c statdisp.cp gcc -c -O -ansi -D_GNU_SOURCE -I/usr/X11R6/include -O -I. -I../netcdf/libsrc statdisp.c statdisp.c: In function `main': statdisp.c:100: warning: return type of `main' is not `int' statdisp.c: In function `draw_text': statdisp.c:1178: virtual memory exhausted compile statdisp.cp: FAILED You can see that the failure was caused by your system running out of virtual memory. The fact that statdisp.cp compiles during a full rebuild is puzzling since there was not change to this module in any addendum. Is it possible that statdisp.cp somehow got munged on your disk? Starting fresh with a new distribution would get around this by writing a new copy, of course. Tom