>From: Mel Taylor <address@hidden> >Organization: Central Michigan >Keywords: 199902191448.HAA08416 McIDAS-X Solaris x86 Mel, re: login information OK, got it. >Solaris >was installed using the defaualt full installation. I have installed the two >recommended security patches from Sun (/export/home/downloads/patches). Thanks, that's good to know. >As you will see, the compressed source is still located in the mcidas home >directory in case you need to revert back to it for some reason. OK. >The data is coming from an NFS mount (waterspout.cst.cmich.edu) on /data. I see that. >I have placed the machine as "out of order", so feel free to do what is needed >(including reboots, process kills, etc). Users have been instructed not to >use the machine. Great, thanks. >Let me know if I can supply any additional help. Thanks. That was enough. I logged on and did some poking around and modified a couple of things that were not related to the problem you were reporting: o noticed that /usr/openwin/bin was not in the PATH for 'mcidas'. I added this directory to the PATH definition in ~mcidas.cshrc and made the change active. (You can't open an xterm without this directory being in your PATH). o edited ~mcidas/data/LOCAL.NAM and changed the location for the tutorial directory: from: /home/mcidas/data to: /export/home/mcidas/data o changed the location for the front reports (ASUS1 bulletins): from: /var/data/ldm/surface/front to: /data/ldm/surface/front I note that you do not have your LDM filing these products anywhere (I can't see where they would be under the /data directory structure). You may want to add filing of these products so McIDAS can plot fronts on top of navigated displays. o changed the location of the topographic AREA files: from: /home/mcidas/data to: /export/home/mcidas/data The topography images are pretty useful and should be made accessible to all users. You will want to restore the modified REDIRECTions to all user's McIDAS sessions: REDIRECT REST LOCAL.NAM I then proceeded to check out the bizarre segmentation violation errors you are getting from MDX. I reverified that they are, indeed, coming from MDX and not the macros that are running MDX. I then remade MDX twice. The first time, I simply deleted mdx.o and did a 'make mdx.k' (from the ~mcidas/mcidas7.4/src directory, of course). This did not produce a working mdx.k executable as you noted. The next thing was to delete all of the mdx*.o files and redo the 'make mdx.k'. This _also_ did not produce a working mdx.k. Acutally, some things in MDX can do: MDX CLE worked just fine, but: MDX T core dumped. Since this failure makes absolutely no sense to me, I decided to FTP over a copy of mdx.k from a system here at Unidata that we know works. I used this copy to overwrite ~mcidas/bin/mdx.k (which is the same file as ~mcidas/mcidas7.4/src/mdx.k by virtue of a hard link). This copy of mdx.k _does_ work correctly. This tells me that something odd is happening in the compile/link phase for mdx.k, but it does not tell me what. That's when I tried to use the debugger, dbx, on mdx.k and notice that you do not have this installed (requires a license). I finally resorted to adding debug statements to mdx.pgm and rebuilding mdx.k. What I found was an old Fortran compiler bug that I believed was eliminated in current releases of SC4.2. The problem is that f77 is incorrectly compiling the routine csetkn.o (from csetkn.for) when optimization is truned on. To make mdx.k run on your system, I did the following: cd ~mcidas/mcidas7.4/src ln csetkn.for csetkn.f f77 -c csetkn.f ar r libmcidas.a csetkn.o make mdx.k rm csetkn.f Now, since MDX works as it should, all of the MDX macros also work as they should. To test this, I ran: SPC T USA 22 This gave the correct display. This bug surfaces for one and only one McIDAS executable, mdx.k. The correct fix, however, is for you to get and apply the Fortran patch that is available for SC4.2 from Sun: 105073-05 (Jumbo Patch for FORTRAN 77 4.2: on Solaris Intel) After you update your SC4.2 development environment, subsequent builds of McIDAS-X should produce good executables. >-- >Mel Taylor (address@hidden) >College of Science & Technology >Central Michigan University Tom Yoksas >From address@hidden Tue Feb 23 06:17:35 1999 >A BIG THANK YOU for all your help. >I realize my LWPATH.NAM file was somewhat out of whack. I was going to >clean it up once I got the plotting going. I have also been in the >process of updating my data files with data that is not being >stored. Thanks for the clean up. >I should have thought about the compiler patches, but seeing I never >patched the SPARC version it never occurred to me that this was the >problem. These are our first systems under X86. Oh well, sometimes >I win sometimes I lose. >Thanks again. >-- >Mel Taylor (address@hidden) >College of Science & Technology >Central Michigan University
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.