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

19990222: Problems with Mcidas on Solaris X86 (cont.)

>From: Mel Taylor <address@hidden>
>Organization: Central Michigan
>Keywords: 199902191448.HAA08416 McIDAS-X Solaris x86


re: login information
OK, got it.

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


>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





o changed the location for the front reports (ASUS1 bulletins):





  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:





  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


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:


worked just fine, but:


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

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:


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.